97 этюдов для программистов. Опыт ведущих экспертов

Нужно заботиться о коде Пит Гудлиф

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

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

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

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

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

Вы хотите писать хороший код. Вы хотите быть хорошим программистом. Тогда вы должны стремиться к следующему:

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

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

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

• Когда к вам в руки попадает код, вы стараетесь, чтобы после вас он стал немного лучше (лучше организован, лучше протестирован, более понятен…).

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

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

Ваши заказчики имеют в виду не то, что говорят Нэйт Джексон

Я еще не встречал заказчика, который не был бы рад возможности рассказать мне, что ему нужно — обычно до мельчайших подробностей. Проблема в том, что заказчики не всегда рассказывают всю правду. В целом заказчики не лгут, но они говорят на своем языке заказчиков, а не на языке разработчиков. У них свой словарь и свой контекст. Они опускают важные детали. Они говорят так, будто вы тоже проработали в их компании лет двадцать. А осложняется это все тем, что на самом деле заказчики часто сами не знают, что им нужно! У одних есть понимание общей картины, но они редко в состоянии толково выразить свое представление. У других общее представление может быть менее ярким, но они знают, чего им не нужно. Так как же можно разработать программный проект для того, кто не способен правдиво рассказать, что именно ему нужно? Выход достаточно прост. Нужно больше взаимодействовать с заказчиком.