Мир программного обеспечения
Важность владения кодом
Хороший код — это хорошо поддерживаемый код
«Ты пишешь это; ты владеешь им». Это философия отдела разработки программного обеспечения, в котором я когда-то работал. Это отличная философия, обеспечивающая ответственность за любой написанный код.
Но это легче сказать, чем сделать.
Владение кодом, хотя это звучит просто, также может быть легко оставлено без присмотра с течением времени. Последствие этого огромно. Код станет спагетти, его будет невозможно поддерживать, и вскоре он станет устаревшей частью $#!+, и никто не сможет понять, как он работает.
Каждая часть кода кем-то написана, так что автор — владелец, не так ли?
Это очень упрощенный взгляд. Это относится только к сольному проекту или небольшой команде для небольшого проекта.
На самом деле, самые важные и успешные проекты, даже если они начинались с малого, проходят различные этапы, которые превращают гордый блестящий код в жалкий фрагмент загадочного кода, которого все боятся и презирают.
Чтобы узнать, как это происходит, ниже приведены семь этапов эволюции кода проекта, который становится уродливым.
1. Рождение
Разработчик начинает совершенно новый проект с продуманной архитектурой и чистой структурой кода. Это достаточно небольшой проект, в котором один разработчик понимает весь поток и интеграцию.
По сути, один человек владеет кодом.
2. Рост
У нас появляется больше разработчиков, которые вносят свой вклад в код. Возможно, команда из 3–5 разработчиков. У нас есть экспертные оценки кода. У нас есть кодовая пара. Все понимают все части кода. У нас есть главный ведущий разработчик, который решает, какой конвенции следовать. Чистый и последовательный.
Команда, по сути, владеет кодом.
3. Повторное использование
В идеале, когда в проект добавлено больше функций, мы не хотим все переписывать. Мы стараемся использовать повторно как можно больше. Мы используем такие подходы, как объектно-ориентированное наследование, рефакторинг общих кодов в некоторые общие классы.
Каждый разработчик владеет своей частью функций, но всем принадлежит общий слой. Всем нравится использовать общий слой, но люди стараются избегать его модификации, так как это может потребовать изменения кода всех остальных.
4. Федерация
Учитывая, что у нас только одна команда из 3–5 разработчиков, у нас недостаточно разработчиков, способных работать над всеми необходимыми функциями. Компания приняла решение нанять временных подрядчиков или одолжить членов команды из других проектов для работы над этим растущим проектом для удовлетворения неотложных потребностей проекта.
Позже код по-прежнему технически принадлежит команде, но команда пишет не весь код. Члены команды заняты другими функциями и не могут полностью владеть объединенным кодом. Подрядчики или члены кредитной группы ушли позже, оставив код частично в собственности.
5. Автоматизация
У одного умного разработчика появилась идея еще больше ускорить работу, не имея дополнительных разработчиков. Они видят некоторые шаблоны и общие шаблоны, которые могут быть сгенерированы автоматически. Чтобы упростить процесс автоматизации, они разработали сложный алгоритмический генератор кода, который генерирует стандартные коды.
Никто не должен владеть сгенерированным кодом, так как он «хорошо сгенерирован». Со временем разработчик использует его, но не знает, как он работает внутри, потому что в этом «нет необходимости». Умный разработчик владеет генератором кода… но ненадолго… (см. этап 6 ниже)
6. Переход
Умный разработчик умен, нашел работу получше и пошел дальше. Некоторые другие члены команды также пошли дальше. Возможно, организация была реорганизована. Команда сократилась. Руководство решило нанять новых людей для заполнения некоторых вакансий. Произошло несколько итераций переходов, пока первоначальная команда не изменилась и не наполнилась новыми членами команды.
Есть много кодов, «принадлежащих» команде, но ни один из них не имеет чувства собственности. Половина из них знает часть кода, но подавляющее большинство остается там, чтобы изучать только «необходимые» основы. Любые изменения кода — это просто «заплатки», поскольку они пытаются избежать изменения всего, что является «оригинальным», поскольку никто не знает, как это работает.
7. Миграция
Через некоторое время все ненавидят работать над исходной кодовой базой. Некоторые рекомендовали нам переписать все приложение. Кроме того, представлен новый стек технологий. Поэтому нам тоже нужно переходить на новый стек технологий.
Однако в бизнесе понимали, что полное переписывание — это большой риск, поскольку приложение уже активно используется в продакшене. Его нельзя полностью переписать, что потребует времени и не гарантирует, что оно будет работать так же, как и существующее приложение.
Следовательно, решение состоит в том, чтобы медленно оценить, как можно медленно перейти на более новую систему, сохраняя при этом «устаревший код». Старый «собственный» код теперь становится «горячей картошкой», и все стараются не прикасаться к нему.
Как вы можете видеть в конце, разработчикам теперь не нравится работать над исходным кодом, который хорошо предназначен для роста и масштабирования.
Из вышеизложенного может показаться, что проблема была вызвана «повторным использованием», «объединением», «автоматизацией» и «переходом», но они не являются основной причиной проблемы.
Все фундаментальные проблемы сводятся к одной общей проблеме: «угасание чувства владения кодом с течением времени».
Как ухудшается чувство владения кодом?
Как видим, все начиналось хорошо. Но с течением времени дела идут все хуже и хуже, и все идет по спирали. Ниже приведены несколько причин:
1. Постоянно расширяющиеся возможности
Программное обеспечение, которое только добавляет и добавляет функции, но не удаляет их, является бомбой замедленного действия. Мы ожидаем, что разработчики будут постоянно создавать все новые и новые функции, сохраняя при этом старые функции, которые они когда-то закодировали, до конца своей жизни.
Старые функции вскоре устаревают, поскольку первоначальные кодеры могли не прикасаться к коду в течение «долго-долгого» времени, поскольку кто-то занят работой над новыми функциями. Несмотря на то, что человек по-прежнему любит код и имеет чувство собственности, существует предел тому, чем он действительно может владеть.
2. Это принадлежит всем = это никому не принадлежит
Это происходит с общим кодом. Если за общим кодом не будет следить один человек или команда, очень скоро он либо станет:
- город-призрак — никто не хотел бы вносить в него изменения, учитывая, что любое изменение может случайно наступить на пятки другим функциям. Вскоре никто не знает, как это работает внутри.
- дикий-дикий запад — т. е. код будет видоизменяться, чтобы стать не-универсальным, где каждая команда создала свой исключительный специальный хук и API, который не является универсальным. Вскоре это становится беспорядком.
3. Кодируйте, но не владейте
Некоторым организациям нравится иметь группу разработчиков, которые переходят от проекта к проекту, чтобы временно поддерживать каждый проект и переходить к другому. Идея состоит в том, чтобы разделить ресурсы между несколькими проектами.
Хотя это звучит «дружественно для бизнеса» для организации, поскольку ресурсы совместно используются, проблема заключается в том, кто в конечном итоге будет владеть кодом, который они пишут?
В отличие от аппаратного продукта, программный продукт живет вечно, и его необходимо время от времени изменять, чтобы обеспечить его правильное понимание и поддержку. Но при «временном» владении таким кодом он скоро устареет.
4. Упрощение с усложнением
Чтобы ускорить написание кода, иногда разработчики создают сложные
- Генераторы кода, чтобы избежать шаблонного кода
- Базовые классы или функции, которые предполагают упростить его использование
Это отличные инициативы, которые могут повысить производительность. Затраты не на его строительство, а на его содержание. Поскольку это сложно, вероятность того, что стоимость его обслуживания также высока, а передача знаний непроста и часто игнорируется.
Очень скоро никто не поймет, как он работает, и никто не захочет его трогать.
5. Мы не всегда будем рядом
Почти гарантировано, что первоначальные разработчики кода не останутся с проектом. Они либо перейдут в другую организацию, на более высокую должность, либо в связи с реструктуризацией компании.
Обычно вся группа разработчиков меняется через несколько лет. Без надлежащего плана перехода новая группа разработчиков, скорее всего, будет:
- код тоже не понял
- не чувствуя никакой привязанности к коду
- имеют разные предпочтения относительно того, как должен быть сделан код
Со всеми вышеперечисленными причинами, скорее всего, ухудшится чувство собственности на текущую кодовую базу.
Как поддерживать хорошее чувство владения кодом?
Чтобы обеспечить надлежащее управление собственностью как отдельным лицом, так и командой, ниже приведены несколько рекомендуемых соображений:
1. Скажите «нет» совместному владению
Ни один код не должен быть оставлен как «совместное владение». Если мы хотим, чтобы какой-то общий код был общедоступным, у него также должен быть разработчик или команда, которая полностью им владеет.
Владелец должен поддерживать благополучие кода, руководящий принцип участия в коде (собственный код по-прежнему позволяет другим вносить свой вклад, как и любой открытый исходный код).
2. Четкие границы и автономия
Владение кодом должно быть четко разделено четкой границей: пакет, модуль или репозиторий. Это позволяет избежать двусмысленности, а также упрощает создание системы, которая управляет владением. Это также гарантирует, что код всегда находится в разумных пределах для разработчика или команды.
Хотя в идеале мы хотим большей согласованности между кодами (например, один и тот же язык), мы должны предоставить каждому владельцу кода автономию в определении его структуры. Эта гибкость позволяет владельцу кода чувствовать себя более способным к написанию кода и страстно владеть им, а также для упрощения дальнейшего развития кода по мере необходимости.
3. Код после отправки еще не готов
Код должен меняться… постоянно. Он требует постоянного обслуживания и изменений. Код, оставленный без присмотра в течение некоторого времени (например, 1-2 года), имеет тенденцию быть устаревшим и устаревшим. Всегда есть что время от времени менять и улучшать (например, обновление библиотеки, рефакторинг и т. д.)
Чтобы коды всегда обновлялись, всегда нужно выделять время на их улучшение, пока разработчики работают над другими функциями. Возможно, рефакторинг кода, улучшение теста и внедрение новых методов разработки.
4. Удаление кода полезно
Учитывая, что каждый код владеет и время от времени нуждается в выделении времени для его пересмотра, каждый разработчик может владеть кодом только определенного размера.
Чтобы убедиться, что коды поддерживаются, кроме добавления новых функций и нового кода, бизнес должен также рассмотреть возможность удаления функций, которые больше не влияют. Такое удаление поможет сократить код, который необходимо поддерживать. (**Вот почему четкое разделение кода для функции необходимо для более легкого удаления функции.)
Если нам нужно увеличить количество функций, не устарев при этом, нам, возможно, придется подумать о привлечении большего количества разработчиков. Обслуживание кода платное.
5. Автоматизация не бесплатна
Автоматизация — одно из самых интересных направлений разработки программного обеспечения на начальном этапе. Работа над ним может быть сложной, но она приносит много удовлетворения.
Фактическая более высокая стоимость приходит позже — ее обслуживание. Нам нужно убедиться, что кто-то не только владеет им, но и полностью его понимает. Это необходимо для того, чтобы можно было решить любые проблемы или улучшения, которые потребуются в будущем. Такая работа обычно сложна для последующего владельца, который не знает контекста кода автоматизации.
Автоматизация, хотя и кажется, что когда-то сделанная, она может волшебным образом повысить производительность, должна время от времени развиваться, чтобы обеспечить ее хорошее обслуживание. Последняя стоимость иногда превышает первоначальную стоимость. Следовательно, нужно взвесить это, прежде чем попасть в него.
Дополнительные иллюстрации см. в статье ниже.
Хороший код — это хорошо поддерживаемый код
В разработке программного обеспечения нас научили многим аспектам создания масштабируемого и поддерживаемого кода, таким как написание чистого кода, хорошо прокомментированного и т. д. Все это отличные методы разработки программного обеспечения, которые должен соблюдать каждый разработчик.
Однако реальность такова, что во многих организациях код по-прежнему становится наследием и, следовательно, становится тяжелым бременем для разработчиков.
В большинстве случаев проблема заключается в том, что этот код больше не принадлежит владельцам. Как только это произойдет, качество кода резко упадет и в конечном итоге станет неуправляемым.
Как и любые отношения, код нуждается в постоянной «любви». Если мы будем постоянно «лелеять» его, он будет продолжать процветать. Если нет, то он быстро состарится и вскоре вернется и будет преследовать нас.
