Главная

Хорошие разработчики крайне находчивы, но необязательно умны.

Умение правильно совмещать интеллект и способность судить о последствиях своих решений – залог стремительного профессионального роста.

1,013 

1+

Один из моих первых уроков, который я получил, работая в качестве программиста, состоял из простой фразы:
«Хороший код выразителен, но он не всегда впечатляет»
Я четко помню свое возражение: «И в чем же разница?». Мне ответили:
«Выразительный» — означает четкий, лаконичный и конкретный. Цель выразительного кода — решение определенной проблемы. Выразительный код решает только поставленную задачу и ничего более.
«Впечатляющий», в свою очередь, означает наличие какой-то нестандартной особенности. Да, возможно, написание впечатляющего кода удовлетворит ваше эго и заставит говорить «Вау» каждый раз, как только вы будете открывать код, но , с другой стороны, ваш «впечатляющий» код может стать проблемой для людей, которые будут заниматься поддержкой его в будущем.
Вот почему хороший разработчик должен быть рассудительным. Хороший разработчик умеет правильно совмещать интеллект и способность судить о последствиях своих решений. Хороший разработчик точно знает, какой код он пишет, зачем он его пишет и каким образом данный код повлияет на все остальное. Короче говоря, хороший разработчик не знает, что такое костыли. Он исправляет ошибку раз и навсегда.
Проворные разработчики, в свою очередь, пишут код быстро и знают практически все грязные способы, чтобы заставить код «работать». Они умеют совмещать естественный интеллект и способность находить сверхбыстрые решения для каждой проблемы. Но часто случается так, что «костыли» накапливаются и в какой-то момент весь код рушится вместе с репутацией разработчиков, которые его писали.

«Программирование — это не то же самое, что и работа в ЦРУ, вы не получаете признания за хитрость».

Стив Макконел

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

Не усложняй

«Любой дурак может написать код, понятный компьютеру. Хороший программист пишет код, понятный людям»

Мартин Фаулер

У разработчиков иногда возникает чувство, что им нужно что-то доказать. Им нужно показать другим, что они “могут”. Это заставляет искать сложные решения для любой проблемы даже в случае, когда самое простое решение будет у них перед носом. Сложное решение — худшее, что может сделать разработчик.
Хороший разработчик пишет простой и понятный код. Простой код проще поддерживать, оптимизировать и изменять. Код хорошего разработчика не делает ничего сверх необычного и впечатлительного и любой, кто посмотрит на этот код, поймет его.
Помните, что когда вы пишете код и маленькая птичка по имени эго начинает искушать вас, задайте себе один простой вопрос:
«Если я открою свой код через 2 месяца, смогу ли я его понять?» Пожалейте своих коллег – оставляйте комментарии, называйте переменные должным образом и, по возможности, разбивайте все на модули.

Качественный код как шутка. Если она хороша, то нет надобности в объяснении.

Хорошие разработчики знают, когда стоит вмешаться.

«Фокусируйтесь на ПОЧЕМУ, а не на том, ЧТО в вашем коде делает вас хорошим разработчиком».

Эдгар Дейкстра

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

Хорошие разработчики больше поддерживают код, чем пишут его.

«Вы начинаете кодить. Окей, а я лучше сначала выясню, чего конкретно от меня хотят.»

Вики Гандотра

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

Они бросают вызов самим себе.

«Если то, чем вы занимаетесь, не заставляет вас преодолевать трудности, то вы не развиваетесь в этом».

Аристотель

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

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

Они не боятся просить о помощи

Если бы мы всегда помогали друг другу, нужда в удаче отпала бы сама собой».

Софокл

Нам, разработчикам, нравится думать о себе как об умных людях и иногда нам трудно признавать свою некомпетентность. В конце концов, кто захочет сказать «я не знаю» на собеседовании? Вместо того, чтобы просто попросить о помощи, мы говорим себе: “Я сам это выясню. Я всегда полагался на себя в прошлом. Я могу сделать это снова.”
Хорошие разработчики так не поступают. Они знают, когда нужно обращаться за помощью, а когда действовать самому. Они точно знают, что задержка с просьбой о помощи может привести к дальнейшим проблемам. Хорошие разработчики не боятся разоблачать свое собственное невежество и просят помощи всякий раз, когда это необходимо.
Помните, что просьба о помощи — это не подрыв вашей репутации специалиста. Это доказательство того, что вы будете делать все возможное, чтобы решить проблему правильно и вовремя.

«Вопросы — это первый шаг к улучшению».

1+