Борьба с неизбежными проблемами устаревшего кода

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

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

Это заставило меня задуматься о нескольких вещах:

  • Неизбежно ли снижение ремонтопригодности кодовой базы со временем?
  • Что заставляет такой код гнить в реальном мире?
  • Как с этим бороться?

Поддерживаемость кодовой базы с течением времени

Недавно я прочитал сообщение Мартина Фаулера, в котором говорится о компромиссе между стоимостью производства и конечным качеством разрабатываемого программного обеспечения. Он ссылается на явление, когда со временем кодовая база заполняется все большим уровнем беспорядка, который он определил как: разница между текущим кодом и тем, каким он должен быть в идеале. Когда вы погружаетесь в кодовую базу, вы, вероятно, хотите как можно меньше мешать пониманию того, что делает этот код. Cruft - это то, что вы видите, когда открываете этот файл из 2000 строк, написанный 10 людьми, которых вы никогда не встречали, в течение 5 лет.

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

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

Однако его мысль несколько смягчилась, когда он заметил:

… Даже лучшие команды неизбежно будут создавать какие-то беспорядки в своей работе.

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

Код - это не единственное, что меняется

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

Бизнес-требования

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

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

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

Программные зависимости

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

Это может означать, что ваше программное обеспечение содержит критические уязвимости безопасности, исправленные в более современных итерациях включенных в него фреймворков или библиотек (на ум приходит Apache Struts). Опыт разработчика может пострадать от работы с этими зависимостями из-за уменьшения поддержки инструментов. Решение программной проблемы становится проблемой сохранения решения в рамках имеющихся зависимостей и инструментов, а не рассмотрения всех возможностей для наиболее эффективного и действенного решения проблемы.

Члены команды и сопровождающие

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

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

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

Чистый старт

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

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

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

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

Достижение устойчивого состояния

Поразмыслив над этим, вы можете сказать: «Если вы переписываете все каждые три года, то в какой-то момент вы не будете ничего делать, кроме как переписывать материал!»

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

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

  • Те же люди / команда все еще работают над программным обеспечением.
  • Никаких новых требований, соответствующих профилю существующего программного обеспечения, не поступает. Если требования достаточно разные, вы, вероятно, все равно напишете что-то новое.
  • Любой рефакторинг или обновление программных библиотек или фреймворков не приносит никакой дополнительной внутренней ценности разработчикам или внешней ценности для пользователей или бизнеса.
  • Переписывание программного обеспечения прямо противоречит интересам ваших пользователей (я не вижу, чтобы кто-нибудь каждый год пытался полностью переписать программное обеспечение автопилота самолета или системы управления ядерным реактором).

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

Выводы

«Изменения - единственная постоянная в жизни»

-Гераклит

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

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

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