Legacy — это слишком часто употребляемое токсичное слово в программной инженерии. В этой статье я утверждаю, что проблема не в программном обеспечении, а в людях, как обычно. Наследием является не код, а то, как мы на него смотрим, а это порождает беспомощность и дорогостоящее переписывание. Есть другой путь!
Как код становится устаревшим
Люди называют какой-то код legacy, когда они им недовольны. Обычно это означает, что не они писали его, поэтому не понимают его и не чувствуют себя в безопасности, изменяя его. Иногда это также означает, что код имеет низкое качество или использует устаревшие технологии. Интересно, что в большинстве случаев ярлык «legacy» относится к людям, которые его присваивают, а не к коду, который он маркирует. То есть, если бы авторы оригинала все еще были рядом, код вообще не считался бы устаревшим.
Эта модель позволяет нам определить факторы, которые способствуют или препятствуют тому, чтобы код стал legacy:
- Чем больше стаж программиста, тем меньше код становится legacy, поскольку авторы будут рядом, чтобы ценить и поддерживать его.
- Чем лучше код спроектирован, понятен и документирован , тем меньше он становится legacy, так как больше шансов, что автор сможет успешно передать его новому владельцу.
- Чем больше компания использует парное программирование, code review и другие техники передачи знаний, тем меньше код становится наследным, поскольку о нем знает не только его автор.
- Чем больше компания растит junior инженеров, тем меньше кода будет наследовано, поскольку лучший способ вырастить младших — передать им право собственности на компоненты.
- Чем больше компания использует простые стандартные технологии, тем меньше вероятность того, что код станет наследием, поскольку знания о них будут широко распространены в организации. По иронии судьбы, если вы определяете инновации как внедрение новых технологий, то чем больше команда внедряет инноваций, тем больше у нее наследия. Каждый раз, когда она внедряет новую технологию, либо она не сработает, и попытка станет наследием, либо она преуспеет, и наследием уже станут старые системы.
Причина, по которой устаревший код так распространен, заключается в том, что большинство команд недостаточно хороши во всем вышеперечисленном, чтобы избежать этого, но, возможно, вы можете стать лучше.
Будь хорошим инженером, не создавай legacy
Если мы не хотим убирать за другими людьми, то вполне разумно не создавать беспорядок для других.
Не пишите плохой код
Я определяю плохой код как код, который не может быть передан новому владельцу, и его приходится переписывать. Основная причина, по которой это происходит, заключается в том, что код недостаточно понятен. Это происходит не только из-за простой некомпетентности, например, плохой архитектуры или отсутствия тестов, но и из-за контрпродуктивных модных приемов, которые разработчики применяют бездумно. Две наиболее вредные из них — это представление о том, что хороший код не имеет комментариев, и что он должен использовать модные технологии, такие как микросервисы или многословные и сложные архитектурные паттерны.
Эвристика, которую я люблю использовать, чтобы не попасть впросак, — это вопрос: «Что самое простое может работать?». Затем я усложняю это только для решения реальных проблем. Отбить плохую идею вроде преждевременного внедрения микросервисов можно простым вопросом: «Какую проблему это решает?». Нет хорошего ответа — нет работы. И нет, «я бы хотел узнать о микросервисах» — это не та проблема, которую можно решить.
Не занимайтесь «инновациями»
Многие инженеры считают, что инновации — это внедрение современных технологий, например новых фреймворков и языков. Это ошибочное мнение порождает множество legacy кода, поскольку как только мы начинаем писать новые сервисы на Golang, все существующие, написанные на Javascript, становятся наследием.
Вместо этого я определяю инновации как решение новых проблем или решение старых проблем лучшим способом. Если вы внедряете новую технологию, которая этого не делает, я не называю это инновацией, я называю это игрой с чужими деньгами. Это фальшивая «инновация», которая создает наследие. Это работа, которая вместо решения проблем создает новые. Какое расточительство!
Заметьте, я не говорю, что вы никогда не сможете использовать новый язык. Я просто говорю, что он должен решать реальную проблему и быть лучшим способом ее решения. Например, если вы тратите миллионы долларов на обучение модели машинного обучения на Python, возможно, стоит переписать ее на Rust, чтобы сэкономить.
Учите других
Как я уже говорил, наиболее распространенная причина, по которой код становится наследием, заключается в том, что его создатель уходит, а новый сопровождающий не может его понять. Написание хорошего кода, конечно, может помочь, но научить новичка — еще лучше. Честно говоря, большинство профессиональных программистов не умеют хорошо кодить, но все они могут научить коллегу тому, как работает часть их кода. Обучение полезно не только для ученика, но и для учителя. Вы поймете, что объяснения заставляют вас задуматься и стать лучшим инженером. Наконец, наставничество — это основной навык Senior+ программистов, поэтому его развитие будет полезно для вашей карьеры.
Лучшая форма обучения — это работа в паре над кодом. Удивительно, чему может научиться новичок за 2 часа работы в паре, чтобы исправить сложную ошибку. Еще лучше работать в паре над новым кодом, так как ответственность будет разделена с самого начала.
Вторым по эффективности является обзор кода, который работает не так хорошо, потому что он медленнее, асинхроннее и требует письменного общения, в котором люди, как правило, хуже. Наконец, для этого нужен придирчивый рецензент с хорошим вкусом, а это редкие качества.
Уходите с честью
Хорошие инженеры создают не только хорошие, но и долговечные системы. Они следят за тем, чтобы о системах заботились даже после их ухода. Для этого они постоянно учат других, но особенно в тот момент, когда планируют уйти. Например, они предупреждают об уходе заблаговременно (за месяц или больше) и используют это время, чтобы подтянуть других и написать документацию.
Исправляйте чужое наследие
Как бы мы ни боролись с legacy, в нашей карьере оно обязательно появится, поэтому нам нужно знать, как лучше им распорядиться.
Не все является legacy
Я бы использовал слово «наследие» только в отношении систем, которые мы не понимаем и которые трудно изменить. Если система просто старая, но прекрасно работает, использование этого слова накладывает ненужное клеймо, которое может побудить к ошибочной переделке.
Если мы активно развиваем систему, нам не нужно слово для ее обозначения. Если ее развитие замедлилось или остановилось, можно сказать, что она находится в режиме обслуживания.
Измените
Поскольку проблема с унаследованным кодом заключается в том, что сопровождающий не понимает его, вы можете изменить ситуацию, просто изучив его. Он по-прежнему будет казаться вам дрянным , но вы сможете улучшать его со временем, добавлять новые возможности, добавлять тесты. Это может показаться менее гламурным, чем полный рерайт с использованием новой «горячей штучки», но это правильное решение для компании, и если мы будем постоянно делать правильные вещи, то заработаем репутацию и будем вознаграждены за это.
В редких случаях унаследованные системы действительно не подлежат восстановлению и должны быть выброшены, но вы можете быть уверены в этом только после глубокого понимания системы и ее проблем. То есть вам нужно попытаться изменить систему в течение нескольких месяцев, прежде чем вы сможете с уверенностью решить, что переписывание — лучший вариант.
Одной из хороших эвристик для принятия решения о переписывании является уверенность в том, что исправление системы потребует гораздо больше усилий, чем ее переписывание. Заметьте, что мы не можем быть в этом уверены, пока глубоко не разберемся в текущей системе и в том, сколько будет стоить написание новой.
Смиритесь или бегите
Кто-то должен исправить устаревший код, но это не обязательно должны быть вы. Гораздо почетнее сменить проект или компанию, чем возглавить ошибочное переписывание.
Если вы останетесь, вам может показаться, что это будет много боли без конца, но вы будете удивлены, насколько лучше может быть уже через год. Кроме того, вы сможете привлечь к работе больше Junior-разработчиков и передать им право собственности. Работа, которая для вас скучна и неблагодарна, для младшего инженера может стать захватывающей возможностью.
В заключение
В большинстве компаний полно legacy систем. Некомпетентные программисты создают их и оставляют беспорядок следующему человеку. У нового счастливчика не хватает моральных принципов, чтобы исправить беспорядок, поэтому он переписывает все заново, и цикл повторяется.
Вы можете разорвать этот цикл; вы можете позаботиться о том, чтобы не создавать унаследованные системы и делегировать те, которые вы нашли. Благодаря этому вы станете лучшим инженером, а рынок признает вас как человека, который решает проблемы, а не создает их. Ваша репутация вырастет, и вы будете достойно вознаграждены.