Хабрахабр

[Перевод] Что такое энтропия в ПО и как ею управлять?

Сегодня солнечный день. Вы едете по дороге в вашу деревню, в которой живут все ваши друзья, ваша семья и ваша любимая собака. Прекрасный день! Неожиданно вы слышите ужасный, кошмарный вопль, разрывающий окрестности. Огромная отвратительная Гидра приближается к деревне, чтобы её уничтожить! Вы хватаете меч (конечно, у вас есть меч!) и стараетесь защитить всех, кого любите. Но есть небольшая проблема: у чудовища много голов, и когда вы отрубаете одну из них, быстро вырастает новая!

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

Но с ним всё равно нужно бороться, чтобы ваши приложения (и коллеги) оставались здоровыми и вменяемыми. В роли Гидры выступает энтропия в ПО: это ваш враг, он вас измотает, но вы никогда не сможете полностью от него избавиться.

Мы узнаем:

  1. Что такое энтропия в ПО и как заметить её в своём коде.
  2. Что является её возможными причинами и как сохранить энтропию на низком уровне.

Хватит болтовни, к делу!

Что такое энтропия и как она оказалась в моём приложении?

Иногда полезно выяснить этимологию используемых слов, особенно таких специфических, как энтропия. В перевод с греческого оно означает «трансформация». Изменение. Нечто, к чему вы должны привыкнуть как разработчик ПО.

Он гласит, что в закрытой изолированной системе количество хаоса со временем не уменьшается. Энтропия ссылается на второй закон термодинамики. Чем больше меняется программа, тем больше в ней хаоса, её энтропия увеличивается. Оно остаётся стабильным или растёт.
Идея энтропии в ПО возникла благодаря книге Object-Oriented Software Engineering.

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

Что произойдёт со временем? Создайте лучшую команду (с вашим участием, разумеется!), лучшую среду, лучший менеджмент, лучшую культуру в компании, лучший проект.

  1. Вы будете каждое утро напевать «Это лучший проект!». Зелёный проект, который выглядит словно прекрасное поле, освещённое чудесным восходом.
  2. Вы и команда будете добавлять всё больше возможностей. Поскольку вы лучшие из лучших, какое-то время всё выглядит отлично.
  3. Пройдут месяцы или годы. Никто больше не хочет работать над проектом. Даже если он был хорошо спроектирован, технологии уже устарели, проект требует слишком много усилий и времени для понимания, он дорог в масштабировании. Слишком сложно построить его хорошую ментальную модель.

Как вы создали эту сложность? Вам просто нужно масштабировать проект. Большее количество элементов часто означает больше зависимостей и выше сложность. Я уже написал об этом подробную статью.

Если вы объясните это Лёхе, вашему коллеге-разработчику, то он ответит:

Ты дурак? «Нифига! Моя репутация не будет запятнана какой-то чушью! Хаосу и беспорядку не место в моём прекрасном приложении! Если я не меняю свою программу, то сложность не будет расти, и в связи с этим доказательством противоречия, я заявляю, что ты ошибаешься, а я — лучший!» Я хозяин своей судьбы!

Если у тебя есть сторонние библиотеки, которые не обновляются, то будут проблемы с безопасностью. Вы можете спокойно, убедительно и решительно объяснить Лёхе, что даже если не менять программу, то изменится всё вокруг неё. А если их обновить, это откроет дверь изменениям и энтропии.

И вам не поможет даже лучшая документация. Более того, если однажды вам понадобится изменить что-то в своём ПО спустя длительное время, то вы уже не будете помнить всех подробностей. Мир изменился, и то, что было верно вчера, уже может никогда не быть верным, как на технологическом уровне, так и на уровне бизнеса.

Подобные изменения разом привносят большое количество энтропии.

Это настоящее сражение, в которое брошены мы, разработчики. Так что вопрос не в избавлении от неё, а в замедлении.

Качество ПО

Как узнать, что в вашем приложении высокий уровень энтропии? Хорошим индикатором является качество кода.

