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

Эта статья написана студентом и разработчиком, который открыт для получения любых знаний и передачи их в мои сети [Twitter], [Linkedin], [ Instagram], также доступна версия на бразильском португальском языке [Нажмите для доступа]

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

Это тема, которая никогда не перестает быть актуальной, день за днем ​​мы видим или слышим, что такой-то мучился с кодом в angular версии 1.4, или когда открываем свой Linkedin и видим десятки конкретных предложений для программистов с опытом работы в какая-то технология, которая не обновлялась более 5 лет или более, или нам просто нужно найти альтернативу этому случайному фрагменту кода в Jquery (да, братья мои, Jquery — это устаревшая технология).

Но что такое унаследованный код, и, что более важно, как мне избежать унаследованного кода?

Во-первых, устаревший код имеет некоторые характеристики, которые даже легко определить, если вы их увидите. Основные особенности:

  • сложность или невозможность обслуживания;
  • Баги, вызванные отсутствием лечения или поддержки используемой технологии;
  • Образец архитектуры неузнаваем;
  • Затрудненная масштабируемость.

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

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

  • Стандартизировать всю структуру и архитектуру кода;
  • Документ для потомков;
  • Сделайте свой код многоразовым;
  • Используйте технологии, которым доверяют;
  • Планируйте свои обновления;
  • Тесты всегда приветствуются;
  • Имплантируют культуру «СТАНДАРТ».

Стандартизируйте всю структуру и архитектуру кода

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

Стандартизация архитектуры и структуры всей системы может быть довольно трудоемкой в ​​зависимости от ее размера. Но это может принести огромную пользу. Для понимания я подготовил аналогию:

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

Я бы сказал, что это детская аналогия, но она очень подходит для контекста. Когда у вас нет стандарта, все делается дольше, будь то ошибки или новые реализации, и это происходит из-за того, что весь код запутан стандартами, которые иногда «создаются» людьми, которые даже не очень разбираются в этом. компания, и попытка исправить ошибки с грязным кодом в большинстве случаев не является приятным занятием, это требует времени и, возможно, не одной головы. На этом я хочу оставить поощрение очень клишированной фразой: «Время — деньги». И я считаю, что вы сэкономите гораздо больше времени, имея один стандарт для всей вашей системы. Для общего ознакомления прочтите книгу Роберта С. Мартина «Чистый код и чистая архитектура».

Документ для потомков

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

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

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

Сделайте свой код многоразовым

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

«Я буду использовать это позже в другом месте?»

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

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

Используйте технологии, которым доверяют

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

Видите ли, я не говорю, что ЗАПРЕЩЕНО использовать технологии, которые находятся в ажиотаже, я говорю о том, что некоторые моменты необходимо проанализировать, прежде чем использовать что-либо, что появляется со многими звездами в github. в вашей системе (тест бесплатный), а баллы таковы:

  • Это уже закрепившаяся на рынке технология или просто коллективный бред?;
  • У него есть постоянные исправления и обновления или коммиты, разделенные месяцами и даже годами?;
  • С помощью опроса достаточно крупные компании используют эту технологию или ее используют только коллеги по колледжу/разногласиям?
  • Это масштабируемая технология или у нее будут проблемы, когда в вашей системе будет много запросов и обращений?

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

Планируйте свои обновления

Вещи постоянно обновляются и меняются, и если вы и ваша система отстаете, мне жаль сообщать вам, что скоро она станет устаревшей. Одна из культур, которую я меньше всего вижу в компаниях, с которыми я контактировал, планирует обновить зависимости используемых технологий, хотя это трудоемко и может задержать планы, чрезвычайно важно, чтобы ваша система имела этот тип культуры. , так как ежегодно (если вы задумались над предыдущей темой) выходят десятки обновлений используемых вами технологий, и это вносит изменения даже в алгоритмы в вашей системе, недаром они называются ОБНОВЛЕНИЯМИ.

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

Тесты всегда приветствуются

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

Несмотря на то, что это более распространено, чем другие пункты, я вижу, что эта культура использует меньше, чем необходимо, во фронтенд-разработке (мое впечатление). Сегодня у нас есть много поддержки для реализации модульных тестов на интерфейсе, будь то e2e (end-to-end) или ориентированные на прикладную логику.

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

Имплантируют культуру «СТАНДАРТ».

Это несколько необычная практика, но очень эффективная, если вы разрабатываете с командой.

Речь идет о внедрении в команде культуры следования системному стандарту, прежде всего, будь то новые реализации или исправления / рефакторинги, это не означает, что новые стандарты не появляются с течением времени, но это означает, что команда будет объединены целью, будь то сохранение того, что есть сегодня, или внедрение чего-то нового.

Это не позволяет разработчикам безответственно кодировать и заставляет их думать во множественном числе, а не в единственном числе, что снижает вероятность устаревшего кода.

Заключение…

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