Как написать код на потом
2 быстрых победы в написании поддерживаемого кода
Я не собираюсь говорить вам писать поддерживаемый код.
Написание хорошо отточенного, поддерживаемого кода в некоторых ситуациях не имеет смысла.
Может быть, вам просто нужно отправить код как можно быстрее (не имеет значения, насколько удобен ваш код, если ваш стартап зависит от MVP для финансирования).
Или, может быть, это потребует больше усилий, чем того стоит.
Чтобы расширить это, взаимосвязь между усилием и результатом имеет тенденцию быть логарифмической в стремлении обеспечить ремонтопригодность части кода - это может быть класс или вся кодовая база.
Возьмем для примера класс.
Не требуется много усилий, чтобы правильно назвать переменные, и, как правило, писать код, с которым легко работать в этом классе.
В этих случаях рентабельность инвестиций огромна.
Разработчикам становится легко работать в этом классе для большинства видов работы.
Однако после определенного момента отдача все больше и больше зависит от способов, которыми вы собираетесь масштабировать кодовую базу.
Именно в этот момент мы должны больше думать о более широком контексте и траектории бизнеса в целом.
Да, преобразование этого класса в более модульные классы будет улучшением, но какой ценой? Только сделайте двадцать пять уроков, и нам нужно будет принять более серьезное решение.
Написание поддерживаемого кода всегда будет объективно лучше, но, преследуете ли вы определенную степень доработки кода, зависит от конкретных обстоятельств.
Вот почему я хотел бы сосредоточиться на левой части этой логарифмической кривой: быстрых выигрышах, которые может использовать каждый разработчик для написания поддерживаемого кода.
Быстрые достижения в написании поддерживаемого кода небольшие, но очень эффективные вещи, которые вы можете делать каждый день, чтобы предвидеть будущее и помочь минимизировать количество усилий, необходимых для будущих изменений кода.
Это целенаправленно исключает такие вещи, как широкие архитектурные решения и крупномасштабный дизайн API.
Не поймите меня неправильно: соответствующие фреймворки и принципы модульного дизайна создают основу для поддерживаемого кода, но после того, как эти каркасы будут созданы, наша задача создать стабильную структуру, которая будет максимально ориентирована на будущее.
Тем не менее, давайте рассмотрим эти два простых способа защитить наш код в будущем.
1. Напишите читаемый код.
Если вы думаете, что код предназначен только для интерпретации машиной - и если он работает, вы закончили свою работу в качестве разработчика - вам нужно сделать шаг назад.
Если это вы, я гарантирую, что другие разработчики (в том числе и вы!) Будут ломать голову, пытаясь расшифровать то, что вы написали шесть месяцев назад.
Будьте уверены, что этого снижения времени можно избежать, просто написав в первую очередь читаемый код.
Итак, как мне узнать, читается ли мой код?
Вообще говоря, вы должны иметь хорошее представление о том, что делает код, просто глядя на имена классов / функций / переменных.
(Хорошее именование - один из самых недооцененных инструментов, которые у нас, как у разработчиков, есть для обеспечения поддерживаемого кода.)
Вот пример плохого и хорошего именования:
Просматривая приведенный выше код, я не знаю, что делает первая функция. Он что-то подтверждает, но я не знаю, что именно. И какие данные он возвращает?
С другой стороны, даже не видя содержимого, я могу сделать вывод, что вторая функция возвращает логическое значение, которое истинно, если тележка подходит для промо.
В результате единоличной ответственности функции, как правило, меньше и с ними легче работать.
Все это говорит о том, что если вы изо всех сил пытаетесь назвать функцию, скорее всего, она слишком велика или пытается сделать слишком много.
Таким образом, у хорошего нейминга есть двоякие побочные эффекты:
- Вы, естественно, создаете функции с единственной ответственностью, что лучше для гибкости кода и тестирования.
- В результате единоличной ответственности функции, как правило, меньше по размеру и с ними легче работать.
Именование может показаться мелочью, но на самом деле это мощный инструмент для обеспечения ремонтопригодности кода.
2. Напишите многоразовый код.
Как и написание читаемого кода, написание повторно используемого кода - это относительно небольшие усилия, которые могут избавить от головной боли в будущем.
Как?
Взгляните на этот фрагмент кода внутри функции:
Этот фрагмент кода извлекает значение cookie клиента.
Скажем, например, нам нужно извлечь значение другого файла cookie (sessionId) в другой функции.
У нас может возникнуть соблазн продублировать приведенный выше код, заменив «customer» на «sessionId»:
Подожди секунду…
Вместо этого мы можем использовать подход многократного использования.
Единственное, что различается между двумя вариантами использования, - это имя файла cookie: customer vs sessionId.
Итак, мы можем выделить общую логику в отдельную функцию, которая принимает имя файла cookie в качестве параметра:
Эта абстракция обеспечивает большую гибкость для будущих потребностей.
Например, что, если бы мы хотели заменить реализацию получения файла cookie с помощью пользовательского регулярного выражения на использование внешней библиотеки?
Теперь нам нужно заменить только один экземпляр, а не несколько мест в коде.
Таким образом, ключом к написанию многоразовых функций является предвидение этих будущих потребностей до их возникновения.
Задайте такие вопросы, как:
- Что, если мы решим использовать здесь другую библиотеку?
- Будет ли это жестко заданное значение применяться в других случаях использования?
- Является ли этот тип данных универсальным для возможных будущих вариантов использования?
- Может ли эта же логика использоваться в другом коде в будущем?
- Можно ли извлечь уже повторяющуюся логику между отдельными функциями?
Похоже, есть над чем подумать.
Но как только вы попрактикуетесь внедрять такое мышление в свою повседневную работу, вы удивитесь, насколько легко оно приживается.
Начните с правильного именования, а затем переходите к написанию повторно используемого кода. Прежде чем вы это узнаете, вы будете писать код не только для сейчас, но и для позже.
