Записи с тегом «dev»

О Проектных Менеджерах (ПМах)

У ПМ в команде несколько ролей. Одна их них — поддерживать спокойный и положительный эмоциональный фон. ПМ должен принимать на себя все эмоциональные удары и другие неприятности исходящие от Владельца Продукта, не давать этим эмоциям просачиваться в коллектив. Хороший ПМ работает как фильтр, сглаживает все эмоциональные перепады в команде.

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

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

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

О разработчиках

Разработчики любят и жалеют свой код. Жалко его выбрасывать, не очень хочется переделывать. Разработчики будут спорить и доказывать, что код правильный и хороший. Со своим кодом расставаться тяжело. Про это нужно помнить.

Разработчики не любят писать тесты. «Зачем их писать? Я проверил, тут всё работает.» Часто потому, что для тестирования бизнес-процесса нужно проделать много работы, чтобы создать подходящие сущности и окружение. В терминах e-commerce, например, это нужно создать сайт, с продуктами, кастомера с адресами и телефонами, положить эти продукты в корзину, залогинить кастомера и только тогда уже проверить, что для такой корзины и кастомера с таким адресом действует налоговое исключение. Часто написание теста занимает больше времени, чем сама фича или фикс. Вывод: нужно развивать тестовую инфраструктуру и код.

Если говорить о каком-то более-менее стандартном веб-приложении, например, админская часть для e-commerce системы, то на одного бекенд-разработчика нужно два фронтенд-разработчика. Бекенд делать быстро, проще тестировать. Фронтенд — это UI, какая-то клиентская логика, работа с апи, сложнее и дольше тесты.

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

ПМ у меня спрашивает: что мы дадим нашему новому фронтенд-разработчику? Как он у нас будет расти, как он станет профессионалом? А я и отвечаю: Профессионалом становится тот, кто в своё время сделал много черной работы: тупая верстка, поддержка работающего, но адского кода в виде jquery-спагети; переписывание большого скучного легаси. Такая чёрная работа и даёт понимание того, как работает проект, как работает фронтенд, насколько он бывает плох и противен. Писать месяцами на модном фреймворчике — получится рафинированный пользователь фреймворка, который пороху не нюхал.

Разработчики перегорают. Пропадает интерес, запал. Повышение зарплат не помогает, они привыкли к постоянному повышению. Хороший показатель перегорания, когда синьёр разработчик возвращается с уровня проектов, до уровня задач. «Давайте мне таски, я их буду делать.» Вместо: «Давайте мне проект, я буду его делать.»

Очень хочется работать с людьми, которые работают и мыслят не в рамках тасков, но в рамках проекта. Которые думают о взаимосвязях внутри проекта, думают и последствиях, думают о сценариях. К сожалению популярные нынче скрамы и аджайлы немного не про это. Разработчики становятся на конвейер по закрытию тасков. Проект целиком видят только технические лидеры, заказчик (не всегда), ПМ (иногда).

На работе

Уже больше двух лет я работаю в команде, которая развивает, внедряет и поддерживает e-commerce движок. Этот год по-моему стал переломным. Проект начал выбираться из sql-болота, в которое его долгое время погружали. Держать самые важные функции в хранимых процедурах очень не удобно: нет версионности, тяжело отлаживать, трудно синхронизировать и деплоить. Медленно, но уверенно наш критический код передвигается их хранимых sql-процедур в c#-код.

Мы написали огромное количество тестов: юнит-тесты на бекенде, функциональные тесты на фронтенде (на Selenium). Появилось больше веры в наш код. Теперь деплой на продакшн-серверы — это не стресс и скрещивание пальцев, а обычный процесс, который мы можем делать несколько раз в день.

Очень помогла книжка Егора Бугаенко «Elegant Objects». Мы поняли наконец, что public static — это адское зло, с которым нужно бороться изо всех сил. Маленькие простые классы рулят, они легко тестируются и поддерживаются.

В 2016 году я впервые сам нанял разработчика в команду. Поиск оказался не простым делом, которое отняло много времени, но теперь я понимаю, как это происходит. Десятки резюме, много собеседований, вопросов и заданий. Понял для себя и знаю, что говорить кандидатам, в чём отличие нашей команды от других, в чём наши преимущества и недостатки. Сейчас повторяю этот опыт, но видимо дальше будем звать профессиональных хантеров. Новичёк довольно быстро влился в проект, разобрался что и как. Его свежий взгляд указал нам на много косяков в проекте, за что ему благодарность. Из него получается аккуратный и дотошный мидл.

