clean_coder_martin.org

💪 Идеальный программист: как стать профессионалом разработки ПО / Мартин Роберт

Глава 1. Кто такой профессионал?

• Ответственный человек, добросовестно выполняющий свою работу и целенаправлено совершенствующийся.
• Профессионал НЕ релизит код без тестирования, а говорит, что он не успевает, говорит заранее, чтобы его менеджер смог что-то сделать. Это ответственное поведение.
• Профессионал НЕ вредит функционалу поэтому использует автотесты, чтобы быстро проверять работает ли его программа или нет.
• Профессионал НЕ вредит структуре программы поэтому пишет код так, чтобы его можно было быстро изменять в будущем.
• Профессионал разбирается в предметной области: для этого он читает минимум одну книгу в той предметной области с которой работает.
• Профессионал уверен в своих силах, чтобы либо взяться за сложную задачу либо найти силы сказать нет, но в то же время понимает, что может ошибиться.
• Профессионал думает об интересах заказчика.
• Как избежать выгорания? Работай 40 часов в неделю на работодателя и еще 10-20 часов посвяти себе: читай книги, пробуй новые языки, экспериментируй, в общем выбирай интересные вещи - это важно.

Глава 2. Почему нужно говорить нет и почему здоровые конфликты создают лучший продукт?

• Если нельзя уложиться в дедлайн или в принципе сделать задачу, то так об этом и скажи, как бы тебе ни было страшно.
• В процессе обсуждения можно изменить требования или сдвинуть дату релиза.
• В процессе конфронтации каждый член команды преследует свою цель и совместно они находят общую цель. Цель – создать востребованный продукт, а это значит, что нужно разобраться со множеством конфликтующих интересов.

Глава 3. Почему нельзя ничего обещать впустую?

• Слова “попробую”, “надо бы” - верный признак того, что ничего сделано не будет.
• Другие люди полагаются на твои слова и ты их можешь подвести. Лучше, чтобы они сразу знали, что что-то сделано не будет: тогда у них останется время для маневра, а ты не будешь тратить их время зря.
• Обещай сделать только выполнимые вещи и в четко оговоренный срок.
• Если дал обещание и понимаешь, что не можешь его сдержать - сразу сообщи об этом и помоги другим людям подготовиться к решению этой проблемы.

- Глава 4. В каком состоянии не надо писать код?

• Ночью - скорее всего ты уже устал, но еще не заметил этого.
• Сверхурочно - если это делать регулярно, то устанешь так, что не захочется вообще работать.
• В состоянии потока - ты не видишь всю картину и есть риск написать быстро, но получить проблему в неожиданном месте.
• В расстроенных чувствах. Если это так, то возьми время и реши проблему: позвони жене и т.д.

Глава 5. Как тестировать код?

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

Глава 6. Какие навыки тренировать?

• Слепая печать
• Горячие клавиши
• Ката: решение типовой задачи на 20-30 минут. Ты уже знаешь как решать задачу, просто доводишь до автоматизма работу с терминалом, IDE, тестами, языком и т.п.
• Можно выявить вещи, которые вызывают трудности, и тренировать их отдельно.
• Можно тренироваться в паре и видеть как другой человек решает ту же задачу. Так научишься новому подходу.
• Тренируй также использовать языки и платформы, которых нет на работе. Это расширит кругозор и будет легче использовать новые технологии, когда будет нужно.
• Читай исходный код опенсорс проектов. Если пришлешь пулл реквест - отлично.

Глава 7. Что значит задача сделана?

• Требования понимаются одинаково как заказчиком так и разработчиком.
• Задача проходит автоматизированные приемочные тесты.
• Важно определить приемочные тесты в процессе согласования требований между заказчиком и разработчиками (включая тестировщиков).
• Реализация пишется после приемочных тестов.
• Приемочные тесты являются формальной документацией по поведению системы. Должны использоваться как программистами, так и заказчиком.

Глава 8. Как тестировать программу?

• Модульные тесты проверяют изолированную вспомогательную логику вместе с особыми случаями.
• Компонентные тесты проверяют изолированную бизнес-логику.
• Интеграционные тесты проверяют связь компонентов и обмен информации между компонентами.

Глава 9. Как планировать свой рабочий день?

• Отказывайся от встреч, если не получаешь немедленной пользы или не понимаешь для чего использовать эту встречу.
• Уточни у организатора встречи какая у нее цель и длительность.
• Если спор длится более 5 минут, то его скорее всего нельзя разрешить логически. Остановись и иди искать новые факты.
• Используй сон или любую переключающую активность для восстановления ресурса концентрации.
• Использую физическую активность, чтобы отдохнуть умом.
• Читай книги: это подпитыает творческий ресурс.
• Работай помидорами.
• Если совершил ошибку, то признай ее и исправь. Не надо строить костыли вокруг ошибки - это слишком дорого.

Глава 10. Что такое оценка и обязательство?

• Оценка – это диапазон времени, в который задача будет сделана с учетом неопределенности.
• Обязательство – это время, за которое задача точно будет сделана. Если возникнут непредвиденные проблемы, то их придется решать за свой счет (сверхурочные и т.п.).
• Оценивай не одним числом, а тремя (PERT): min (нет проблем вообще), average (наиболее вероятная оценка), max (все пошло не так как ожидалось).
• Средняя оценка по методу PERT = (min + 4*average + max)/6
• Среднее отклонение по методу PERT = (max - min)/6
• По методу PERT можно оценить проект: посчитай сумму средних оценок всех задач и корень из суммы квадратов средних отклонений задач. Это и будет среднее значение проекта и его среднее отклонение.
• Еще задачи можно оценивать (от 1 до 5) всей командой и если оценки совпадают, то брать задачу в работу, а если не совпадают, то выяснять почему до тех пор пока члены команды не придут к согласию.

Глава 11. Как работать под давлением?

• Не бери на себя невыполнимые обязательства.
• Если попал в кризисную ситуацию, то остановись и подумай: ты не сможешь работать быстрее в спешке - будет больше ошибок.
• Используй те же методы, что и обычно. Хирург в операционной не начинает суетиться и паниковать, наоборот, он остается хладнокровным так как от его точных действий зависит жизнь пациента.
• Если какие-то методы работают в кризис, то используй их всегда: они действительнл помогают.
• Обращайся за помощью: программируй в паре.

Глава 12. Насколько важно общаться с другими людьми?

• Очень важно для любых нетривиальных задач.
• Важно понимать конечную цель системы с точки зрения бизнеса. Нельзя просто стремиться к решению технически сложных задач, это следствие.
• Работай в паре над сложными задачами: так проще распространять знания и вообще решать задачи.
• Код должен правиться разными людьми: код будет качественнее, уменьшится bus factor.

Глава 13. Нужно ли формировать под новый проект новую команду?

• Нет: команде нужно время, чтобы сработаться.
• Лучше, чтобы одна и та же команда работала над несколькими проектами: качество будет выше.

Глава 14. Как стать мастером?

• Самому следить за другим мастером и учиться.
• Следовать профессиональному кодексу: брать ответственность, учиться.
• Подавать пример другим, хотя бы чуть-чуть.
• Запасись терпением: понадобится время.