Per aspera ad astra - и не пищать
Контакты

Достижения

Все достижения (18)

Наибольший вклад в теги

Все теги (96)

Лучшие ответы пользователя

Все ответы (200)
  • Что делать если команда говнокодит?

    Мы стараемся не запускать эту проблему посредством code review, пытаясь распределить нагрузку по ревью между наиболее опытными участниками. Если в коде есть проблемы - тикет возвращается на доработку с замечаниями. Даже если банально не мержится с главной веткой. Попробуйте наладить этот процесс.

    Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

    Прямо уж откровенной копипасты и лапши у нас вроде бы нет почти. Мы стараемся избегать её, придумывать декларативные абстракции во всех случаях, где много тупого императивного кода, писать в функциональном стиле. Я думаю, что необходимы постоянные целенаправленные усилия в этом направлении, чтоб не допускать засилья энтропии.

    Ещё пара идей.
    • можно отправить разработчиков на какой-нибудь онлайн-курс по чистому коду, хотя я таких даже не знаю, но наверняка должны быть
    • или устраивать "хакатоны чистого кода", на коих команда разбивается на пары-тройки, каждая из коих пишет какую-нибудь маленькую, но полезную, а главное чистую и оттестированную штуковину, причём тема - по собственному выбору. Потраченное время - оплачиваемое, разумеется. Это уже зависит от руководства фирмы, согласится ли оно на такие развлечения.


    Мне думается, что чистота и красота кода должны быть пунктами культуры в команде разработчиков, ценностями, если угодно. Нужно не только ругать за ошибки, но и не забывать похвалить товарища за красивое решение, за хороший код, за внимательность.

    Ну и важно, чтобы у самих разработчиков была установка на хороший код, профессиональная гордость. У фрилансеров её, бывает, нет, а есть отношение "тяп-ляп, лишь бы работало и лишь бы часы оплатили, а там хоть потоп". Учитывая, что их заказчики занимаются code review нечасто, развитие такого отношения закономерно. Но всё-таки хочется писать красивые программы. Такое желание обязано быть.

    Я, конечно, сам не волшебник, я только учусь, и работа с командой - такая штука, которой надо постоянно учиться. Видимо, вы тоже учитесь; успехов в этом.
    Ответ написан
  • Кратчайший путь до первых денег на фриланс бирже?

    У меня опыт небольшой. Python, Django, Flask, и по большей части - на oDesk. По моему мнению, самое что ни на есть важное - это: 1) выбор адекватных заказчиков, способных точно объяснить, что им надо, и желательно - технически компетентных; 2) Грамотное общение с ними. На всякое предложение о работе подписывается много людей. Чтобы выделиться среди этой толпы, необходимо потратить определённое время и силы. Внимательно прочесть предложение, подумать над ним и сформулировать в ответном письме вкратце:

    - Ваш опыт, пусть и кратко, относительно данного проекта.

    - Ваше представление о том, как следует реализовать этот проект (вкратце; но можно двумя словами, но желательно - обоснованно, упомянуть о том, что вот такую-то фичу вы реализуете с помощью MongoDB для пущей скорости). Пустословия и популизма не надо.

    - Предполагаемые сроки. Я их обычно завышаю раза в два. Это позволяет решить задачу с запасом и устранить возможные баги, глюки и т.п. Гораздо лучше, чем обнаружить потом, что времени катастрофически не хватает.

    Очень хорошо, если Вы сразу напишете ещё и некоторые рацпредложения. Вежливо и корректно, конечно.

    Короче говоря, необходимо 1) найти те проекты, в которые стоит вникать и разбираться; 2) вникнуть и разобраться так, чтобы заказчик понял: Вы - компетентный специалист, работаете на совесть, сделаете обещанное и качественно. По крайней мере, очень постараетесь. Если с самого начала тон общения построен именно так, если Вы задали уровень и поддерживаете его, то в случае возможных проблем, неувязок, нестыковок, как правило, люди относятся с пониманием.

    Ответ написан
  • Разработка web-сервисов – LAMP (Python/Django) vs. MEAN (Node.js)? Или что-то другое?

    1) Мой основной язык Python, на JS больших программ почти не писал. Когда писал на нём больше, то ощущал дискомфорт из-за:
    - отсутствия нормального наследования (хотя сейчас, вероятно, это уже исправлено)
    - трудностей с типами данных и неявными преобразованиями (вот вчера буквально был холивар на Тостере о == и ===)
    - списков, реализованных как переодетые объекты
    - отсутствия из коробки структур данных вроде deque.

    Но это были студенческие поделки.

    2) Python предоставляет больше средств борьбы со сложностью. Наследование, система метаклассов, синтаксический сахар. Хотя бы даже такая штука как property. Он даёт больше возможности инкапсулировать сложность внутри. Ну и на нём действительно очень много разнообразных библиотек. Возьмите хотя бы Django: она умеет автоматически генерировать миграции базы данных. Насколько я знаю, это мало кто умеет делать.

    3) Не думаю, что JS - это язык будущего для бэк-енда. Я бы согласился, если бы вы сказали про Scala или Kotlin, которые куда больше подходят для больших и сложных приложений хотя бы потому, что имеют ещё больше средств борьбы со сложностью, чем Python. Поэтому я смотрю скорее в их сторону для своего будущего профессионального развития, не на JS. Он как-то не очень тянет в сравнении.

    4) Ничто не помешает вам изучить платформу А, затем Б, потом В и так далее; от этого только польза. Может быть, вы через десять лет будете на Quipper - диалекте Haskell для квантовых компьютеров - писать. Но начинать посоветую всё же с Python - чтоб меньше заниматься мазохизмом и больше писать кода.)
    Ответ написан
  • Насколько легко трудоустроиться программисту в 40+, 50+ итд лет?

    Чушь, на самом деле.

    1) Довод первый, личный. Ну вот у нас в команде есть разработчик, которому за 40, занимается JavaScript. Ощущения исключительно положительные. Товарищ имеет большой опыт и очень хорошо знает что делает. Да ещё и изучает что-то новое, куда-то движется в своей области.

    Ну, правда, знал я одного или двух товарищей, которым тоже за 40 и которые обладают опытом, но при этом обладают ещё и первосортной наглостью, более всего заботясь о том, чтоб засчитать побольше часов (неплохо оплачиваемых), а не о том, чтоб их код без ошибок работал. :) Просто у человека нет совести и желания профессионально делать свою работу, это бывает в любом возрасте.

    2) Довод второй, социологический. Как известно, у человека в течение последних веков продолжительность и всей жизни в целом, и составной её части - детства стала гораздо больше. В пушкинские времена крестьянские девочки в 13-14 лет были на выданье, на них ложилась вся тяжесть семейной жизни. Сейчас это совершеннейшие дети, им только в куклы играть.

    Двадцать лет назад парень 20 лет был взрослым и уже зачастую женился. Сейчас 20 - это молодо-зелено; крепко стать на ноги к этому возрасту, стать профессионалом в интеллектуально ёмкой отрасли деятельности - да невозможно практически; посему и о семье говорить рано, что бы там ни вопили охранители. Ну и естественным образом, коль скоро детство и молодость растягиваются, то и период активной интеллектуальной деятельности - тоже должен сдвигаться. Захватывая и 40 лет, и 50, а может и 60-70. Тут уж зависит от индивидуальных усилий.

    3) Довод третий, профессиональный. Слышал ли кто-нибудь, чтобы грамотного, квалифицированного профессора математики выгоняли в 50 лет? Конечно, он наверняка уже не может генерировать идеи, как он это делал в 20; математика - дело молодых. Но опыт его огромен, он пользуется уважением, учит студентов и аспирантов; совет его ценится и может серьёзно помочь молодым коллегам; он далеко не вне профессии. Почему так происходит? Потому что математика - это устоявшаяся область, математика - это профессия в полном смысле.

    Программирование пока не вполне созрело как профессия, потому что оно несколько моложе математики (ну, не менее чем на пять тысяч лет, если считать от Московского математического папируса с задачами по стереометрии). О том, что программирование должно стать профессией - см. пост Роберта Мартина, который мне очень нравится: blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html

    UPD. Другие ораторы упомянули о психологических причинах: тим-лиду, которому 25, боязно показать команде своё невежество в сравнении дядькой, которому 40. Ну это больше говорит о тим-лиде, а не о дядьке. Тим-лиду следует посидеть вечерком в тиши и подумать, правильно ли он живёт в этом мире, коли руководствуется мерками каменного века и правилом "я начальник, ты дурак".
    Ответ написан
  • Какой набор инструментов порекомендуете для работы с картами на Python?

    • Для хранения геоданных: PostgreSQL/PostGIS. django.contrib.gis обеспечивает родную поддержку, плюс библиотеки geos, geopy для расчётов расстояний и прочего.
    • Для взаимодействия с front-end - Django REST Framework со сторонними модулями, которые обеспечивают ей понимание gis-полей.
    • Для рисования карт на front end: js-библиотека Leaflet с использованием свободно доступных слоёв (google maps или open street map) и своим кодом, взаимодействующая с back end через вышеупомянутый API.
    Ответ написан