Идеальный программист. Часть 1

Статья-конспект по книге Роберта Мартина «Идеальный программист». После прочтения книги у меня поменялось отношение к программистической жизни. В книге рассматривается процесс написания кода, сам код, отношение к задачам, TDD и много других полезностей. Читать нужно разработчикам и менеджерам проектов. Частично применимо к дизайнерам.

1. Профессионализм

Непрофессионалы не берут ответственности за свою работу. Они делегируют эту ответственность выше по иерархии: ты начальник, — ты и отвечаешь. Если непрофессионал обкакался, — экскременты приходится убирать работодателю. Профессионал чистит за собой сам. Что ещё делают профессионалы и не делают дилетанты?

Используют правило «Не навреди». Ваш код должен работать и вы не должны ничего ломать. Конечно, это не каждому под силу, но по мере профессионального роста, количество ошибок в вашем коде будет стремиться к нулю.
Контроль качества не должен ничего найти. Я неоднократно наблюдал ситуацию, когда в тестирование отправлялась неверно выполненная задача. Причём, то, что она не выполнена было понятно разработчику. Такое отношение никуда не годится. Когда вы отдаёте задачу тестировщикам, вы должны быть полностью уверены в вашем коде. Дефектный код — это любой код, в качестве которого вы не уверены. Если служба контроля качества нашла в вашем коде ошибку, вы должны удивиться, извиниться, понять, почему это произошло и не допустить подобного в дальнейшем.
Используют автоматизированное тестирование. Невозможно быть уверенным в качестве своего кода, не протестировав его. Протестируйте код вдоль и поперёк, справа налево и сверху вниз. Каждый кусок кода должен быть протестирован для всех возможных ситуаций. Если это делать вручную, — у вас не будет времени на разработку, поэтому тестирование нужно автоматизировать: пускай потеет машина. Код должен быть покрыт тестами на 100%. Об этом чуть подробнее позже в разделе про TDD.
Пишут гибкий код. Структура кода должна обеспечивать гибкость. Внесение изменений в код не должно приводить к непомерным затратам. Профессионалы знают паттерны проектирования и строят на них программную архитектуру. Проверяется просто: попробуйте внести изменения в ваш код. Если это вызовет боль чуть ниже пояса, — значит с гибкостью у вас всё плохо. Переработайте структуру кода, чтобы следующее изменение вносилось проще. Это называется безжалостным рефакторингом: всегда оставляйте модуль чище, чем до вашего прихода.
Учатся сами. Работодатель не обязан вас никуда отправлять учиться. Если вы работаете 40 часов в неделю, — запланируйте на работу 60 часов. Из них 40 часов вы потратите на работодателя, а оставшиеся 20 — на самообразование.
Знают свою область. Вы должны знать, что такое диаграмма Насси—Шнейдермана, алгоритм быстрой сортировки, что означает термин «бесхозные данные» и для чего нужны «таблицы Парнаса». Чтобы быть профессионалом, вам нужно знать фундаментальные основы профессии. Причём, большая часть этих основ была сформулирована несколько десятков лет назад. Паттерны проектирования, SOLID, методологии разработки, анализа и проектирования, TDD, ООП, структурное программирование, непрерывная интеграция, парное программирование, артефакты.
Не останавливаются в обучении. Наша отрасль постоянно развивается и обновляется. Если вы не следите за тем, что происходит, вы можете за год оказаться в каменном веке. Пример для дизайнеров: вы можете не знать о том, что для фотошопа есть плагин, разбивающий ваш макет на ассеты и заливающий в облако, но заказчик предпочтёт работать с тем дизайнером, который в качестве результата работы даст ему ссылку на сборник ассетов для верстальщика. Это я про sympli.
Тренируются. Чтобы держать форму, нужно постоянно напрягать мозги. Выполняйте упражнения на разных языках программирования. Пусть это будут несложные задачи, которые занимают не больше 10 минут. Но время на них нужно выделять каждый день.
Работают совместно. Отличный способ научиться чему-то новому, — это совместная работа. Профессиональные разработчики стараются вместе проектировать, тренироваться, работать, планировать. Они много узнают друг от друга и делают свою работу эффективнее. Очень помогает, когда вы даже просто сидите рядом с товарищем и смотрите, как он пользуется средой разработки. О! Оказывается, есть раскладка Бирмана и Ctrl-Alt-Z в фотошопе.
Учат других. Лучший способ научиться самому — это научить других. Именно поэтому я пишу статьи и иногда провожу занятия и курсы. Основную пользу от преподавания получает преподаватель. Профессионалы берут на себя ответственность за обучение новеньких сотрудников и не бросают их один на один с огромной медицинской информационной системой, в код которой даже смотреть страшно (это про нас).
Знают предметную область. Есть порочная практика работать только по спецификации. Это верх непрофессионализма, когда мы всю мыслительную деятельность поручаем аналитикам, а свой собственный мозг используем исключительно для описания алгоритмов. Профессионал знает полезное действие. Он понимает, зачем нужна каждая функция, что она даст пользователям и как она повлияет на бизнес клиента. Он может исправить спецификацию и отправить аналитиков на дополнительное исследование.
Понимают интересы работодателя и заказчика. Если у вашего работодателя проблемы, — это ваши проблемы. Если вашему работодателю задолжал ДИТ Москвы 30 миллионов и не платит уже который месяц, — это означает, что вы к новогодним праздникам останетесь без премии. Предлагайте решения проблем заказчика и знайте его бизнес. Придумайте для своего заказчика новый проект, идею, улучшение, бизнес-процесс, продукт, посоветуйте сотрудника, поставщика, покупателя. Не жадничайте.
Скромны. Профессионал — это не непогрешимый царь горы. Я видел примеры, когда даже самые квалифицированные разработчики ошибались. Профессионал не смеётся над ошибками других, не издевается над коллегами, принимает заслуженные и незаслуженные насмешки над собой. Он понимает, что его оценки сроков могут быть неверными, а выбранная технология окажется негодной.

2. Говорите «Нет»

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

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

Фразы «я попробую», «я постараюсь, «я попытаюсь» нужно совсем исключить из своей лексики и не принимать такие ответы ни от кого другого. Если вам говорят такие фразы, — уточняйте и настаивайте на прямом ответе. «Я попытаюсь» — означает, что вы приложите дополнительные усилия для того, чтобы выполнить задачу. А какие это усилия? Неужели вы работали раньше не в полную силу? Или теперь вы готовы работать круглосуточно? Или вы взвалите это на плечи коллектива? Если у вас нет резервов энергии, нового плана и не собираетесь изменять своё поведение, — значит вы просто врёте. Не надо пытаться.

3. Как сказать да. Язык обещаний

Один мой хороший, но неопытный друг встречался с клиентом по сайту и пригласил меня на переговоры. Пришёл мужчина и начал рассказывать о том, какой у него хороший проект, но он уже несколько раз обжигался на непрофессионалах; поэтому нам нужно сделать предварительные макеты. Я знаю о вреде предварительных макетов, а мой друг не знал и как только я собирался открыть рот, — он уже ответил, что «да, хорошо, мы сделаем». Так был сделан первый и единственный шаг к потере клиента. К заданному сроку он не сделал макет, не получил новый заказ и клиент разочаровался.

Обещание можно разделить на три части:

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

Сказать «да» — это значит, что нужно сказать, что вы что-то сделаете без каких-либо модификаторов. Что это за модификаторы? «Нужно» (мне нужно похудеть), «должен» (мы должны найти новых клиентов), «постараюсь» (я постараюсь уговорить инвестора), «хорошо бы» (хорошо бы сходить в кино), «надеюсь» (надеюсь, мы встретимся на следующей неделе), «давайте» (давайте сделаем аутентификацию к четвергу), «если будет время».
Проследите за своей речью и речью других. Обратите внимание, как часто эти слова встречаются вокруг нас и как часто вы пытаетесь снять с себя ответственность.

