Одним из самых важных уроков, которые я постиг в качестве разработчика 15 лет назад, была эта простая мысль:
Хороший код выразителен, а не впечатляющ.
Я помню, как услышав это спросил «А в чём разница?», и получил ответ.
«Выразительный» — понятный, однозначный и конкретный. А раз так, написание выразительного кода потребует работы с конкретной задачей. Вложение сил и времени в его создание служит конкретной цели, а результат соответствует ожиданию.
«Впечатляющий» — код, который запоминается. Написание кода, запоминающегося своими сложными структурами и алгоритмами, хотя и почешет ваше эго, станет настоящей болью для того, кто будет поддерживать его в будущем. И если последний окажется маньяком, узнавшим ваш адрес, храни вас Господь от его гнева.
Именно поэтому хороший разработчик мудр, а не гениален. Мудрый разработчик обладает не только умом, но и способностью постоянно думать о последствиях своих действий. Он знает какой конкретно код пишет, для чего он это делает и, главное, как это код поведёт себя в будущем. Или, если проще, мудрый разработчик пытается лечить болезнь, а не симптомы.
«Гениальные» разработчики, так же обладая умом, напротив, думают лишь о настоящем. Они умеют решать текущие проблемы быстро и эффектно. Вот только гора от их хаков и выкрутасов постоянно накапливается и однажды обрушает код, хороня под собой репутации всех причастных. Вот почему Стив Макконнелл однажды верно заметил:
Программирование — не работа в ЦРУ, вам не нужно быть смекалистым.
И мудрые разработчики не делают ничего смекалистого. Они пишут скучный и простой код, который легко понять. Ни больше, ни меньше.
Вот ещё несколько принципов мудрых разработчиков.
Они предпочитают простоту
Мартин Фаулер однажды сказал:
Любой дурак может писать код понятный компьютеру. Хороший разработчик пишет код понятный человеку.
Иногда у разработчиков возникает желание самоутвердиться. Показать окружающим свой талант. И они начинают искать заумные решения для каждой встречной проблемы, хотя простое решение прямо под рукой. И это одна из худших ошибок, которую только может совершить разработчик.
Мудрый разработчик пишет прямолинейный код. Его легко поддерживать, оптимизировать и рефакторить при необходимости. Код не делает чего-то хитрого, каждый кто с ним сталкивается, сразу примерно понимает что происходит «под капотом». Передовые и необычные алгоритмы отлично проявляют себя во время ночного спринта на кофе и энергетиках, но сильно подводят чуть позже в продакшене.
Когда эго начинает потихоньку вас искушать во время программирования, спрашивайте себя: «Если я вернусь к работе с этим кодом через 2 месяца, смогу ли я вспомнить, что конкретно тут происходит?» Если ответ — «да», то дерзайте. Помните, однако, о своих коллегах, которым когда-нибудь придётся с этим кодом работать.
Код — он как анекдот. Если его нужно объяснять, он плох.
Они знают, когда (не)нужно оптимизировать код
Эдсгер Дейкстра однажды верно заметил:
Хороший разработчик сосредоточивается на том ДЛЯ ЧЕГО, а не на том С ПОМОЩЬЮ ЧЕГО при написании кода.
Тем не менее, есть много разных путей оптимизировать код. Каждый из них связан с изменением количества потребляемой памяти, процессорного времени и конкретного алгоритма. И мудрые разработчики выбирают этот путь прагматично.
Но прежде чем начать что-то улучшать, они следуют золотому правилу «не навреди».
С какой целью я собираюсь что-то менять? Возможно, программа уже прекрасно решает поставленную задачу? Учитывая, как именно и в каком окружении программа будет запускаться, есть ли вообще смысл делать её быстрее? На все эти вопросы надо ответить самому себе перед тем, как начинать оптимизацию.
Любая оптимизация имеет смысл только в контексте трудозатрат и отдачи, если программа важна, и она действительно медленная, и есть разумные основания полагать, что её можно оптимизировать, сохранив надежность, правильность и ясность. Программа выдающая ошибочные результаты никому не нужна, какой бы быстрой она не была. Хорошо оптимизированный код лучше не оптимизированного, но при неправильном подходе, верно прямо обратное.
Помните: любые изменения производительности при оптимизации нужно замерять. Интуиция в этом деле — плохой помощник.
Они предпочитают использовать, а не создавать код
Вик Гундотра попал в яблочко, как-то сказав:
Вы начинаете с написания кода. Я начинаю с поиска решения.
И мудрые разработчики следуют его примеру. Они начинают с поиска уже готового кода. Хотя некоторым и кажется, что они-то сейчас всё сделают с нуля «как правильно», большинство заканчивает банальным изобретением велосипеда.
Не стесняйтесь гуглить. Поиск решений, будь то онлайн или в собственной базе кода, полезен уже хотя бы с точки зрения изучения подходов, сработавших ранее в похожих задачах, а так же их плюсов и минусов. Вот почему мудрые разработчики проводят немало времени читая чужой код, перед тем, как начать писать собственный. Создание кода с нуля всегда стоит времени, денег и энергии. Не растрачивайте ресурсы, пока это и правда станет необходимо.
Так что при решении очередной задачи попробуйте сначала посмотреть, решал ли кто-либо её до вас. Вы не избегаете своей работы, вы избегаете ненужной работы.
Они стараются быть лучше
Аристотель сказал однажды:
Если вы работаете над чем-то, что уже умеете, вы не станете лучше.
Мудрые разработчики стараются усовершенствовать себя, а точнее свой код при каждой возможности. Они достаточно скромны, чтобы сознавать, что свой лучший код они ещё не создали.
Они не отсиживаются в зоне комфорта раз за разом используя один и тот же подход. Они всеми силами стараются, чтобы собственные привычки не стали для них догмой. Они постоянно ищут способы и возможности сделать лучше, особенно если смогут научиться чему-то новому в процессе.
Мудрые разработчики не очаровываются модными технологиями и крутыми фичами. Они достаточно прагматичны, чтобы понимать, что серебряной пули не существует и любой подход имеет свои плюсы и минусы.
Они не боятся просить помощи
Сократ произнёс:
Если бы мы постоянно помогали друг другу, никому бы не понадобилась удача.
Как разработчикам, нам нравится думать о себе как об умных людях. К тому же, среди нас и правда есть гении. Но мы так же склонны считать, что должны знать всё на свете. И правда, кому приятно сказать перед коллегами: «Я не знаю»? Кто захочет признаться, что новая технология для него — набор иероглифов?
Вместо этого вы тихо шепнёте себе: «Я разберусь в этом самостоятельно. Я уже делал так много раз раньше, смогу и сейчас.»
Мудрые разработчики так не поступают. Они знают, когда нужно думать самому, а когда нужно попросить помощи. Они уже знают, что затягивая с просьбой помочь, лишь убивают время до наступления дедлайнов, что повредит всей команде. А потому не боятся показаться некомпетентными и просят помощи тогда, когда это нужно.
Своевременная просьба о помощи не подорвёт веру коллег в ваши возможности. Она укрепит уверенность в вас, как в профессионале, готовом делать всё необходимое, чтобы уложиться в сроки и добиться качественного результата.
Как однажды заметила Кюбра Саит:
Положительные изменения начинаются с вопросов.
Автор: germn
