"Идеальный программист" Роберта Мартина давно стал руководством по профессионализму в сфере IT и одним из основополагающих трудов в современной разработке, наравне с "Чистым кодом", "Чистой архитектурой" и "Чистым эджайлом".

На Хабре уже есть несколько мнений об этой книге, но в них, как правило, книга преподносится через призму субъективности.

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

Иллюстрации к посту любезно предоставила нейросеть Kandinsky 2.2.

О профессионализме

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

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

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

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

О тестировании

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

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

Об автоматизации тестирования

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

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

О TDD

Три закона TDD:

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

2. Вы пишете ровно такой объем кода модульного теста, какой необходим для того, чтобы этот тест не проходил (если код теста не компилируется, считается, что он не проходит).

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

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

TDD — не религия и не панацея. Выполнение трех законов не гарантирует ни одного из перечисленных преимуществ. Плохой код можно написать даже при предварительном написании тестов.

О чистоте кода и архитектуры

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

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

О чистой архитектуре

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

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

О доверии к своим рабочим методам

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

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

О саморазвитии

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

Читайте книги, статьи, блоги, твиты. Посещайте конференции и собрания пользовательских групп. Участвуйте в работе исследовательских групп. Изучайте то, что лежит за пределами вашей привычной зоны. Если вы программист .NET — изучайте Java. Если вы программируете на Java — изучайте Ruby. Если вы программируете на C — изучайте Lisp. А если вам захочется серьезно поработать мозгами, изучайте Prolog и Forth!

Если вы не позаботитесь о расширении собственного кругозора, это может привести к нежелательному сужению резюме и менталитета.

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

О передаче опыта

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

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

Об ответственности

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

Профессионал всегда помогает бизнесу найти способ достижения его целей, но он не всегда принимает на себя обязательства, принятые за него.

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

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

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

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

Об обещаниях

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

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

Когда говорить "да" и "нет"

Профессионалы говорят правду облеченным властью. У них достаточно смелости, чтобы сказать «нет» своим начальникам.

Как сказать «нет» начальнику? Ведь это ваш начальник! Разве вы не обязаны делать то, что говорит начальник? Нет! Говорите «нет», если вы профессионал. Рабам запрещается говорить «нет». Наемные работники неохотно говорят «нет». Но профессионалу положено говорить «нет». Более того, хорошим руководителям очень нужны люди, у которых хватает смелости сказать «нет». Только так можно действительно чего-то добиться.

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

О выполнении своей работы

У профессиональных разработчиков есть только одно определение: выполнено — значит выполнено. Сделано — значит, что весь код написан, все тесты пройдены, служба контроля качества и ключевые участники приняли результат. Сделано.

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

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

Проблема ложной готовности решается созданием независимого определения «готовности». Для этого следует поручить бизнес-аналитикам и специалистам по тестированию создать автоматизированные приемочные тесты, без прохождения которых продукт не может считаться готовым. Тесты должны быть понятны для бизнесменов и ключевых участников проекта, не связанных с технической стороной.

Об авралах

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

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

На сверхурочную работу можно соглашаться только при выполнении некоторых условий: 1 — лично вы можете ее себе позволить; 2 — аврал будет продолжаться недолго, не более двух недель, и 3 — у руководства имеется резервный план на случай, если ваши усилия завершатся неудачей.

О концентрации

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

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

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

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

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

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

О взаимодействии внутри команды

О встречах

Встречи обходятся примерно в $200 в час на каждого участника. Здесь учитываются зарплаты, премии, затраты на использование помещения и т. д.

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

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

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

Встреча должна проходить достаточно быстро: краткое обсуждение по каждому элементу списка реализации, после чего элемент либо выбирается, либо отклоняется. Ни на один элемент не должно уходить более 5 или 10 минут. Если потребуется более подробное обсуждение, запланируйте его на другое время с частью группы.

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

О работе в группах

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

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

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

О "притёртых" группах

Группы формируются не сразу. Между участниками постепенно налаживаются отношения. Они учатся работать друг с другом, узнают странности, сильные и слабые стороны своих коллег. Со временемм участники «притираются» друг к другу.

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

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

«Притертая» группа обычно содержит около дюжины участников. В группу должны входить программисты, тестеры и аналитики. И у нее должен быть руководитель проекта. Хорошо «притертая» группа из 12 человек может состоять из семи программистов, двух тестеров, двух аналитиков и руководителя проекта.

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