Хороший разработчик мудр, а не гениален

Одним из самых важных уроков, которые я постиг в качестве разработчика 15 лет назад, была эта простая мысль:

Хороший код выразителен, а не впечатляющ.

Я помню, как услышав это спросил «А в чём разница?», и получил ответ.

«Выразительный» — понятный, однозначный и конкретный. А раз так, написание выразительного кода потребует работы с конкретной задачей. Вложение сил и времени в его создание служит конкретной цели, а результат соответствует ожиданию.

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

Именно поэтому хороший разработчик мудр, а не гениален. Мудрый разработчик обладает не только умом, но и способностью постоянно думать о последствиях своих действий. Он знает какой конкретно код пишет, для чего он это делает и, главное, как это код поведёт себя в будущем. Или, если проще, мудрый разработчик пытается лечить болезнь, а не симптомы.

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

Программирование — не работа в ЦРУ, вам не нужно быть смекалистым.

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

Вот ещё несколько принципов мудрых разработчиков.


Они предпочитают простоту

Мартин Фаулер однажды сказал:

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

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

Мудрый разработчик пишет прямолинейный код. Его легко поддерживать, оптимизировать и рефакторить при необходимости. Код не делает чего-то хитрого, каждый кто с ним сталкивается, сразу примерно понимает что происходит «под капотом». Передовые и необычные алгоритмы отлично проявляют себя во время ночного спринта на кофе и энергетиках, но сильно подводят чуть позже в продакшене.

Когда эго начинает потихоньку вас искушать во время программирования, спрашивайте себя: «Если я вернусь к работе с этим кодом через 2 месяца, смогу ли я вспомнить, что конкретно тут происходит?» Если ответ — «да», то дерзайте. Помните, однако, о своих коллегах, которым когда-нибудь придётся с этим кодом работать.

Код — он как анекдот. Если его нужно объяснять, он плох.
Они знают, когда (не)нужно оптимизировать код

Эдсгер Дейкстра однажды верно заметил:

Хороший разработчик сосредоточивается на том ДЛЯ ЧЕГО, а не на том С ПОМОЩЬЮ ЧЕГО при написании кода.

Тем не менее, есть много разных путей оптимизировать код. Каждый из них связан с изменением количества потребляемой памяти, процессорного времени и конкретного алгоритма. И мудрые разработчики выбирают этот путь прагматично.

Но прежде чем начать что-то улучшать, они следуют золотому правилу «не навреди».

С какой целью я собираюсь что-то менять? Возможно, программа уже прекрасно решает поставленную задачу? Учитывая, как именно и в каком окружении программа будет запускаться, есть ли вообще смысл делать её быстрее? На все эти вопросы надо ответить самому себе перед тем, как начинать оптимизацию.

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

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

Вик Гундотра попал в яблочко, как-то сказав:

Вы начинаете с написания кода. Я начинаю с поиска решения.

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

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

Так что при решении очередной задачи попробуйте сначала посмотреть, решал ли кто-либо её до вас. Вы не избегаете своей работы, вы избегаете ненужной работы.

Они стараются быть лучше

Аристотель сказал однажды:

Если вы работаете над чем-то, что уже умеете, вы не станете лучше.

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

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

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

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

Сократ произнёс:

Если бы мы постоянно помогали друг другу, никому бы не понадобилась удача.

Как разработчикам, нам нравится думать о себе как об умных людях. К тому же, среди нас и правда есть гении. Но мы так же склонны считать, что должны знать всё на свете. И правда, кому приятно сказать перед коллегами: «Я не знаю»? Кто захочет признаться, что новая технология для него — набор иероглифов?

Вместо этого вы тихо шепнёте себе: «Я разберусь в этом самостоятельно. Я уже делал так много раз раньше, смогу и сейчас.»

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

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

Как однажды заметила Кюбра Саит:

Положительные изменения начинаются с вопросов.

Оставить комментарий