Опыт работы в отрасли разработки программного обеспечения привел меня к заключению, что на практике разница между просто компетентными программистами и выдающимися программистами заключается в одном: это отношение к работе. Хорошее программирование требует профессионального подхода и стремления написать как можно лучший код с учетом ограничений, накладываемых окружающей действительностью и требованиями отрасли.
Код, ведущий в ад, вымощен благими намерениями. Чтобы стать отличным программистом, нужно отказаться от благих намерений и действительно проявить заботу о коде — воспитывать в себе позитивный взгляд на написание кода и вырабатывать здоровое отношение к работе. Выдающийся код есть плод тщательных усилий искусных мастеров, а не поделка, небрежно сляпанная программистом, или таинственное создание самопровозглашенных гуру от кодирования.
Вы хотите писать хороший код. Вы хотите быть хорошим программистом. Тогда вы должны стремиться к следующему:
• Какими бы ни были условия работы, вы отказываетесь наскоро писать код, который предположительно решает задачу. Вы стремитесь писать красивый код, корректность которого очевидна (и доказывается хорошо написанными тестами).
• Вы пишете код, доступный для понимания (другие программисты могут быстро разобраться в нем и продолжить работу), легкий в сопровождении (вы или другие программисты легко сможете модифицировать его в будущем) и верный (вы сделали все возможное, чтобы показать, что вы действительно решили задачу, а не просто создали видимость работающей программы).
• Вы хорошо ладите с другими программистами. Программист не должен быть отшельником. Редкий программист работает в одиночку: большинство трудится в составе команды программистов, будь то в рамках компании или проекта с открытым исходным кодом. Вы учитываете особенности других программистов и пишете код так, чтобы они могли его прочесть. Вы стремитесь помочь команде создать как можно лучший продукт, а не показать, какой вы умный.
• Когда к вам в руки попадает код, вы стараетесь, чтобы после вас он стал немного лучше (лучше организован, лучше протестирован, более понятен…).
• Вы любите код и программирование, поэтому вы постоянно изучаете новые языки, идиомы и новые приемы. Но применяете их только тогда, когда это уместно.
К счастью, вы читаете эти советы потому, что действительно любите код. Вам это интересно. Это ваше увлечение. Получайте удовольствие от программирования. Радуйтесь, написав код для решения сложной задачи. Пишите программы, которыми можно гордиться.
Ваши заказчики имеют в виду не то, что говорят
Нэйт Джексон
Я еще не встречал заказчика, который не был бы рад возможности рассказать мне, что ему нужно — обычно до мельчайших подробностей. Проблема в том, что заказчики не всегда рассказывают всю правду. В целом заказчики не лгут, но они говорят на своем языке заказчиков, а не на языке разработчиков. У них свой словарь и свой контекст. Они опускают важные детали. Они говорят так, будто вы тоже проработали в их компании лет двадцать. А осложняется это все тем, что на самом деле заказчики часто сами не знают, что им нужно! У одних есть понимание общей картины, но они редко в состоянии толково выразить свое представление. У других общее представление может быть менее ярким, но они знают, чего им не нужно. Так как же можно разработать программный проект для того, кто не способен правдиво рассказать, что именно ему нужно? Выход достаточно прост. Нужно больше взаимодействовать с заказчиком.
Начинайте задавать своим заказчикам вопросы как можно раньше, и задавайте вопросы чаще. Не стоит повторять их же словами то, что они сказали о своих пожеланиях. Помните: они имели в виду не то, что сказали вам. Я часто провожу такую проверку: в разговоре с заказчиком заменяю термины заказчика своими собственными и наблюдаю за его реакцией. Вы не поверите, как часто термин заказчик имеет смысл, совершенно отличный от термина клиент. Тем не менее человек, который объясняет вам, что он хочет видеть в программном продукте, считает эти слова взаимозаменяемыми и уверен, что вы понимаете, какой свой статус он имеет в виду в конкретный момент. А вас это дезориентирует, и качество вашей программы страдает.