Адаптированный перевод статьи от Рави Шанкар Раджан
Рави Раджан (Ravi Rajan) – глобальный менеджер ИТ-программ из Мумбая, Индия. Он также является заядлым блоггером, поэтом-хайку, энтузиастом археологии и маньяком истории. С Рави можно связаться через LinkedIn, Medium и Twitter.
6 минут чтения
Одним из моих первых уроков в качестве разработчика 15 лет назад было полученное короткое сообщение.
«Хороший код выразительный, а не впечатляющий»
Я помню, как спросил: “В чем разница?” , и мне объяснили.
«Выразительный» означает четкий, окончательный и конкретный. Поэтому написание выразительного кода обязательно должно решить конкретную проблему. На его создание стоит потратить время и силы, и он делает именно то, для чего предназначен.
«Впечатляющий», с другой стороны, означает штамп или отпечаток. Написание впечатляющего кода со сложными конструкциями и алгоритмами может потешить ваше эго и произвести вау-эффект, поднятые брови и хлопки, но может оказаться болезненным для тех, кто собирается поддерживать ваш код в будущем. И если он окажется психопатом, который знает ваш адрес, то только Бог сможет спасти вас от его гнева!
Вот почему хорошие разработчики умны, а не просто талантливы. Умный разработчик сочетает естественный интеллект со способностью судить о последствиях своих действий в будущем. Он точно знает, какой код пишет, почему, и как этот код повлияет на долгосрочную перспективу. Короче говоря, он не является разработчиком временных заплаток. Он верит в исправление болезни раз и навсегда.
Талантливые разработчики, с другой стороны, быстры, супер-быстры и знают все грязные способы в мире, чтобы заставить код «работать». Они сочетают в себе естественный интеллект и способность находить сверхзвуковые решения для каждой проблемы. Но со временем бинты и клейкая лента накапливаются, и однажды код просто рушится вместе с репутацией всех разработчиков, которые над ним работали. Вот почему Стив Макконнелл правильно сказал.
«Программирование – это не то же самое, что быть в ЦРУ, вы не получаете признания за хитрость ».
И умные разработчики не делают ничего подобного. Они пишут код, который скучен, прост и понятен. Ни больше ни меньше.
И вот некоторые замечательные вещи, которые делают именно умные разработчики.
Они пишут простой код.
Мартин Фаулер правильно сказал.
«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям»
У разработчиков иногда возникает ощущение, что им нужно что-то доказать. Им нужно показать другим, на что они способны. Это заставляет их искать сложные решения для каждой проблемы, в то время как самое простое решение лежит у них перед глазами. Это худшая ошибка, которую может сделать разработчик.
Умные разработчики пишут простой код. Простой код прост в обслуживании, оптимизации и изменении в будущем. Он не делает ничего сумасшедшего или неожиданного, и каждый, кто его читает, точно понимает, что этот код делает. Новые и необычные алгоритмы и подходы, как правило, отлично выглядят во время пятой чашки кофе, но с треском проваливаются в реальном времени.
Помните, что когда вы пишете код, и маленькая птичка по имени эго начинает искушать вас, задайте себе один простой вопрос.
« Если я вернусь поработать над своим кодом через 2 месяца, смогу ли я его понять?» Если ответ «да», сделайте это, но пожалейте своих коллег-программистов, вставляя соответствующие комментарии, называя переменные должным образом и применяя модули, так что это не будет нуждаться в пояснениях.
Хороший код похож на шутку. Если его нужно объяснять, это плохо.
Они знают, когда имеет смысл улучшать код.
Эдгар Дейкстра правильно сказал:
«Сфокусируйтесь на ПОЧЕМУ, а не на том, ЧТО в вашем коде сделает вас лучшим разработчиком»
Существует несколько способов оптимизации кода. Каждая из возможностей связана с использованием большего количества памяти, более быстрого выполнения или другого алгоритма / логики. И когда это возможно, умные разработчики делают этот выбор мудро.
Но прежде чем приступить к каким-либо действиям по улучшению кода, они следуют золотому принципу «не надо».
Зачем мне это делать? Программа уже достаточно хороша? Зная, как будет использоваться программа и в какой среде она работает, есть ли какая-то выгода в том, чтобы сделать ее быстрее? Вот некоторые вопросы, которые вы должны задать перед оптимизацией кода.
Да. Оптимизация имеет смысл только с точки зрения усилий и затрат, если программа важна, и она действительно медленная, и есть некоторые ожидания, что ее можно будет выполнить быстрее, сохранив надежность, правильность и ясность. Быстрая программа, которая дает неправильные результаты, никому не нужна. Эффективно оптимизированное программное обеспечение имеет больше преимуществ, чем недостатков, но если вы делаете оптимизацию неправильно, верно обратное.
Помните, что все, что вы улучшаете, должно быть измеримым. Интуиция – это всегда очень паршивое руководство, от которого нельзя зависеть.
Они поддерживают, а не строят код.
Вики Гандотра стукнул пальцем по голове и сказал:
“Вы начинайте кодировать. Я же пойду выясню, чего они хотят”
Умные разработчики делают именно это. Они начинают с поиска решения в том, что доступно. В то время как некоторым из нас нравится взбираться на «верховную лошадь» в восстановлении вещей «правильным путем», в большинстве случаев мы заканчиваем изнурительными усилиями по изобретению проклятого колеса.
Не бойтесь искать. Поиск уже реализованных решений в Интернете или в вашей базе данных кода очень полезен для изучения методов, распространенных в аналогичных ситуациях, и плюсов и минусов, связанных с ними. Вот почему умные разработчики тратят много времени на чтение кода перед написанием. Написание нового кода всегда дорого с точки зрения времени, денег и эмоциональной энергии. Не делайте этого, если это действительно не требуется.
Поэтому, когда вы начинаете решать задачу, проверьте, не решал ли ее кто-то еще. Вы не срезаете углы, вы сокращаете усилия.
Они бросают вызов самим себе.
Аристотель правильно сказал:
«Если то, что вы делаете, не бросает вам вызов, то это не меняет вас»
Умные разработчики ставят перед собой задачу, точнее код, который они написали при любой возможности. Они достаточно скромны, чтобы признать, что ни один код не является лучшим из когда-либо созданных.
Они не выбирают удобную колею и не используют один и тот же шаблон. Они сознательно избегают своих предпочтений в кодировании, чтобы кодирование не выродилось в слепую догму. Они всегда ищут пути и средства, чтобы сделать что-то лучше, и если это означает учиться чему-то новому, они всегда за.
Помните, умные разработчики не очарованы блестящими идеями или джазовыми функциями. Они достаточно прагматичны, чтобы понять, что не существует идеального решения, и каждая замечательная функция или удивительный хак имеют свои недостатки.
Наконец, они не боятся просить о помощи.
Софокл правильно сказал:
«Если бы мы всегда помогали друг другу, никому не понадобилась бы удача»
Как разработчикам, нам нравится думать о себе как о умных людях. На самом деле, некоторые из нас чистые гении. Но, сказав это, мы склонны думать, что знаем все и можем понять все сами. В конце концов, кто захочет сказать «я не знаю» на встрече? Кто захочет признать, что новая функциональность, которая будет развернута, для него китайская грамота?
Вместо этого вы говорите себе: “Я сам это выясню. Я всегда полагался на себя в прошлом. Я могу сделать это снова”.
Умные разработчики этого не делают. Они знают, когда обращаться за помощью, а когда использовать свой разум. Они точно знают, что любая дальнейшая задержка с просьбой о помощи приведет к беспокойству и впоследствии окажет давление на всех в команде, чтобы они уложились в сроки. Вот почему они не боятся разоблачать свое собственное невежество и просят помощи всякий раз, когда это необходимо.
Помните, что просьба о помощи – это не вопрос ваших возможностей. Это только укрепляет уверенность в вас других, что вы будете делать все возможное, чтобы завершить свою работу вовремя и с правильными результатами. Вы преодолеете эту опасную ловушку, как уверенный разработчик, который хочет каждый день меняться к лучшему.
Как правильно сказала Кубра Соль:
«Задавать вопросы – это первый способ начать изменения»
