Посмотрим правде в глаза, мы пишем программное обеспечение уже несколько десятилетий. Мы больше не можем претендовать на роль нового домена и выдавать рождение в качестве оправдания за отправку небрежного кода.
Большинство из нас может отличить хороший код от плохого, но как нам создать красивое программное обеспечение, а не просто читать о нем?
Что ж, давай попробуем здесь.
Эта статья не научит вас дзен обслуживания программного обеспечения. Скорее это просто дамп из памяти, отсортированный в псевдослучайном порядке для обеспечения сохранности данных. Надеюсь, что по пути будет реализована некоторая ценность.
Сочувствуйте через код
Говорите, чтобы другие слушали… пишите, чтобы другие читали
В краткости есть элегантность. Кодовый гольф может помочь вам выиграть JS1k, но незаписанные строки всегда будут отсутствовать. Пустые пропасти служат большим препятствием для совместной работы, чем самые длинные блоки обфускации.
Даже при написании простой оболочки для извлечения данных я всегда находил полезным оставлять комментарии в качестве маркеров на следе. Несколько удачно размещенных комментариев могут сэкономить много человеко-часов на поиск с возвратом и изучение вопросов, особенно в командах с высокой степенью сотрудничества.
Когда количество задействованных разработчиков n превышает одного, потребность в ясности становится неоспоримой для крупных проектов. Загвоздка в том, что n не является мгновенным измерением. Даже если через несколько месяцев код проверяет тот же человек, n становится больше 1, и правило по-прежнему применяется.
(Не делать) Переписывать, чтобы обновить
Проекты, в которых не учитывается потребность в инклюзивности, редко обновляются. Скорее, обновления функциональности и даже незначительные исправления доставляются путем перезаписи системы.
Как и многие программисты, я иногда пишу свежий код, а не читаю старый. Это можно понять как побочный эффект невыполнения требований предыдущего раздела, но при разработке программного обеспечения это все еще неоправданное решение.
Старый код, вероятно, дает много гарантий, которых нет в вашем новом решении. Во-первых, существующий код работает, в то время как ваш все еще находится в домене теоретически быстрее. У нас есть ПО для контроля версий, пользуйтесь ими.
Удалите свой путь к совершенству
На каждом каменном блоке есть статуя… задача скульптора - открыть ее.
- Микеланджело, наверное,
Гордитесь удалением строк кода. Я с нетерпением жду дней, когда в моих git коммитах будет больше красного, чем зеленого. Многословие не является обязательной зависимостью для ясности. Фактически, устранение неактуальных путей принятия решений и сокращение циклических циклов выполнения улучшают читаемость и сокращают пространство поиска по мере появления ошибок в будущем.
Если ваш менеджер когда-нибудь спросит вас, сколько строк кода вы добавили в проект, у меня есть только один совет - бегите; быстро и в обратном направлении.
Абстракции не вечны
Все мы любим абстракции, они спасают нас от повторений, позволяют нам стоять на плечах гигантов и являются секретом того, как стать 10-кратным рок-звездой-ниндзя. Ладно, если не считать шуток, я должен признать, что абстракции - действительно ценные инструменты. Они позволяют нам использовать существующий код в качестве предположений, которые можно абстрагироваться при написании кода более высокого уровня.
Однако вы наверняка слышали и о Законе дырявых абстракций. Если нет, то ссылка тут же, я подожду, Джоэл писатель намного лучше меня.
Понимание стоимости абстракции - важный шаг на пути разработчика. Умение искать скрытые издержки - важный шаг в росте программиста. Чем раньше будет осуществлено осознание, тем легче будет пробудиться от обманчивых фантазий.
Один из моих ответов на противоположный вопрос Питера Тиля - это мнение о том, что грубое накопление направленной практики становится неотличимо от врожденного таланта.
Прилагая согласованные усилия по написанию лучшего кода с каждым днем, я надеюсь достичь точки, в которой разработка программного обеспечения будет проходить гораздо более жесткий этап выполнения от мысли до кристалла.
Первоначально опубликовано на сайте hackernoon.com 18 октября 2017 г.
