К сожалению, есть на свете и организации, в которых подобные подвиги ценят и вознаграждают. Но я смотрю на это по-другому.
Прежде чем я расскажу об этом, давайте на секунду отвлечемся вот на что.
Любую работу следует начинать с определения ее цели. Если вы пишете новый код, подумайте о том, как часто он будет выполняться. Подумайте о том, предназначена ли программа для использования внутри компании, или ей будут пользоваться клиенты. Подумайте о том, часто ли этой программе нужна будет поддержка. Подумайте об объеме обрабатываемых данных и т. д. Попытайтесь представить себе, какую роль будет играть этот код в продукте в целом.
Пример: я видел, как программисты целыми днями корпят над оптимизацией какого-то кода, который потом будут запускать от силы пару раз в неделю. Имеет ли значение, сколько времени занимает работа программы – 10 миллисекунд или 10 секунд? В некоторых случаях да, но обычно нет. Возможно, если писать код «небрежно», его будет легче читать и поддерживать, и к тому же вы быстрее все доделаете.
Концепция «код должен работать быстро» не так однозначна, как может показаться
Часто цель работы – угодить начальству, поэтому не воспринимайте мои слова чересчур серьезно и делайте все возможное, чтобы непосредственный руководитель был вами доволен. Это он отвечает за ваш карьерный рост, а не я. Тем не менее стоит знать, что скорость выполнения задач и строгость написания кода – не священный Грааль, как вам могли вбивать в голову в вузе.
Если вы программист или тимлид и хотите вынести из прочтения этой книги один урок, вот что я предлагаю запомнить:
Если в проекте работы на час, он будет готов через час. Если в нем работы на четыре часа, он займет день. Если в нем работы на день, он займет всю неделю. Если на неделю, он займет пару месяцев. Проекты, в которых работы на полгода и больше, как правило, не заканчиваются никогда.
Запишите это. Это один из самых важных уроков в разработке программного обеспечения.
Чем меньше получатся кусочки, из которых состоит ваш проект, тем быстрее вы справитесь. Поэтому, если вам поручили большой проект, начать стоит с разделения его на ряд более мелких. Разделяй и властвуй. Если у вас получится распределить силы по мелким проектам, вы уложитесь в рамки времени и бюджета. А если не сможете – придется искать оправдания, чтобы выкрутиться. На хороших оправданиях можно протянуть не один год, так что это не конец света. Но нет ничего плохого и в том, чтобы сразу победить.
Если вы тимлид, заставьте своих программистов описать подход к написанию кода. Не позволяйте им приступать к работе, пока они не разобьют проект на мелкие кусочки. Требуйте список задач.
Приготовьтесь услышать такую фразу: «Не учите ученого, не надо меня по мелочам контролировать». Я не раз слышал подобное, и не только от программистов. В ней есть доля правды. Отличных программистов не надо контролировать по мелочам. Тем не менее у отличных программистов к моменту начала работ уже будет выстроен план, а проект разбит на мелкие части. Если этого не было сделано, то стоит задуматься, так ли он хорош.
Еще одна популярная фраза, которую часто можно услышать от исполнителей: «Я не знаю, сколько времени это займет. В процессе». Я считаю такой ответ неприемлемым. Лучше было бы сказать: «Я сейчас потрачу пару дней на изучение кода, а затем составлю план работ. Вот тогда я смогу дать точные оценки по срокам».
Нет правил без исключений, но я куда больше ценю надежность, читабельность и поддерживаемость кода, чем скорость выполнения или «строгость». И если вы постоянно пишете код, пытаясь увидеть его глазами какого-то другого программиста, которому через пару лет предстоит вносить в него изменения, вы обнаружите, что работа как по волшебству завершается в срок и в рамках бюджета. Код будет быстрее отлаживаться и надежнее работать на продакшене[19].
И, как всегда, все начинается с «проще значит лучше». Лучший код выглядит до безобразия просто.
Обычно я начинаю написание кода с определения имен методов (подпрограмм)[20]. Мне нравятся функциональные блоки с именами, которые четко говорят, что такая подпрограмма делает – типа get_input_from_customer («принять ввод от клиента») или put_record_to_database («отправить запись в базу данных»). Я стараюсь, чтобы функциональность процедуры сводилась к тому, что указано в названии метода. Другими словами, в методе под названием validate_customer_number («проверить номер клиента») не надо делать ничего, кроме проверки номера клиента. Если для этого вам нужно выполнить какую-то другую работу, вызовите для нее другой метод. Постарайтесь, чтобы каждый отдельно взятый метод занимал не более двадцати строк кода. Если для проверки номера клиента нужно провести, например, проверку того, активен ли счет клиента, вызовите метод check_customer_account_active («проверить, активен ли счет клиента»). Не помещайте предназначенный для этого код в тот же самый метод. Зачем это делать, если и надо-то всего четыре или пять строк кода? Ответ такой: большинство программистов в состоянии написать несколько строк кода и заставить этот метод из нескольких строк работать с первой попытки. При этом метод из 25 строк требует экспоненциально больше времени для отладки, чем кусок кода на 20 строк. Уж поверьте: надо быть простым как валенок. Используйте до омерзения длинные имена переменных. И вы закончите работу быстрее, чем «вундеркинд» за соседним столом.
20
Для популярных языков программирования существуют целые стандарты оформления, описывающие оптимальное сопровождение кода (coding conventions). Они включают в себя правила наименования подпрограмм и переменных (то, о чем пишет Кен), форматирования строк и логических блоков, комментирования кода и т. п. –