Ещё стало понятно, что для проекта нужна новая кровь. Разработчики, которые в проекте 5 лет, костенеют, привыкают, жалеют свой старый код, с которым частенько нужно беспощадно расправляться. Новички лучше видят проблемы и кривости, не жалеют старого кода, готовы всё переписать заново.

Закрыли с партнёром Домовед. Очень важный проект, которому мы уделили много времени и который многому нас научил. Проект постоянно стабильно рос. Мы были вверху поисковой выдачи по запросам «… без посредников». Мы проверили несколько интересных гипотез и убедились в том, что люди готовы платить за объявления без посредников. В конце концов свою квартиру я нашёл на Домоведе. Чтобы проект жил, над ним нужно постоянно работать. Свободное плавание тут не катит. Два года назад разработка остановилась, а год назад стало понятно, что разработка вряд ли продолжится. Чтобы не было стыдно за проект, мы его просто закрыли. Итог за 2013-2015 годы примерно такой: расходы — 36 000 грн, доходы — 16 000 грн. Потерь совершенно не жалко, это было интересно и круто. Спасибо, Домовед!

Музыка

Я уже больше года подписчик Google Play Music и практически всё слушаю там. Слушалось очень много и очень разного. Попытался разобраться в хип-хопе. Услышал и полюбил Мгзавреби. Вспомнил и много раз послушал альбом «Goddess in the Doorway» Мика Джаггера и «Alone in the Universe» от ELO. Нашёлся Hiatus c классным альбомом «Ghost Notes» и Mokhov c «Magic Times». Ну и много-много всего, регулярно оставлю ссылки в твитере.

2017

В 2017-м году я желаю себе и вам больше проводить времени с семьёй, больше спать, не пропускать обеды, закончить всё незаконченное, отдохнуть в три отпуска и слушать хорошую музыку. Быть добру!

В прошлом году я помимо написания кода стал немного заниматься управлением. Самый важный аспект в этом деле — это отношения внутри команды: «люди и взаимодействие важнее процессов и инструментов». Прочитал интересную статью, которая проявила проблемы нашей команды и нашего процесса разработки. Оставил себе конспект.

Будьте осторожны с высокими показателями

Ваши отличные исполнители добиваются высоких результатов продуктивности путем технического долга намеренно или ненамеренно. Они экономят время на дизайне и архитектуре разных уровней, отсутствии адекватного тестирования и разработке кода, который трудно читать, поддерживать и расширять.

Поощряйте продолжительное улучшение продукта

Как бы вы не старались, технический долг будет накапливаться. Стимулируйте разработчиков улучшать приложение, в то время как они работают над своими проектами. Примерами улучшений является создание объектов для повторного использования кода и разбивание больших объектов, которые трудно поддерживать, на объекты поменьше, с которыми легче работать по отдельности. Непрерывное совершенствование это не самостоятельный проект. Когда склонность к постоянным улучшениям станет частью ДНК вашей команды, результаты вас поразят.

Поощряйте право собственности на код

Разработчикам нужно дать право собственности на части кодовой базы и не позволять другим разработчикам менять этот код без одобрения владельца. Это приводит к более высокой производительности труда, поскольку разработчик знаком с кодом, с которым он обычно работает.

Распознавайте лидеров

Некоторые ваши разработчики активнее других участвуют в обсуждениях, к ним чаще обращаются за помощью или советом, чем другие и их чаще приглашают на собрания по разработке, даже если они не будут работать в этом проекте. Эти разработчики ваши истинные лидеры. Ваши коллеги уже проделали тяжелую работу выявления настоящих лидеров за вас. Эти лидеры также должны быть публично признаны таковыми. У ваших лидеров будет уходить больше времени на завершение своих проектов — в конце концов, они делают сразу две работы. Не заставляйте ваших (зачастую стеснительных) истинных лидеров просить о повышении — просто сделай это.

Следите за ложными системами показателей