Согласно книге 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»? Это хороший признак того, что нужно разделить функцию, метод или какую-либо другую конструкцию.
  • Есть ощущение, что какой-то код был добавлен из-за лени? Он нарушает логику и ухудшает понятность?

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

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

  1. Увеличение технического долго приведёт к новым проблемам. Они вернутся и будут преследовать вас (и вашу команду) ещё сильнее.
  2. Встретив технический долг, отрефакторьте его. Это лучший вариант. Если у вас нет времени или сил, просто добавьте комментарий //TODO: отрефакторить потому-то и потому-то. Сообщите о проблеме, не оставляйте её скрытой в кодовой базе.

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

Рефакторьте маленькие фрагменты кода за раз и часто прогоняйте тесты, чтобы убедиться, что система ведёт себя как ожидается.

Наконец, в ходе рефакторинга вам могут понадобиться хорошие аргументы:

  1. Сначала, для себя. Легко подумать, что ваш коллега не умеет программировать и что вы знаете лучше других. Но если вы не видите конкретных выгод от рефакторинга, то не делайте этого. Возможно, всё дело лишь в вашем эго, и вы можете что-то испортить.
  2. Если рефакторинг связан со стилем кода, значит, в вашей команде его ясно не определили. Проведите встречу и решите все вместе, какой стиль кода вы хотите принять. Это нужно будет где-то записать, чтобы все могли обращаться по мере надобности. Редактируйте соглашение в зависимости от потребностей команды. В противном случае ваш код наполнится комментариями вроде «мы используем табуляцию!!! НЕ ПРОБЕЛЫ!!!!!11!1!!!». Это бесполезный шум.
  3. Наконец, если кто-то спросит вас, почему вы изменили его прекрасный код, у вас будут настоящие аргументы для объяснения своего решения.

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

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

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

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

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

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

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

Проблема

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

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

Экономия денег.

