[Перевод] Что такое энтропия в ПО и как ею управлять?
Сегодня солнечный день. Вы едете по дороге в вашу деревню, в которой живут все ваши друзья, ваша семья и ваша любимая собака. Прекрасный день! Неожиданно вы слышите ужасный, кошмарный вопль, разрывающий окрестности. Огромная отвратительная Гидра приближается к деревне, чтобы её уничтожить! Вы хватаете меч (конечно, у вас есть меч!) и стараетесь защитить всех, кого любите. Но есть небольшая проблема: у чудовища много голов, и когда вы отрубаете одну из них, быстро вырастает новая!
Кажется, что вы не можете победить в этой битве. Возможно, вы сможете играть с Гидрой достаточно долго, так чтобы вся деревня успела улететь от ужасной угрозы? Наконец, вы станете настоящий героем всего мира! Кому этого не хочется?
В роли Гидры выступает энтропия в ПО: это ваш враг, он вас измотает, но вы никогда не сможете полностью от него избавиться. Но с ним всё равно нужно бороться, чтобы ваши приложения (и коллеги) оставались здоровыми и вменяемыми.
Мы узнаем:
- Что такое энтропия в ПО и как заметить её в своём коде.
- Что является её возможными причинами и как сохранить энтропию на низком уровне.
Хватит болтовни, к делу! 
Что такое энтропия и как она оказалась в моём приложении?
Иногда полезно выяснить этимологию используемых слов, особенно таких специфических, как энтропия. В перевод с греческого оно означает «трансформация». Изменение. Нечто, к чему вы должны привыкнуть как разработчик ПО.
Энтропия ссылается на второй закон термодинамики. Он гласит, что в закрытой изолированной системе количество хаоса со временем не уменьшается. Оно остаётся стабильным или растёт.
Идея энтропии в ПО возникла благодаря книге Object-Oriented Software Engineering. Чем больше меняется программа, тем больше в ней хаоса, её энтропия увеличивается.
Первое, что нужно уяснить нам, бедным разработчикам, это трагическая правда: мы можем бороться с количеством энтропии в наших программах, но никогда не сможем от неё избавиться.
Создайте лучшую команду (с вашим участием, разумеется!), лучшую среду, лучший менеджмент, лучшую культуру в компании, лучший проект. Что произойдёт со временем?
- Вы будете каждое утро напевать «Это лучший проект!». Зелёный проект, который выглядит словно прекрасное поле, освещённое чудесным восходом.
- Вы и команда будете добавлять всё больше возможностей. Поскольку вы лучшие из лучших, какое-то время всё выглядит отлично.
- Пройдут месяцы или годы. Никто больше не хочет работать над проектом. Даже если он был хорошо спроектирован, технологии уже устарели, проект требует слишком много усилий и времени для понимания, он дорог в масштабировании. Слишком сложно построить его хорошую ментальную модель.
Как вы создали эту сложность? Вам просто нужно масштабировать проект. Большее количество элементов часто означает больше зависимостей и выше сложность. Я уже написал об этом подробную статью.
Если вы объясните это Лёхе, вашему коллеге-разработчику, то он ответит:
«Нифига! Ты дурак? Хаосу и беспорядку не место в моём прекрасном приложении! Моя репутация не будет запятнана какой-то чушью! Я хозяин своей судьбы! Если я не меняю свою программу, то сложность не будет расти, и в связи с этим доказательством противоречия, я заявляю, что ты ошибаешься, а я — лучший!»
Вы можете спокойно, убедительно и решительно объяснить Лёхе, что даже если не менять программу, то изменится всё вокруг неё. Если у тебя есть сторонние библиотеки, которые не обновляются, то будут проблемы с безопасностью. А если их обновить, это откроет дверь изменениям и энтропии.
Более того, если однажды вам понадобится изменить что-то в своём ПО спустя длительное время, то вы уже не будете помнить всех подробностей. И вам не поможет даже лучшая документация. Мир изменился, и то, что было верно вчера, уже может никогда не быть верным, как на технологическом уровне, так и на уровне бизнеса.
Подобные изменения разом привносят большое количество энтропии.
Так что вопрос не в избавлении от неё, а в замедлении. Это настоящее сражение, в которое брошены мы, разработчики.
Качество ПО
Как узнать, что в вашем приложении высокий уровень энтропии? Хорошим индикатором является качество кода.
Что это такое и как его измерить? Согласно книге Accelerate: The Science Behind Devops:
- Если увеличивается соотношение изменения/сбои, то качество снижается. Отслеживайте изменения, баги и сбои, сопоставляйте их друг с другом. Если каждое изменение приводит к новым багам или сбоям, то энтропия в вашей программе увеличивается.
- Важную роль играет субъективное восприятие проекта разработчиками. Если у всех есть ощущение, что становится всё сложнее масштабировать приложение, не ломая его, то наверняка энтропия высока. Однако это ощущение должно быть распространённым.
- Если команда тратит много времени на исправление багов или восстановление после сбоев, то наверняка энтропия свила гнездо в вашем приложении.
Если вы можете получить какую-то информацию о соотношении изменений и сбоев, и потратить время на исправление багов, то сможете придумать хороший график, чтобы убедить руководство в необходимости какого-то рефакторинга.
Демон сложности
Даже если у вас код максимального качества, сложность может легко возрастать, когда дело доходит до самих возможностей программы. Сам бизнес является источником необходимой сложности, от которой вы не сможете избавиться.
При избыточной сложности бизнеса разработчикам придётся потратить много сил, чтобы построить хорошую ментальную модель бизнеса компании. Поэтому они будут делать ошибки, пытаясь перевести бизнес-требования в код.
Давайте подробнее поговорим о сложности бизнеса: действительно ли нам нужны все эти сложные фичи, которые нам спускают?
Водопад энтропии
Проблема
Более-менее очевидно, что основной причиной энтропии в ПО являются сами разработчики. Они ленивы, им не хватает квалификации, особенно Саньку, с которым вы работаете. Он задаёт столько вопросов!
Я категорически не согласен с таким мнением. По моему опыту, основной причиной энтропии является руководство, особенно в компаниях, придерживающихся водопадного стиля управления.
Как заметил Джеральд Вайнберг в книге The Secret of Consulting:
Даже если это чисто техническая проблема, её происхождение всегда можно отследить вплоть до действия или бездействия руководства.
Я знаю, что вы подумали: «Ты ошибаешься! Руководство не всегда отвечает за всё! Просто разработчикам удобно во всём обвинять начальство!»
Я не говорю, что во всём виновато руководство, но у него всегда есть какая-то доля ответственности. Разработчик сделал что-то плохое? Тебе нужно пересмотреть процедуру найма. Спецификации были плохо реализованы? Возможно, кто-то из руководство не знает, чего на самом деле хочет, поэтому и спецификации для него не имеют значения.
Поэтому так трудно быть руководителем! Чем выше ты в иерархии, тем труднее.
Как разработчики, насколько сильно вы влияете на принятие решений? Если на 100%, то поздравляю, во всём виноваты вы. Если на 0%, то вашей вины нет. Между этими полюсами лежит весь спектр влияния. И водопад не подразумевает его большого количества.
Используете Scrum, Kanban и покер планирования? Конечно, вы не применяете водопад! Вы применяете Agile так же, как ребёнок строит дом с помощью отвёртки.
Конечно, инструменты важны, но их значимость гораздо ниже значимости вашего образа мышления, которое необходимо для корректной разработки ПО. Процитирую манифест Agile:
Личности и взаимодействия важнее процессов и инструментов.
Применение Scrum не означает, что ты применяешь «Agile», особенно если у тебя отсутствует образ мышления, которому пытается научить эта методология.
При водопадном управлении кто-то выше вас принимает решение, уровнем выше другие люди принимают новые решения, и так далее.
На нижних уровнях иерархии находятся сотрудники, чьё проклятие заключается в следовании всем принятым решениям. Какова их задача? Производить, словно рабочие на сборочном конвейере автозавода. Им не нужно думать, они должны делать машины.
Плохие новости: являясь разработчиком, вы будете на дне иерархии.
Если кто-то наверху принимает решения относительно функций приложения, и у вас практически нет возможностей повлиять на процесс принятия решений, тогда добро пожаловать в водопад! К сожалению, чаще всего высшее руководство не видит, что в мире разработки ПО не существует фазы производства. Разработчики занимаются проектированием системы, а эта задача далека от конвейерной сборки кабины.
Почему? Потому что, в отличие от автомобиля, приложения постоянно меняются! Вам нужно корректно проектировать их, чтобы они работали, отвечали потребностям пользователей, чтобы приложения имели приемлемую производительность, чтобы они были масштабируемы и были устойчивы к изменениям, при этом сохраняя энтропию на низком уровне. Для этого вам нужно принимать много решений о том, как отражать бизнес-знания в вашем коде.
Если вы не влияете на сложность, которая спускается вам руководством, то придётся потратить много сил на управление ей в коде. Это будет считаться «необходимой» сложностью: той, которой нельзя избежать.
Возможный результат? Уровень энтропии может расти очень, очень быстро.
Возможное решение
В компании необходимо как можно активнее практиковать совместное принятие решений и ответственность.
Если вы узнали в описанной мной водопадной модели свою компанию, то вам нужно поговорить с теми, кто принимает решения:
- Приведите данные и сильные аргументы, почему и как можно упростить фичу X или Y. Объясните возможную цену разработки сложной фичи сейчас и в будущем.
- Объясните, почему разработка ПО в рамках Agile означает, что людям нужно работать вместе. Управленцы, дизайнеры, разработчики и все остальные должны быть частью процесса принятия решений в зависимости от бизнес-требований.
- Если ваше руководство автоматически отвергнет предложения, то вам нужно понять, почему оно это сделало. Задайте вопросы.
- Поговорите о том, что принимающие решения считают самым важным: о деньгах и времени. Покажите им, что образ мышления в стиле Agile (а не одни лишь инструменты) поможет сэкономить и то, и другое.
Однако трудно пытаться решить проблему, если вас об этом не просили. Многие руководители очень довольны водопадной моделью, и зачастую даже не знают, что следуют ей. Вам понадобится много дипломатии и такта.
Учитывая всё это, если вы чувствуете, что бизнес-решения добавляют слишком много сложности в ваше приложение, и что вы ничего не можете с этим сделать, даже попытавшись, то советую найти другую работу. Это изматывает — изо дня в день работать с высокой энтропией, а делать раздутый продукт удовольствия мало… или использовать его. Это может дать вам подсказку относительно успеха, который ожидает ваш продукт.
И последнее: то, что может выглядеть сложным на уровне бизнеса, можно упростить, если вы хорошо знаете бизнес-процессы. Это крайне важно. Поэтому узнавайте больше о деятельности своей компании, что здесь делают и что не делают, это поможет упростить фичи и кодовую базу.
По мере выражения своего архитектуры мы что-то объясняем компьютеру. А для этого нам нужно хорошо понимать то, что мы объясняем.
Дональд Кнут
Качество кода и технический долг
Проблема
Помимо «необходимой» сложности, привносимой бизнесом, энтропия в ПО тесно связана с качеством кода и техническим долгом.
Что такое технический долг? Попросту говоря, это упрощения (хаки), которые вы используете для экономии времени, зная, что позднее вам это может аукнуться. Особенно в тех случаях, если от этих хаков зависят другие фичи: вам придётся это исправлять с процентами, как и при настоящем долге, в виде сложностей и головной боли.
В зависимости от задачи вашего приложения, технический долг может быть более или менее приемлемым. Если программа должна прожить пару месяцев, то можно вообще не думать о техническом долге, энтропии или качестве. Просто соедините куски кода, и готово!
К примеру, это может быть временным решением, прежде чем создавать более сложное приложение с нуля. Или так можно быстро написать прототип, чтобы проиллюстрировать идею, а затем всё переписать или отказаться от концепции.
С другой стороны, обычно компании хотят разрабатывать более долгоживущие приложения. Это разумно: переписывание приложение может стоить очень дорого (особенно, если оно большое), и никто не гарантирует, что его уровень энтропии окажется ниже. Переписывание — занятие очень рискованное.
В подобных случаях вам нужно быть очень осторожными с техническим долгом и качеством кода. Это важная часть вашей работы как разработчика.
В известной книге The Pragmatic Programmer (в которой помимо много другого введён принцип DRY) приведена интересная аналогия технического долга. Здесь описано исследование, в котором сопоставлены разрушения городских зданий с… выбитыми в них окнами. Разбитое окно создаёт впечатление заброшенности, вдохновляя каждого хулигана в округе. В результате здания с разбитыми окнами подвергаются вандализму быстрее, чем здания с целыми окнами.
Технический долг — это упрощение или хак в вашем коде, разбитое окно. Когда другой разработчик, или даже вы сами в будущем, заметит это, то возникнет соблазн добавить ещё больше технического долга, потому что «здесь всё равно есть плохой код, так чего париться?»
Пример: вы написали обход для одного сложного бага, потому что не было времени его выискивать. Другой разработчик (или вы сами позднее) поверх этого обхода может написать другой код, решая другую проблему. Очень быстро нарастут слои обходных решений, в которых никто никогда не разберётся.
Решение
Во-первых, как узнать, что в коде есть технический долг?
Спросите себя:
- Я могу просто и логически объяснить, что делает код?
- Здесь используются корректные наименования? Они помогают объяснить, что делает код?
- Применяются ли длинные наименования с «and», вроде «deleteUserAndShutDown»? Это хороший признак того, что нужно разделить функцию, метод или какую-либо другую конструкцию.
- Есть ощущение, что какой-то код был добавлен из-за лени? Он нарушает логику и ухудшает понятность?
Чем больше будут расти ваши знания и опыт, чем больше вы будете любознательны и чаще будете проводить здоровые обсуждения с другими разработчиками, тем чаще вы станете замечать паттерны технического долга. Это код с душком.
Встречая такие паттерны, пожалуйста, не расценивайте их как разрешение добавлять ещё больше технического долга:
- Увеличение технического долго приведёт к новым проблемам. Они вернутся и будут преследовать вас (и вашу команду) ещё сильнее.
- Встретив технический долг, отрефакторьте его. Это лучший вариант. Если у вас нет времени или сил, просто добавьте комментарий //TODO: отрефакторить потому-то и потому-то. Сообщите о проблеме, не оставляйте её скрытой в кодовой базе.
Не забывайте, что рефакторить нужно параллельно с разработкой других фич, чтобы они соответствовали текущей архитектуре. Попросту говоря, исправление технического долга должно быть не самостоятельной задачей, а продолжающимся процессом, который может быть не связан с текущей задачей. Разрабатывая фичу, дайте себе право исправить встреченный технический долг.
Рефакторьте маленькие фрагменты кода за раз и часто прогоняйте тесты, чтобы убедиться, что система ведёт себя как ожидается.
Наконец, в ходе рефакторинга вам могут понадобиться хорошие аргументы:
- Сначала, для себя. Легко подумать, что ваш коллега не умеет программировать и что вы знаете лучше других. Но если вы не видите конкретных выгод от рефакторинга, то не делайте этого. Возможно, всё дело лишь в вашем эго, и вы можете что-то испортить.
- Если рефакторинг связан со стилем кода, значит, в вашей команде его ясно не определили. Проведите встречу и решите все вместе, какой стиль кода вы хотите принять. Это нужно будет где-то записать, чтобы все могли обращаться по мере надобности. Редактируйте соглашение в зависимости от потребностей команды. В противном случае ваш код наполнится комментариями вроде «мы используем табуляцию!!! НЕ ПРОБЕЛЫ!!!11!1!!!». Это бесполезный шум.
- Наконец, если кто-то спросит вас, почему вы изменили его прекрасный код, у вас будут настоящие аргументы для объяснения своего решения.
Хорошие аргументы в будущем всегда играют положительную роль. Например, обёртывание сторонней библиотеки, чтобы она не стала причиной утечки в вашей кодовой базе. Если вы не понимаете, почему я говорю про утечку, то почитайте, что я писал об абстракциях.
Нам, людям, трудно даются прогнозы в средне- и долгосрочной перспективе. Поэтому не всегда просто рефакторить или «продавать» нечто с прицелом на неизвестное будущее.
Технический долг отражает дуализм между простым и правильным путями. Первый быстр и привлекателен, второй сделает ваш проект масштабируемым и лёгким в сопровождении. Вам понадобится самодисциплина, чтобы как можно чаще выбирать второй путь. Иначе будущее будет наполнено страданиями.
Если вы слишком устали, раздражены или полны других мыслей или эмоций, снижающих вашу мотивацию, чтобы придерживаться правильного пути, а не простого, то лучше пока не программируйте. Прогуляйтесь, поговорите с коллегами, сделайте перерыв. Вернитесь к коду со свежими мозгами.
Чаще всего технический долг добавляется при отладке. Если вы исправляете баг, добавляя обходное решение, то вы ничего не исправили. Баг остался, просто его труднее запустить и случайно найти. Исправлять баги нужно с помощью рефакторинга, изменения или полного удаления кода. Затем протестируйте код, чтобы удостовериться, что баг не возникнет снова.
Последнее: винить коллег за ошибки непродуктивно. Если будете плохо или саркастично высказываться о своей кодовой базе, это тоже не решит проблем, только ухудшит ситуацию. Не разрушайте командный дух. Вам нужно уменьшать энтропию в проекте, а не разрушать его устно.
Автоматизированные тесты
Проблема
Есть кое-что завораживающее меня в волшебном мире разработки ПО, особенно в стартапах: многие программисты до сих пор не хотят писать автоматизированные тесты.
Почему меня это завораживает? Во всех остальных сферах инжиниринга тестируют то, что делают, следуя строгому процессу. Когда строишь ракету, то необходимо протестировать множество систем, или ракета упадёт. То же самое относится к автомобилям, мостам, самолётам — чему угодно.
Экономия денег.
Простой пример: NASA тщательно тестирует свой код (см. правило 5).
Трудно найти руководителей или разработчиков, которые против тестов, но легко найти тех, кто против автоматизированных тестов. Эти люди предпочтут тратить время на ручное тестирование любых изменений, вместо того, чтобы один раз написать тесты.
Я тоже не без греха. Годами я занимался тем же самым.
Надеюсь, все согласны с тем, что компьютинг — это автоматизация для нас людей, которая экономит наше время и повышает нашу эффективность. Так почему бы не автоматизировать и тесты? Да, я считаю это целесообразным. Тестирование, как и рефакторинг, требует времени на написание кода (как и всё остальное), но экономит время, энергию и рассудок в средне- и долгосрочной перспективе.
Вот очень простой индикатор того, что у приложения может быть высокий уровень энтропии: если есть хорошие автоматизированные тесты, то уровень энтропии может быть низким. Если таких тестов нет, уровень энтропии является высоким.
Чем больше проект, тем сильнее будет последнее заявление.
Решение
Если ваши коллеги или лица, принимающие решения, не хотят слышать о тестировании, вам понадобятся сильны аргументы.
Вот конкретный пример. В одном банке из-за недостаточного тестирования было потеряно 1,3 млрд клиентских записей. И вам не нужно быть банком, чтобы иметь баги и терять данные. Достаточно сказать «нет» автоматизированным тестам.
Аргументы против тестов часто связаны со скоростью:
- «Тестирование замедляет всех и везде».
- «Мы стартап, у нас нет времени на тесты».
- «Тестирование для шимпанзе. Я знаю, что делаю, потому что у меня большой мозг».
Повторюсь, что, даже если вы потратите какое-то время на написание тестов (хотя я в этом и сомневаюсь), зато сэкономите много времени и энергии в будущем:
- Тесты покажут упущенные вами баги. Составьте их список, чтобы показать принимающим решения, какие проблемы могут возникнуть у компании без тестов.
- Все будут увереннее изменять приложение. Разработчики будут тратить меньше времени, спрашивая себя, не сломают ли их изменения что-нибудь другое.
- Не нужно тестировать вручную каждое изменение. Ручное тестирование — это настоящая потеря времени, и нужно всячески его минимизировать.
- Автоматические тесты покажут, есть ли какие-то системные проблемы в вашем коде. Например, если тесты трудно писать из-за обилия зависимостей. В таком случае исправляйте архитектуру!
- Тесты могут помочь понять, как должен работать ваш код. Подумайте о своих коллегах!
Тестирование даст вам ощущения контроля над вашим кодом, и поэтому уменьшит у всех стресс.
Я не утверждаю, что нужно всё проверять с помощью модульных тестов. Я не утверждаю, что покрытие должно быть стопроцентным. Я не утверждаю, что модульное тестирование лучше любого другого.
Я говорю, что вам нужно тестировать код, когда это целесообразно. Сэнди Метц хорошо рассказала об этом в своём выступлении.
Также полезно тестировать в ходе исправления багов, чтобы удостовериться, что баги не возникнут снова. Затем можете показать тест всем противникам и сказать, что этого бага могло бы не быть, если бы кто-нибудь с самого начала написал тест.
Если после этих аргументов ваша команда всё ещё не хочет писать тесты, то в причина может быть в том, что они просто не умеют. Вместо того, чтобы ругать их, вы можете:
- Заняться с коллегами совместным программированием, чтобы показать, чем полезны тесты и как легко их можно писать.
- Организовать встречу с командой и предложить какой-то базовый процесс тестирования, который вы сможете со временем адаптировать под ваши команды.
Если в команде есть начинающие разработчики, научите их искусству тестирования. Я часто встречаю точку зрения, что начинающих не нужно обучать тестированию. Это ошибка. Тесты должны считаться частью вашего кода, частью будущего, которое вы создаёте, а не чем-то опциональным, побочным.
Тесты — это клей, который позволяет всей системе чётко работать.
Тестирование ведёт к сбоям, а сбои ведут к пониманию.
Берт Рутан
Делитесь знаниями, чтобы избегать ошибок
Очень важно делиться знаниями с командой:
- Постоянное обучение сделает вашу работу более интересной и сложной.
- Это повысит ваши знания, а следовательно и ценность как разработчика.
- Если все будут делиться своими знаниями, то чьим-то уходом информация не пропадёт.
Это снизит энтропию в вашем проекте. Команда будет более мотивирована хорошо выполнить работу, все будут учиться друг у друга писать более качественный, более чистый код.
Как преуспеть в этом начинании?
Совместное программирование
Совместное программирование — это обмен опытом. Кто-то пишет код и показывает другому, как он это делает. А второй указывает на ошибки, даёт советы и подсказки.
Вот и всё! Если разработчики заинтересованы, то получается забавно.
Но, к сожалению, совместное программирование часто считают потерей времени.
Лёха, ваш коллега, выразил распространённое мнение об этом: «Два разраба будут кодить две разные фичи быстрее, чем одну, верно? К тому же тут один разрабатывает, а второй просто смотрит в экран. Потеря времени!».
Вы можете объяснить ему: мы хотим писать качественный код, а не много кода. Код нам не друг, он источник багов. Нам нужно бороться с энтропией, а не как можно быстрее писать код.
Если те, кто принимает решения, вас не поймут, ищите другую работу. Если вы этого не сделаете, то со временем получите пачку устаревших приложений, которые невозможно сопровождать. Добро пожаловать в ад!
Анализ кода
Это ещё один хороший способ делиться своими знаниями. Анализ кода может:
- Научить вас лучшим способам решения проблем.
- Помочь вам научить других тому, что вы знаете.
- Улучшить взаимодействие в команде.
Все должны анализировать чужой код, как их код должен анализироваться. Это верно и для опытных, и для начинающих. Анализ кода позволит находить баги и, что важнее, повысит навыки всей команды.
Вы жалуетесь на Коляна, начинающего разраба, потому что он ничего не знает про принцип единственной ответственности. В его коде бардак?
Всегда лучше учить, а не обвинять. Дайте ему хороший совет, подскажите полезные источники информации, поделитесь знанием и энтузиазмом.
Несколько советов по проведению анализа кода:
- Старайтесь избегать комментариев, полных негатива. «Думаешь, это решение лучше?» — так сказать лучше, чем «Не делай так! Дурак! Вот единственный хороший ответ!».
- Задавайте в комментариях вопросы, а не нагромождайте утверждения. Это покажет, что вы не всегда правы, что вы сомневаетесь, как и все остальные, и что ваше эго не раздуто до непомерной величины. «Думаешь, этот код получится расширить, если мы так сделаем?» вместо «Сделай так и так, потому что я босс и работаю уже 289 лет».
Эти подходы могут спровоцировать интересные дискуссии и здоровые обсуждения, что ещё больше повысит ценность вашей команды. Очевидно, что обсуждать нужно уважительно и конструктивно!
Делитесь знаниями
Делитесь с коллегами интересными статьями (вроде этой!) в любых мессенджерах и прочих каналах коммуникации.
Важно также экспериментировать с командой. Если вы считаете, что новая технология может решить одну из ваших проблем, проведите совместное программирование и проверьте эти возможности.
Не забудьте, что передача знаний — это забота и повышение эрудиции и опыта команды, в которой вы работаете, и хороший способ писать более качественный и чистый код. Это поможет держать уровень энтропии на минимальном уровне!
Тем, кто всё ещё думает, что первой причиной энтропии в ПО является лень, я возражу, что она никогда не бывает основной причиной. Почему ваши коллеги ленивы? Потому что кадровики наняли не тех? Или у них слишком силён стресс из-за сжатых сроков? Работа приносит им удовлетворение?
Поговорите с командой. Спросите, нравится ли им работать с вами. Интересуйтесь по-настоящему, какие они люди. Прислушайтесь к тому, что они скажут, к их отзывам, даже если вы не согласны с их мнениями.
Честно говоря, вам понадобится приличная порция эмпатии и открытости, чтобы эффективно работать с людьми. Обвинения и критика ничего никому не дадут. А указывать на лень — это обвинение.
Итак. Что вы для себя вынесли из этой статьи?
- Энтропия — это мера беспорядка в вашей системе. Избавиться от неё невозможно. А для удержания на стабильном уровне необходимо не только жаловаться, но и действовать.
- Снижение качества кода — хороший индикатор увеличения энтропии.
- Не только разработчики ответственны за высокую энтропию. Сложные и/или неясные фичи могут загнать уровень энтропии в небеса.
- Заботиться о качестве кода нужно активно, указывая на технический долг, а лучше исправляя его.
- Необходимо автоматическое тестирование, если вы хотите снизить энтропию в кодовой базе. На самом деле, фича должна считаться завершённой только после прохождения автоматизированных тестов.
- Создайте такую атмосферу, которая позволит легко делиться знаниями друг с другом с помощью совместного программирования, анализа кода или просто выкладывания ссылок на интересные источники информации (статьи, книги).
Идеального ПО не существует. Энтропия всегда будет частью нашей работы. Это не означает, что мы уже проиграли эту битву. Это означает, что снижение энтропии во всей кодовой базе — уже победа!
Полезные ссылки:
