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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 1974 году мне было 22 года. Прошло полгода с момента брака с моей замечательной женой Энн-Мэри. До рождения нашего первого ребенка, Анджелы, оставался еще год. Тогда я работал в одном из подразделений Teradyne, называвшемся Chicago Laser Systems.

Рядом со мной трудился мой приятель по средней школе Тим Конрад. В свое время мы с ним занимались всякими интересными вещами: собирали компьютеры в его подвале, мастерили «лестницы Якова [49]» в моем, учили друг друга программировать для PDP-8 и собирать настоящие калькуляторы из микросхем и транзисторов.

На работе мы программировали систему, которая использовала лазеры для высокоточной обрезки электронных компонентов (резисторов, конденсаторов и т. д.) В частности, мы нарезали кристаллы для первых цифровых часов, Motorola Pulsar.

Программирование велось на компьютере M365, клоне Teradyne PDP-8. Система писалась на ассемблере, а исходные файлы хранились на магнитных лентах. Хотя мы могли править код в экранном редакторе, процесс был достаточно сложным, поэтому для чтения кода и предварительной правки использовались в основном печатные листинги.

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

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

Исходная программа была достаточно простой. Она читала ленту, разбирала ассемблерный код, строила таблицу символических имен и добавляла в нее ссылки. Программа прекрасно работала, но была жутко медленной. Обработка главной операционной программы (MOP) занимала около часа.