[Перевод] Почему некоторые проекты угасают после ухода программиста из компании
Зачастую судьба цифрового продукта заботит не только компанию, которой он принадлежит, но и специалистов, непосредственно участвовавших в его разработке. Для многих программистов (и команда beeline cloud — не исключение) проект, к которому они приложили руку, — это не просто набор кода, а настоящее детище, чья судьба не перестает волновать даже после ухода из компании. Перевели для вас статью, которая поможет обеспечить своему начинанию долгую жизнь.
В статье речь пойдет об одной из основных причин гибели проекта после ухода программиста. Несколько практических примеров из реальной жизни помогут вам избежать подобной ситуации.
Предисловие
Вам никогда не приходилось задумываться о судьбе проекта, над которым вы работали в какой-нибудь компании?
Лично я всегда интересуюсь у бывших коллег, в каком состоянии мое «детище» и поддерживается ли оно до сих пор.
И дело вовсе не в самолюбии. Мое желание узнать, что проект, в который я вложил столько времени, развивается и служит своей цели, довольно логично.
Недавно мне довелось участвовать в рефакторинге кода. Хочу рассказать о причинах его проведения.
Таким образом, тему статьи так и обозначу: причины рефакторинга.
Безусловно, моё личное мнение должно соотноситься с вашим опытом и тем, как ваша компания работает над структурированием и сопровождением проектов.
Долг программиста в написании кода — максимально использовать в нем все свои способности. И делать упор не только на функционал, но и на удобство последующего сопровождения, ориентируясь на долгосрочную перспективу.
Что приводит к решению «проект подлежит рефакторингу»
Ответ не начертан на скрижалях. Существует множество причин для вынесения подобного вердикта.
Основываясь на собственном опыте, постараюсь рассказать о некоторых из них.
Вы концентрируетесь лишь на том, чтобы ваш код работал
Нет ничего плохого в том, чтобы заставить его работать так, как планировалось. В конце концов, в этом и заключается основная поставленная задача.
Проблемы начинаются, когда возникает необходимость в новых фичах. Как и для любого живого существа (а мы можем считать нашу систему живым существом), эволюция в проекте неизбежна.
Таким образом, код должен быть готов к тому, чтобы меняться и расти согласно новым задачам и потребностям. В противном случае он обречен на рефакторинг или, что еще хуже, на отказ от него.
Неорганизованный проект с запутанными именами
Чтение кода не должно быть пыткой. Однако навигация по пакетам и папкам в некоторых проектах вовсе не способствует пониманию, а лишь ужасает.
Проект, в котором зависимости перемешаны или плохо структурированы, со стопроцентной уверенностью можно пометить как «требующий рефакторинга».
При организации кода я стараюсь поставить себя на место другого человека. Легко ли следовать структуре моих модулей и пакетов? И если я уйду в отпуск, сможет ли мой коллега легко разобраться во всём и заменить меня?
Однозначно ответить сложно. У людей отличается мышлений, и у каждого программиста свой подход к работе.
Отсутствие документации или ее низкое качество
Это как раз про меня.
Я уже писал, что всегда интересуюсь судьбой своего проекта, даже если ушел из компании. Одна из причин моего интереса — беспокойство о том, что я не уделил должного внимания документированию. Мне всегда кажется, что можно было сделать лучше.
К документированию кода можно подходить по-разному. Создание полной сквозной документации, отражающей, как система работает в целом, на мой взгляд, будет наилучшим решением.
Чтобы над проектом мог работать другой программист (после вашего ухода из компании или просто ваш коллега), не ленитесь снабжать код комментариями — это правило хорошего тона.
Некоторые инструменты позволяют создавать документацию на основе комментариев в коде.
Жестко прописанные значения и отсутствие структуры данных
Иногда вполне допустимо жестко прописывать некоторые значения.
Но когда проект напичкан ими, его чертовски сложно масштабировать без страха что-то сломать.
Если вы не знаете, о чём идёт речь, постараюсь объяснить.
Хардкод — принудительное присвоение переменной определенного значения вместо того, чтобы присваивать его динамически.
username = "yanick_user" # hardcode value for username
role = "admin" # hardcode value for roleЭто неправильно! А если имя пользователя изменится? Или после ухода пользователя из компании его просто отключат? Что делать, если понадобится сменить тип учётной записи?
Каждый раз придется лезть в код! Теперь представьте себе кошмар в сценарии, где существуют каскадные зависимости.
Всё может сразу пойти наперекосяк.
import os
username = os.getenv("USERNAME")
role = os.getenv("ADMIN_ROLE")Еще один очень важный момент — хорошо продуманная структура данных. Понимание важности структуры данных может существенно помочь в написании кода.
Чётко представляя, какие данные будет обрабатывать ваша система, вы облегчите задачу для себя, интерпретатора и тех, кто будет работать над вашим проектом.
def do_something(args):
if args.get("some_key") == "admin":
user = args.get("user_key")
...Не знаю, как для вас, но для меня это очень трудный для понимания код. Что такое здесь args? Можно ли получить от args другие ключи? Какой из них является обязательным?
В Python, используя класс данных (dataclass), очень легко описать объект, если вы знаете его структуру:
from dataclasses import dataclass
class Myclass:
user_key: str
some_key: strТеперь вы можете реорганизовать предыдущую функцию do_something и упростить ее выполнение:
import os
ADMIN_ROLE = os.getenv("ADMIN_ROLE")
def do_something(args: Myclass):
if args.some_key == ADMIN_ROLE:
user = args.user_key
...Пренебрежительное отношение к тестам или полное отсутствие таковых
И еще попадание в цель. Опять про меня.
Сказать по правде, добросовестно писать тесты я начал только после перехода к нынешнему работодателю.
Теперь-то я на практике понимаю важность их написания. Этим мы убиваем сразу двух зайцев. Во-первых, проверяем работоспособность кода, во-вторых, получаем прекрасное руководство по использованию системы и взаимодействию с ней. По возможности не игнорируете написание тестов.
Итак, как же уберечь свой проект от угасания?
Вопрос сложный, и, может, кто-нибудь сумеет на него ответить лучше меня со 100% уверенностью.
Несомненно одно — если вы примите к сведению мои рекомендации с учетом своего личного опыта, то окажетесь на правильном пути.
Да, я не безгрешен, но всегда стараюсь следовать лучшим практикам проектирования систем.
Периодически заглядываю в PEP (Python Enhancement Proposals) и читаю предложения по улучшению Python. Здесь всегда есть возможность узнать что-то новое и интересное. Python — быстро развивающийся язык программирования, и я стараюсь идти в ногу со временем.
Может и вы вспомните что-то из личного опыта? Возможно, кому-нибудь это поможет избежать чёрной метки «Требует рефакторинга».
Больше практических историй про решение ИТ-задач:
Для разработки качественных и безопасных приложений компании нужно подобрать подходящий способ поиска и устранения уязвимостей. Чтобы его выбрать, можно оценить разные методики тестирования по четырем критериям: сложности внедрения, влиянию на время жизненного цикла ПО, а также ложноположительным и ложноотрицательным срабатываниям.
Делимся статьей-сравнением с наглядными графиками, которые помогут решить, какой инструмент подойдет именно вам: SCA, SAST, DAST или IAST?
Читать
Миграция с зарубежного ПО на российское часто становится проблемой для крупных компаний с большим количеством бизнес-процессов и данных. Рассказываем, как реализовать такой переход. Внутри — полезные рекомендации для тех, кому миграция только предстоит.
Читать
Как развернуть CRM за 7 шагов?
CRM помогает компании провести клиентов от знакомства до формирования лояльности, не теряя по пути информацию и автоматизируя часть процесса. Рассказываем, как за 7 шагов внедрить CRM-платформу так, чтобы сотрудники не перестали ей пользоваться.
Читать