правило 5). Простой пример: NASA тщательно тестирует свой код (см.

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

Годами я занимался тем же самым. Я тоже не без греха.

Так почему бы не автоматизировать и тесты? Надеюсь, все согласны с тем, что компьютинг — это автоматизация для нас людей, которая экономит наше время и повышает нашу эффективность. Тестирование, как и рефакторинг, требует времени на написание кода (как и всё остальное), но экономит время, энергию и рассудок в средне- и долгосрочной перспективе. Да, я считаю это целесообразным.

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

Чем больше проект, тем сильнее будет последнее заявление.

Решение

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

В одном банке из-за недостаточного тестирования было потеряно 1,3 млрд клиентских записей. Вот конкретный пример. Достаточно сказать «нет» автоматизированным тестам. И вам не нужно быть банком, чтобы иметь баги и терять данные.

Аргументы против тестов часто связаны со скоростью:

  • «Тестирование замедляет всех и везде».
  • «Мы стартап, у нас нет времени на тесты».
  • «Тестирование для шимпанзе. Я знаю, что делаю, потому что у меня большой мозг».

Повторюсь, что, даже если вы потратите какое-то время на написание тестов (хотя я в этом и сомневаюсь), зато сэкономите много времени и энергии в будущем:

  • Тесты покажут упущенные вами баги. Составьте их список, чтобы показать принимающим решения, какие проблемы могут возникнуть у компании без тестов.
  • Все будут увереннее изменять приложение. Разработчики будут тратить меньше времени, спрашивая себя, не сломают ли их изменения что-нибудь другое.
  • Не нужно тестировать вручную каждое изменение. Ручное тестирование — это настоящая потеря времени, и нужно всячески его минимизировать.
  • Автоматические тесты покажут, есть ли какие-то системные проблемы в вашем коде. Например, если тесты трудно писать из-за обилия зависимостей. В таком случае исправляйте архитектуру!
  • Тесты могут помочь понять, как должен работать ваш код. Подумайте о своих коллегах!

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

Сэнди Метц хорошо рассказала об этом в своём выступлении. Я говорю, что вам нужно тестировать код, когда это целесообразно.

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

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

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

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

Тесты — это клей, который позволяет всей системе чётко работать.

Тестирование ведёт к сбоям, а сбои ведут к пониманию.

Берт Рутан

Делитесь знаниями, чтобы избегать ошибок

Очень важно делиться знаниями с командой:

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

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

Как преуспеть в этом начинании?

Совместное программирование

Совместное программирование — это обмен опытом. Кто-то пишет код и показывает другому, как он это делает. А второй указывает на ошибки, даёт советы и подсказки.

Если разработчики заинтересованы, то получается забавно. Вот и всё!

Но, к сожалению, совместное программирование часто считают потерей времени.

К тому же тут один разрабатывает, а второй просто смотрит в экран. Лёха, ваш коллега, выразил распространённое мнение об этом: «Два разраба будут кодить две разные фичи быстрее, чем одну, верно? Потеря времени!».

Код нам не друг, он источник багов. Вы можете объяснить ему: мы хотим писать качественный код, а не много кода. Нам нужно бороться с энтропией, а не как можно быстрее писать код.

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

Анализ кода

Это ещё один хороший способ делиться своими знаниями. Анализ кода может:

  • Научить вас лучшим способам решения проблем.
  • Помочь вам научить других тому, что вы знаете.
  • Улучшить взаимодействие в команде.

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

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

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

Несколько советов по проведению анализа кода:

  • Старайтесь избегать комментариев, полных негатива. «Думаешь, это решение лучше?» — так сказать лучше, чем «Не делай так! Дурак! Вот единственный хороший ответ!».
  • Задавайте в комментариях вопросы, а не нагромождайте утверждения. Это покажет, что вы не всегда правы, что вы сомневаетесь, как и все остальные, и что ваше эго не раздуто до непомерной величины. «Думаешь, этот код получится расширить, если мы так сделаем?» вместо «Сделай так и так, потому что я босс и работаю уже 289 лет».

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

Делитесь знаниями

Делитесь с коллегами интересными статьями (вроде этой!) в любых мессенджерах и прочих каналах коммуникации.

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

Это поможет держать уровень энтропии на минимальном уровне! Не забудьте, что передача знаний — это забота и повышение эрудиции и опыта команды, в которой вы работаете, и хороший способ писать более качественный и чистый код.

Почему ваши коллеги ленивы? Тем, кто всё ещё думает, что первой причиной энтропии в ПО является лень, я возражу, что она никогда не бывает основной причиной. Или у них слишком силён стресс из-за сжатых сроков? Потому что кадровики наняли не тех? Работа приносит им удовлетворение?

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

Обвинения и критика ничего никому не дадут. Честно говоря, вам понадобится приличная порция эмпатии и открытости, чтобы эффективно работать с людьми. А указывать на лень — это обвинение.

Что вы для себя вынесли из этой статьи? Итак.

  • Энтропия — это мера беспорядка в вашей системе. Избавиться от неё невозможно. А для удержания на стабильном уровне необходимо не только жаловаться, но и действовать.
  • Снижение качества кода — хороший индикатор увеличения энтропии.
  • Не только разработчики ответственны за высокую энтропию. Сложные и/или неясные фичи могут загнать уровень энтропии в небеса.
  • Заботиться о качестве кода нужно активно, указывая на технический долг, а лучше исправляя его.
  • Необходимо автоматическое тестирование, если вы хотите снизить энтропию в кодовой базе. На самом деле, фича должна считаться завершённой только после прохождения автоматизированных тестов.
  • Создайте такую атмосферу, которая позволит легко делиться знаниями друг с другом с помощью совместного программирования, анализа кода или просто выкладывания ссылок на интересные источники информации (статьи, книги).

Идеального ПО не существует. Энтропия всегда будет частью нашей работы. Это не означает, что мы уже проиграли эту битву. Это означает, что снижение энтропии во всей кодовой базе — уже победа!

Полезные ссылки:

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»