Серьёзное обещание говорит о том, что вы выполните конкретное действие. Даже если вы не можете сделать всё, что вас просят, вы можете сделать какую-то конкретную часть из предложенного.
— Сделай, пожалуйста, отчёт в Birt. Это нужно сделать к понедельнику.
— К понедельнику не смогу. Но к этому времени я подготовлю веб-сервисы.
В общем виде серьёзное обещание выглядит так: «Я сделаю то-то к такому-то времени».
Если вы не справились с обещанным, как можно быстрее сообщите об этом тому, кому вы обещали.

4. Написание кода

Готовность кода — это такое его состояние, когда решено сразу несколько задач:

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

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

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

Зона потока — зло. Так программисты называют сверхпроизводительное время, когда удаётся писать-писать-писать код и не хочется ни на что не отвлекаться, а всё продолжать и продолжать. В этом состоянии программист считает себя суперменом, а свой код хорошим.
Проблема в том, что быстро написанный в Зоне код чаще становится причиной ошибок. Вы можете потерять часть общей картины и код будет плохо согласован с остальным частями или бизнесом. Если вы чувствуете, что входите в Зону, предпринимайте осознанные усилия, чтобы выйти из неё. Помогает pomodoro, парное программирование и жена.
Верный признак Зоны, — это когда вы невежливо отвечаете на телефонные звонки и не рады даже хорошим людям.

Творческий кризис можно преодолеть. Он обычно происходит от усталости или от однообразия. Вводите в свою жизнь что-то новое и больше отдыхайте. Читайте книги из разных областей: классическую литературу, естествознание, научную фантастику, Дарью Донцову. Творчество порождает творчество.

Сокращайте время отладки. Это время кажется разработчиком неизбежным, но чем меньше вы сидите за дебаггером, тем больше вы сделаете чего-нибудь действительно полезного. Помогает TDD/TLD и контрактное программирование.

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

5. Отставание от графика

Есть такой класс людей, которые пытаются уверить до последнего, что всё будет хорошо, хотя, понимают, что к сроку не успеть и это понятно даже ёжику. Из недавней практики: мой друг, фотограф (Ф) и поэт заказал новогоднюю фотозону у парня по имени П. Ф поставил перед П задачу с дэдлайном на три дня раньше реального: 1 декабря. Реально, 4 декабря должны были начаться съёмки в по-новогоднему оформленной студии. Однако, сегодня 6 число, а фотозона ещё не готова. Ф проклинает П, строит сам, отменяет фотосессии, несчастлив.

Домашнее задание: приведите пример, когда вы облажались со сроками и всех подвели.

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

6. Помогайте и принимайте помощь

Если вы Программист с большой буквы, — помогите другим. Это важная часть профессиональной этики. Ваша работа не настолько важна, чтобы не помогать начинающим. Но это не значит, что вы должны отказаться от личного времени и оказывать помощь всегда и везде. Объявите во всеуслышание, что вы готовы помогать только с 14:00 до 16:00.
Принимать помощь — ещё большее искусство. Если предлагают, будьте признательны и выделите время на это. Если не предлагают, обязательно попросите. Выйдите в общий зал, встаньте на табуреточку, скажите: «мне нужна помощь» и нарисуйте на доске суть вопроса. Не стесняйтесь. Понятно, что многие становятся программистами, потому что им больше нравятся компьютеры, чем люди. Однако, для хорошего разработчика навык общения и приёма-передачи знаний жизненно необходим.

На этом первая часть окончена. Через неделю будет вторая часть, в которой рассмотрим TDD, тренировку, приёмочное тестирование, планирование, уклонение от работы, способы оценки, работу под давлением, работу в группе.

Иллюстрации нарисовал Александр Корнилов.

Акция: Сегодня у меня день рождения и по этому поводу розыгрыш: кто поздравит с ДР, тот получит электроверсию книжки в ЛС. Акция до 12 декабря включительно.
ссылка на оригинал статьи https://habrahabr.ru/post/317312/