Основное внимание в этой статье уделяется интерфейсным технологиям, но концепции служат обоим мирам.
Эта статья написана студентом и разработчиком, который открыт для получения любых знаний и передачи их в мои сети [Twitter], [Linkedin], [ Instagram], также доступна версия на бразильском португальском языке [Нажмите для доступа]
Вам не нужно быть лучшим разработчиком в мире, чтобы знать, что унаследованный код — это призрак, который преследовал каждого разработчика или, по крайней мере, будет преследовать его в любой момент, и ничто похожее на передаваемый опыт не может предотвратить его появления. Я прошел через некоторые проблемы с командой разработчиков, в которой я участвую, для меня будет честью поделиться знаниями с вами, читатель.
Это тема, которая никогда не перестает быть актуальной, день за днем мы видим или слышим, что такой-то мучился с кодом в angular версии 1.4, или когда открываем свой Linkedin и видим десятки конкретных предложений для программистов с опытом работы в какая-то технология, которая не обновлялась более 5 лет или более, или нам просто нужно найти альтернативу этому случайному фрагменту кода в Jquery (да, братья мои, Jquery — это устаревшая технология).
Но что такое унаследованный код, и, что более важно, как мне избежать унаследованного кода?
Во-первых, устаревший код имеет некоторые характеристики, которые даже легко определить, если вы их увидите. Основные особенности:
- сложность или невозможность обслуживания;
- Баги, вызванные отсутствием лечения или поддержки используемой технологии;
- Образец архитектуры неузнаваем;
- Затрудненная масштабируемость.
Есть много других функций, которые определяют, что код является устаревшим, но наиболее очевидные из них описаны выше. Поскольку рассматриваемая статья направлена на то, чтобы показать, как не страдать от этого типа кода, объяснение каждой из этих характеристик необходимо будет объяснить в другой статье.
Наконец мы добрались до той части, где я объясняю необходимые практики, чтобы вы могли избежать головной боли в будущем или даже «сохранить» тот устаревший код, который вас преследует. Давайте поэтапно:
- Стандартизировать всю структуру и архитектуру кода;
- Документ для потомков;
- Сделайте свой код многоразовым;
- Используйте технологии, которым доверяют;
- Планируйте свои обновления;
- Тесты всегда приветствуются;
- Имплантируют культуру «СТАНДАРТ».
Стандартизируйте всю структуру и архитектуру кода
Во-первых, давайте согласимся, что только по названию «архитектура» и «структура» лучшее из миров должно быть только одним стандартом, но во многих ситуациях и примерах мы видим, что это не то, что происходит. Очень часто называемое «грязным кодом», отсутствие стандарта как в архитектуре, так и в структуре системы может вызвать множество головных болей, таких как сложность обслуживания, сложность обучения новых сотрудников, сложность масштабирования вашего приложения, потраченное время на простые ошибки и т.д.
Стандартизация архитектуры и структуры всей системы может быть довольно трудоемкой в зависимости от ее размера. Но это может принести огромную пользу. Для понимания я подготовил аналогию:
Представьте себе, что вы находитесь в офисе вашей компании, ваш начальник просит конкретный отчет за несколько месяцев назад, который хранился у вас, но вы, при ужасной организации, не знаете, где отчет. Вы ищете, ищете, и ничего не находите, следовательно, вашему начальнику это не нравится, и он требует от вас внимания.
Я бы сказал, что это детская аналогия, но она очень подходит для контекста. Когда у вас нет стандарта, все делается дольше, будь то ошибки или новые реализации, и это происходит из-за того, что весь код запутан стандартами, которые иногда «создаются» людьми, которые даже не очень разбираются в этом. компания, и попытка исправить ошибки с грязным кодом в большинстве случаев не является приятным занятием, это требует времени и, возможно, не одной головы. На этом я хочу оставить поощрение очень клишированной фразой: «Время — деньги». И я считаю, что вы сэкономите гораздо больше времени, имея один стандарт для всей вашей системы. Для общего ознакомления прочтите книгу Роберта С. Мартина «Чистый код и чистая архитектура».
Документ для потомков
Этот тип практики необходим, по крайней мере, для любого типа кода, и это утверждение касается не только внешнего интерфейса. Когда я говорю, что документирование необходимо, я не говорю, что мы просто должны комментировать наш код, на самом деле я имею в виду, что мы должны сделать наш код понятным для возможных других программистов, которые могут анализировать/писать то же самое, и комментировать это способ сделать это, но это не единственный способ, есть много способов документировать наш код, даже по причинам, что иногда комментариев недостаточно, чтобы сделать код понятным, и очевидно, что комментарии сверх необходимого могут повредить нашей структуре.
Что касается способов документирования, у нас есть несколько способов, которые могут варьироваться от языка к языку, от структуры к структуре, от методологии к методологии и т. д., то есть всегда читайте передовые методы документирования технологии, языка и т. д., которые вы используете. с использованием.
Наконец, всегда помните, что ваш код может быть доступен другим разработчикам, поэтому оставляйте его так, чтобы его поняли все старшие.
Сделайте свой код многоразовым
Ментальность, которая мне нравится, заключается в том, что я должен думать о коде всякий раз, когда мой код может стать гигантской системой или даже экосистемой, это заставляет меня переосмысливать каждую строчку, которую я пишу:
«Я буду использовать это позже в другом месте?»
Кодирование, думая о повторном использовании, меняет все, потому что вместо того, чтобы просто решить проблему, вы решаете набор проблем, область применения меняется от простого файла до системы в целом, осмелюсь сказать, что принцип повторного использования, особенно во фронтенде, очень важно, потому что это делает наш код намного чище и компактнее.
Поэтому я призываю вас выполнять это упражнение всякий раз, когда вы программируете, думайте: «Можно ли это использовать повторно?» или даже «Есть ли уже решение этой проблемы в системе?», это внесет экономичность и простоту в ваш код.
Используйте технологии, которым доверяют
Всякий раз, когда мы собираемся решить, какие технологии будут использоваться в проектах, мы, к сожалению, склонны увлекаться «хайпом» (особенно во фронтенде). И это удар под дых, потому что, хотим мы этого или нет, нам нравится использовать то, что используют все, но это может быть решение, которое повлияет на всю вашу систему из-за того, что многое из того, что сегодня является «рекламой», вполне может быть не завтра.
Видите ли, я не говорю, что ЗАПРЕЩЕНО использовать технологии, которые находятся в ажиотаже, я говорю о том, что некоторые моменты необходимо проанализировать, прежде чем использовать что-либо, что появляется со многими звездами в github. в вашей системе (тест бесплатный), а баллы таковы:
- Это уже закрепившаяся на рынке технология или просто коллективный бред?;
- У него есть постоянные исправления и обновления или коммиты, разделенные месяцами и даже годами?;
- С помощью опроса достаточно крупные компании используют эту технологию или ее используют только коллеги по колледжу/разногласиям?
- Это масштабируемая технология или у нее будут проблемы, когда в вашей системе будет много запросов и обращений?
Эти и другие вопросы приходится задавать (разные от системы к системе), чтобы потом не было головной боли, особенно при выборе новой технологии в середине существующей системы.
Планируйте свои обновления
Вещи постоянно обновляются и меняются, и если вы и ваша система отстаете, мне жаль сообщать вам, что скоро она станет устаревшей. Одна из культур, которую я меньше всего вижу в компаниях, с которыми я контактировал, планирует обновить зависимости используемых технологий, хотя это трудоемко и может задержать планы, чрезвычайно важно, чтобы ваша система имела этот тип культуры. , так как ежегодно (если вы задумались над предыдущей темой) выходят десятки обновлений используемых вами технологий, и это вносит изменения даже в алгоритмы в вашей системе, недаром они называются ОБНОВЛЕНИЯМИ.
Отсутствие планирования, по крайней мере, каждые шесть месяцев обновлений вашей системы приведет даже к выходу за рамки «устаревшего» и может привести к поломке вашей системы в зависимости от обновления. Поэтому я настоятельно рекомендую отложить некоторые планы, чтобы это произошло.
Тесты всегда приветствуются
К счастью, это реальность, немного более распространенная среди нас, разработчиков и компаний, но я не могу не поговорить на эту тему, поскольку она так важна для рассматриваемой темы.
Несмотря на то, что это более распространено, чем другие пункты, я вижу, что эта культура использует меньше, чем необходимо, во фронтенд-разработке (мое впечатление). Сегодня у нас есть много поддержки для реализации модульных тестов на интерфейсе, будь то e2e (end-to-end) или ориентированные на прикладную логику.
Такая необходимая практика больше не подлежит обсуждению, отсутствие тестирования может привести к преувеличенным рефакторингам, пустой трате времени на ненужные ошибки, потере качества кода и так далее. Поэтому реализация тестов на вашей системе уже давно должна была стать реальностью.
Имплантируют культуру «СТАНДАРТ».
Это несколько необычная практика, но очень эффективная, если вы разрабатываете с командой.
Речь идет о внедрении в команде культуры следования системному стандарту, прежде всего, будь то новые реализации или исправления / рефакторинги, это не означает, что новые стандарты не появляются с течением времени, но это означает, что команда будет объединены целью, будь то сохранение того, что есть сегодня, или внедрение чего-то нового.
Это не позволяет разработчикам безответственно кодировать и заставляет их думать во множественном числе, а не в единственном числе, что снижает вероятность устаревшего кода.
Заключение…
В дополнение к практикам, приведенным в качестве примеров выше, существует множество других, различающихся методологией и культурой. Принцип, который я действительно хочу оставить вам, читатели, заключается в том, что кодирование не является чем-то исключительным и эгоистичным, поэтому всегда думайте о будущем вашей системы и ваших коллег-разработчиков. Очевидно, что мы не должны верить в утопию, что мы можем избежать любой головной боли, но необходимо сделать самый минимум, чтобы избежать устаревшего кода.