Разработчики программного обеспечения не так уж и глупы, они быстро узнают, как обыграть систему показателей, если контрпродуктивные средства поощрения видны. Так или иначе, вся работа сведется к достижению самого высокого показателя выполненной работы.

Отдельные рабочие места

Нет ни единого научного доказательства того, что офисы открытого типа это хорошая идея и есть неопровержимые доказательства того, что они ухудшают продуктивность большинства разработчиков программного обеспечения. Разработчикам программного обеспечения нужны личные места.

Поощряйте эксперименты

У большинства компаний нет огромных денежных ресурсов, чтобы дать 20% рабочего времени под экспериментальные проекты как у Google. Эксперименты, тем не менее, периодически следует поощрять и поддерживать. Разработчики программного обеспечения не лишены хороших идей и имеют особый опыт, а соответственно у них хорошее чутье касательно приложений, которые могут быть улучшены и расширены.

Позволяйте сотрудникам уходить

Если сотрудник подходит к вам и просит перейти из одной группы в другую, милостиво позвольте им этого сделать. Это не значит, что вы должны позволить им уйти посреди кризисного времени, но как правило, если они хотят уйти из группы, значит что-то не сложилось.

Всегда выполняйте небольшие просьбы

Ваш сотрудник хочет монитор побольше? Купите. Они хотят определенную клавиатуру? Купите. Они хотят работать из дома каждую среду и это их личное требование? Разрешите. Они хотят Мак вместо ПК? Дайте им его. Даже если у них постоянный поток запросов, который кажется никогда не закончится, никогда не говорите им нет, кроме одного случая: если вы уверены, что эта маленькая просьба появится у всей фирмы и это действительно будет слишком сильно сказываться на бюджете.

Отмените годовые и полугодовые отчеты

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

Вы не лучше ваших сотрудников

Разработка программного обеспечения это работа. Управление разработкой программного обеспечения это работа. То, что ваши сотрудники отчитываются перед вами, еще не значит, что вы умнее или лучше них. Не путайте и не позволяйте вашим работникам путать менеджмент с карьерным ростом — это просто другая работа, даже если за нее платят немного больше.

Не делайте возврастную скидку

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

Обобщение

Если вы будете должным образом заботиться о своих сотрудниках, то они будут заботиться о вас, что приводит к лучшим результатам и более высокой удовлетворенностью карьерой для вас и для них.

Егор Бугаенко написал полезную книгу про ООП. Я её прочитал и сделал для себя короткий конспект.

Современное ООП не правильно приготовлено, оно больше похоже на процедурный стиль потому, что выросло из него. Проблема больших программных продуктов — maintainability (ремонтопригодность, поддерживаемость). Решить помогает чистый стиль ООП — очень маленькие классы, immutable объекты и прочее.

Не использовать -er в именовании классов

Manager, Controller, Formatter — плохие имена плохих классов. Класс должен отражать не то, что он делает, а то, кто он есть.

Один главный конструктор в классе

Все остальные конструкторы его вызвают. Так есть единый код создания объекта, который легче поддерживать.

Конструкторы не должны содержать выполняющий код

Конструкторы только создают/инициализируют объект, вся полезная работе происходит в методах.

Делайте классы как можно мельче

Инкаплируйте максимум 4 объекта. Такие классы легче поддерживать и тестировать.

Всегда используйте интерфейсы

Интерфейс — это задокументированный контракт, который класс будет выполнять. (Спорно)

Методы-билдеры именуйте существительными

Например: string content(File file), int sum(int, int)

Методы-манипуляторы именуйте глаголами

Например: void paint(Color color), void write(string s). Такие методы не должны что-то возвращать, всегда void.

Методы возвращающие булевый тип именуйте прилагательными

Например: bool empty(), bool negative().

Не используйте константы

Они добавляют связи между классами, а это плохо. Вместо констант нужно делать классы, которые имплементируют работу с этими константами. (Спорно)

Делайте объекты не изменяемыми (immutable)

Такие объекты лечге поддерживать и отлаживать. Есть если объект должен изменить своё внутренне состояние, значит нужно создать и вернуть новый объект с новым внутренним состоянием. Плюсы такие:

• объект всегда остайтся самим собой, нет identity mutability,
• failure atomicity — ошибки не влияют на внутреннее состояние объекта, он всегда остайтся собой,
• нет сайд-эффектов,
• нет null в полях, всё должно быть проинициализировано в конструкторе,
• потокобезопасность — много потоков могут пользовать объект без синхронизаций,
• маленькие и простые классы — трудно сделать immutable класс в 5000 строк.

Пишите тесты вместо документации

Плохой код вынуждает писать документацию к нему. Простые маленькие классы не нуждаются в документации. Хорошо написанные юнит тесты для класса и есть его документация.

Не используйте моки, используйте фейки.

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

Максимум 5 публичных методов в классе

Маленькие классы легче понимать, поддерживать и тестировать.

Не используйте статические методы

Статические методы из процедурного стиля программирования. Они удобны для компьютера, но плохи для ООП, классов, поддержки и тестирования. Императивный стиль — это про алгоритмы и исполнение. Декларативный — про объекты и поведение. Нужно стремиться к декоративному стилю.

Не используйте utility классы, хелперы

Это обычно не классы, а набор процедур. Это очень частый антипаттерн в ООП.

Не используйте синглтоны

Немного лучше, чем utility класс. Но без него можно. Не используйте их. Объект не должен трогать ничего кроме своих инкапсулированных свойств. Все остальное объекту нужно передавать в конструкторе.

Функциональное программирование

Оно конечно хорошее, но ООП более выразительное и мощное потому, что имеет не только методы (функции), но и объекты.

Не принимайте NULL-аргументов

Это избавляет от проверки на null. Null - это из мира компьютеров, а не из мира объектов.

Be loyal and immutable, or constant

Коротко не скажешь, нужно читать.

Не используйте геттеры и сеттеры

Объекты в ООП не просто структуры данных. Структура данных прозрачная, а объект — черный ящик. Структурв данных пассивная, объект — активный. Геттеры и сеттеры нарушают целостность объекта, он становится не иммутабельным.

Используйте new только во вторичных конструторах

Для создания объектов по-умолчанию.

Избегайте проверки и приведения типов

Reflection — это хороший инструмент для плохих программистов.

Никогда не возвращайте NULL

Лучше выбрасывайте исключение. Fail fast — чем раньше вы упадёте, тем быстрее вы найдёте ошибку. Вариант: возравращать объект специального класса: class NullUser implements User.

Не ловите исключения, которые вы не должны ловить

Пусть они улетают выше, fail fast.

Используйте вложенные исключения

Словили исключение, выбрасывайте новое с хорошим описанием ситуации и вложенным словленным исключением.

Одного типа исключений достаточно

Использование вложенных исключений приводит к тому, что одного типа исключений обычно достаточно.

Используйте RAII

Получение некоторого ресурса неразрывно совмещается с инициализацией, а освобождение — с уничтожением объекта.

Проджект менеджмент на работе — trello.com.
Проджект менеджмент для домашних проектов — hackpad.com.
Группые, приватные, 1-на-1 чаты на работе — hipchat.com.
Система контроля версий — mercurial.
Хостинг репозиториев для домашних проектов — bitbucket.org.
IDE — ReSharper и PyCharm.
Текстовый редактор — SciTe.
Текучие дела и туду для дома — Google Keep.
Читалка фидов — self hosted Tiny Tiny RSS + его же Andriod-приложение.
Веб-закладки — thinkery.

Много разных програм и сервисов было перепробовано, прежде чем этот набор устоялся и стабилизировался.

Забываю я эту магическую последовательность в Cache-Control, которая запрещает браузеру кешировать ответы. Записываю на память:

Cache-Control: no-cache,no-store,must-revalidate,max-age=0

Ещё для верности можно добавлять:

Pragma: no-cache
Expires: 0

А ещё браузеры не кешируют POST-запросы.

Рассматривая исходники Apache, нахожу занятные лицензии и комментарии. Например, apr_md5.c:

/*
 * The apr_md5_encode() routine uses much code obtained from the FreeBSD 3.0
 * MD5 crypt() function, which is licenced as follows:
 * ----------------------------------------------------------------------------
 * "THE BEER-WARE LICENSE" (Revision 42):
 * <phk@login.dknet.dk> wrote this file.  As long as you retain this notice you
 * can do whatever you want with this stuff. If we meet some day, and you think
 * this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 * ----------------------------------------------------------------------------
 */