Напишите код, который легко удалить, а не расширить
Каждая строчка написанного кода имеет свою цену: обслуживание. Чтобы не платить за большой объем кода, мы создаем многоразовое программное обеспечение. Проблема с повторным использованием кода заключается в том, что позже он мешает вам передумать.
Чем больше у вас потребителей API, тем больше кода вам придется переписать, чтобы внести изменения. Точно так же, чем больше вы полагаетесь на сторонний API, тем больше вы страдаете, когда он изменяется. Управление тем, как код сочетается друг с другом или какие части зависят от других, является серьезной проблемой в крупномасштабных системах, и она становится все труднее по мере того, как ваш проект стареет.
Когда мы удаляем строки кода, мы снижаем стоимость обслуживания. Вместо того, чтобы создавать многоразовое программное обеспечение, мы должны попытаться создать одноразовое программное обеспечение.
Мне не нужно говорить вам, что удаление кода веселее, чем его написание.
Шаг 0: не пишите код
Количество строк кода само по себе мало что говорит нам, но величина говорит: 50, 500, 5000, 10000, 25 000 и т.д. Монолит из миллиона строк будет более раздражающим, чем один из десяти тысяч строк.
Самый простой код для удаления — это код, который вы изначально избегали писать.
Шаг 1. Скопируйте и вставьте код
Создание повторно используемого кода — это то, что легче сделать задним числом с парой примеров использования в базе кода, чем предвидеть те, которые вам, возможно, понадобятся позже.
Лучше скопировать и вставить код пару раз, а не создавать библиотечную функцию, просто чтобы понять, как она будет использоваться. Как только вы сделаете что-то общим API, вам будет сложнее изменить.
Удалить код внутри функции проще, чем удалить функцию.
и т.д. (в полной версии статьи)…
Вы скопировали, вы реорганизовали, вы наслоили, вы составили, но код все равно должен что-то делать в конце дня. Иногда лучше просто сдаться и написать значительный объем мусорного кода, чтобы скрепить все остальное.
Бизнес-логика — это код, характеризующийся бесконечной серией крайних случаев и быстрых и грязных хаков. Это отлично. Я согласен с этим. Другие стили, такие как «игровой код» или «код основателя», — это то же самое: срезание углов для экономии значительного количества времени.
Причина? Иногда проще удалить одну большую ошибку, чем пытаться удалить 18 мелких чередующихся ошибок. Во многих случаях программирование носит исследовательский характер, и быстрее ошибиться несколько раз и повторить итерацию, чем думать, что все получится правильно с первого раза.
Это особенно верно в отношении более веселых или творческих начинаний. Если вы пишете свою первую игру: не пишите движок. Точно так же не пишите веб-фреймворк перед написанием приложения. Иди и напиши в первый раз «лажу». Если вы не экстрасенс, вы не будете знать это.
Оригинал: Write code that is easy to delete, not easy to extend
Что думаете?
Эта статья напоминает мне кое-что, о чем я думал на днях. И читать лучше полную статью. Основные операции программирования:
Из них рефакторинг, безусловно, самый сложный. Есть ли подход, который может использовать это наблюдение для упрощения разработки? Тут я не знаю.
А так, я не считаю код артефактом, который нужно сохранить, и идея «потраченных строк» действительно находит отклик у меня.