- PVSM.RU - https://www.pvsm.ru -
Сегодня солнечный день. Вы едете по дороге в вашу деревню, в которой живут все ваши друзья, ваша семья и ваша любимая собака. Прекрасный день! Неожиданно вы слышите ужасный, кошмарный вопль, разрывающий окрестности. Огромная отвратительная Гидра приближается к деревне, чтобы её уничтожить! Вы хватаете меч (конечно, у вас есть меч!) и стараетесь защитить всех, кого любите. Но есть небольшая проблема: у чудовища много голов, и когда вы отрубаете одну из них, быстро вырастает новая!
Кажется, что вы не можете победить в этой битве. Возможно, вы сможете играть с Гидрой достаточно долго, так чтобы вся деревня успела улететь от ужасной угрозы? Наконец, вы станете настоящий героем всего мира! Кому этого не хочется?
В роли Гидры выступает энтропия в ПО: это ваш враг, он вас измотает, но вы никогда не сможете полностью от него избавиться. Но с ним всё равно нужно бороться, чтобы ваши приложения (и коллеги) оставались здоровыми и вменяемыми.
Мы узнаем:
Хватит болтовни, к делу!
Иногда полезно выяснить этимологию используемых слов, особенно таких специфических, как энтропия. В перевод с греческого оно означает «трансформация». Изменение. Нечто, к чему вы должны привыкнуть как разработчик ПО.
Энтропия ссылается на второй закон термодинамики. Он гласит, что в закрытой изолированной системе количество хаоса со временем не уменьшается. Оно остаётся стабильным или растёт.
Идея энтропии в ПО возникла благодаря книге Object-Oriented Software Engineering [1]. Чем больше меняется программа, тем больше в ней хаоса, её энтропия увеличивается.
Первое, что нужно уяснить нам, бедным разработчикам, это трагическая правда: мы можем бороться с количеством энтропии в наших программах, но никогда не сможем от неё избавиться.
Создайте лучшую команду (с вашим участием, разумеется!), лучшую среду, лучший менеджмент, лучшую культуру в компании, лучший проект. Что произойдёт со временем?
Как вы создали эту сложность? Вам просто нужно масштабировать проект. Большее количество элементов часто означает больше зависимостей и выше сложность. Я уже написал об этом подробную статью [2].
Если вы объясните это Лёхе, вашему коллеге-разработчику, то он ответит:
«Нифига! Ты дурак? Хаосу и беспорядку не место в моём прекрасном приложении! Моя репутация не будет запятнана какой-то чушью! Я хозяин своей судьбы! Если я не меняю свою программу, то сложность не будет расти, и в связи с этим доказательством противоречия, я заявляю, что ты ошибаешься, а я — лучший!»
Вы можете спокойно, убедительно и решительно объяснить Лёхе, что даже если не менять программу, то изменится всё вокруг неё. Если у тебя есть сторонние библиотеки, которые не обновляются, то будут проблемы с безопасностью. А если их обновить, это откроет дверь изменениям и энтропии.
Более того, если однажды вам понадобится изменить что-то в своём ПО спустя длительное время, то вы уже не будете помнить всех подробностей. И вам не поможет даже лучшая документация. Мир изменился, и то, что было верно вчера, уже может никогда не быть верным, как на технологическом уровне, так и на уровне бизнеса.
Подобные изменения разом привносят большое количество энтропии.
Так что вопрос не в избавлении от неё, а в замедлении. Это настоящее сражение, в которое брошены мы, разработчики.
Как узнать, что в вашем приложении высокий уровень энтропии? Хорошим индикатором является качество кода.
Что это такое и как его измерить? Согласно книге Accelerate: The Science Behind Devops [3]:
Если вы можете получить какую-то информацию о соотношении изменений и сбоев, и потратить время на исправление багов, то сможете придумать хороший график, чтобы убедить руководство в необходимости какого-то рефакторинга.
Даже если у вас код максимального качества, сложность может легко возрастать, когда дело доходит до самих возможностей программы. Сам бизнес является источником необходимой сложности, от которой вы не сможете избавиться.
При избыточной сложности бизнеса разработчикам придётся потратить много сил, чтобы построить хорошую ментальную модель бизнеса компании. Поэтому они будут делать ошибки, пытаясь перевести бизнес-требования в код.
Давайте подробнее поговорим о сложности бизнеса: действительно ли нам нужны все эти сложные фичи, которые нам спускают?
Более-менее очевидно, что основной причиной энтропии в ПО являются сами разработчики. Они ленивы, им не хватает квалификации, особенно Саньку, с которым вы работаете. Он задаёт столько вопросов!
Я категорически не согласен с таким мнением. По моему опыту, основной причиной энтропии является руководство, особенно в компаниях, придерживающихся водопадного стиля управления.
Как заметил Джеральд Вайнберг [4] в книге The Secret of Consulting [5]:
Даже если это чисто техническая проблема, её происхождение всегда можно отследить вплоть до действия или бездействия руководства.
Я знаю, что вы подумали: «Ты ошибаешься! Руководство не всегда отвечает за всё! Просто разработчикам удобно во всём обвинять начальство!»
Я не говорю, что во всём виновато руководство, но у него всегда есть какая-то доля ответственности. Разработчик сделал что-то плохое? Тебе нужно пересмотреть процедуру найма. Спецификации были плохо реализованы? Возможно, кто-то из руководство не знает, чего на самом деле хочет, поэтому и спецификации для него не имеют значения.
Поэтому так трудно быть руководителем! Чем выше ты в иерархии, тем труднее.
Как разработчики, насколько сильно вы влияете на принятие решений? Если на 100 %, то поздравляю, во всём виноваты вы. Если на 0 %, то вашей вины нет. Между этими полюсами лежит весь спектр влияния. И водопад не подразумевает его большого количества.
Используете Scrum, Kanban и покер планирования? Конечно, вы не применяете водопад! Вы применяете Agile так же, как ребёнок строит дом с помощью отвёртки.
Конечно, инструменты важны, но их значимость гораздо ниже значимости вашего образа мышления [6], которое необходимо для корректной разработки ПО. Процитирую манифест Agile:
Личности и взаимодействия важнее процессов и инструментов.
Применение Scrum не означает, что ты применяешь «Agile», особенно если у тебя отсутствует образ
При водопадном управлении кто-то выше вас принимает решение, уровнем выше другие люди принимают новые решения, и так далее.
На нижних уровнях иерархии находятся сотрудники, чьё проклятие заключается в следовании всем принятым решениям. Какова их задача? Производить, словно рабочие на сборочном конвейере автозавода. Им не нужно думать, они должны делать машины [8].
Плохие новости: являясь разработчиком, вы будете на дне иерархии.
Если кто-то наверху принимает решения относительно функций приложения, и у вас практически нет возможностей повлиять на процесс принятия решений, тогда добро пожаловать в водопад! К сожалению, чаще всего высшее руководство не видит, что в мире разработки ПО не существует фазы производства. Разработчики занимаются проектированием системы, а эта задача далека от конвейерной сборки кабины.
Почему? Потому что, в отличие от автомобиля, приложения постоянно меняются! Вам нужно корректно проектировать их, чтобы они работали, отвечали потребностям пользователей, чтобы приложения имели приемлемую производительность, чтобы они были масштабируемы и были устойчивы к изменениям, при этом сохраняя энтропию на низком уровне. Для этого вам нужно принимать много решений о том, как отражать бизнес-знания в вашем коде.
Если вы не влияете на сложность, которая спускается вам руководством, то придётся потратить много сил на управление ей в коде. Это будет считаться «необходимой» сложностью: той, которой нельзя избежать.
Возможный результат? Уровень энтропии может расти очень, очень быстро.
В компании необходимо как можно активнее практиковать совместное принятие решений и ответственность.
Если вы узнали в описанной мной водопадной модели свою компанию, то вам нужно поговорить с теми, кто принимает решения:
Однако трудно пытаться решить проблему, если вас об этом не просили. Многие руководители очень довольны водопадной моделью, и зачастую даже не знают, что следуют ей. Вам понадобится много дипломатии и такта.
Учитывая всё это, если вы чувствуете, что бизнес-решения добавляют слишком много сложности в ваше приложение, и что вы ничего не можете с этим сделать, даже попытавшись, то советую найти другую работу. Это изматывает — изо дня в день работать с высокой энтропией, а делать раздутый продукт удовольствия мало… или использовать его. Это может дать вам подсказку относительно успеха, который ожидает ваш продукт.
И последнее: то, что может выглядеть сложным на уровне бизнеса, можно упростить, если вы хорошо знаете бизнес-процессы. Это крайне важно. Поэтому узнавайте больше о деятельности своей компании, что здесь делают и что не делают, это поможет упростить фичи и кодовую базу.
По мере выражения своего архитектуры мы что-то объясняем компьютеру. А для этого нам нужно хорошо понимать то, что мы объясняем.
Дональд Кнут [9]
Помимо «необходимой» сложности, привносимой бизнесом, энтропия в ПО тесно связана с качеством кода и техническим долгом.
Что такое технический долг? Попросту говоря, это упрощения (хаки), которые вы используете для экономии времени, зная, что позднее вам это может аукнуться. Особенно в тех случаях, если от этих хаков зависят другие фичи: вам придётся это исправлять с процентами, как и при настоящем долге, в виде сложностей и головной боли.
В зависимости от задачи вашего приложения, технический долг может быть более или менее приемлемым. Если программа должна прожить пару месяцев, то можно вообще не думать о техническом долге, энтропии или качестве. Просто соедините куски кода, и готово!
К примеру, это может быть временным решением, прежде чем создавать более сложное приложение с нуля. Или так можно быстро написать прототип, чтобы проиллюстрировать идею, а затем всё переписать или отказаться от концепции.
С другой стороны, обычно компании хотят разрабатывать более долгоживущие приложения. Это разумно: переписывание приложение может стоить очень дорого (особенно, если оно большое), и никто не гарантирует, что его уровень энтропии окажется ниже. Переписывание — занятие очень рискованное.
В подобных случаях вам нужно быть очень осторожными с техническим долгом и качеством кода. Это важная часть вашей работы как разработчика.
В известной книге The Pragmatic Programmer [10] (в которой помимо много другого введён принцип DRY [11]) приведена интересная аналогия технического долга. Здесь описано исследование, в котором сопоставлены разрушения городских зданий с… выбитыми в них окнами. Разбитое окно создаёт впечатление заброшенности, вдохновляя каждого хулигана в округе. В результате здания с разбитыми окнами подвергаются вандализму быстрее, чем здания с целыми окнами.
Технический долг — это упрощение или хак в вашем коде, разбитое окно. Когда другой разработчик, или даже вы сами в будущем, заметит это, то возникнет соблазн добавить ещё больше технического долга, потому что «здесь всё равно есть плохой код, так чего париться?»
Пример: вы написали обход для одного сложного бага, потому что не было времени его выискивать. Другой разработчик (или вы сами позднее) поверх этого обхода может написать другой код, решая другую проблему. Очень быстро нарастут слои обходных решений, в которых никто никогда не разберётся.
Во-первых, как узнать, что в коде есть технический долг?
Спросите себя:
Чем больше будут расти ваши знания и опыт, чем больше вы будете любознательны и чаще будете проводить здоровые обсуждения с другими разработчиками, тем чаще вы станете замечать паттерны технического долга. Это код с душком.
Встречая такие паттерны, пожалуйста, не расценивайте их как разрешение добавлять ещё больше технического долга:
Не забывайте, что рефакторить нужно параллельно с разработкой других фич, чтобы они соответствовали текущей архитектуре. Попросту говоря, исправление технического долга должно быть не самостоятельной задачей, а продолжающимся процессом, который может быть не связан с текущей задачей. Разрабатывая фичу, дайте себе право исправить встреченный технический долг.
Рефакторьте маленькие фрагменты кода за раз и часто прогоняйте тесты, чтобы убедиться, что система ведёт себя как ожидается.
Наконец, в ходе рефакторинга вам могут понадобиться хорошие аргументы:
Хорошие аргументы в будущем всегда играют положительную роль. Например, обёртывание сторонней библиотеки, чтобы она не стала причиной утечки в вашей кодовой базе. Если вы не понимаете, почему я говорю про утечку, то почитайте, что я писал об абстракциях [12].
Нам, людям, трудно даются прогнозы в средне- и долгосрочной перспективе. Поэтому не всегда просто рефакторить или «продавать» нечто с прицелом на неизвестное будущее.
Технический долг отражает дуализм между простым и правильным путями. Первый быстр и привлекателен, второй сделает ваш проект масштабируемым и лёгким в сопровождении. Вам понадобится самодисциплина, чтобы как можно чаще выбирать второй путь. Иначе будущее будет наполнено страданиями.
Если вы слишком устали, раздражены или полны других мыслей или эмоций, снижающих вашу мотивацию, чтобы придерживаться правильного пути, а не простого, то лучше пока не программируйте. Прогуляйтесь, поговорите с коллегами, сделайте перерыв. Вернитесь к коду со свежими мозгами.
Чаще всего технический долг добавляется при отладке. Если вы исправляете баг, добавляя обходное решение, то вы ничего не исправили. Баг остался, просто его труднее запустить и случайно найти. Исправлять баги нужно с помощью рефакторинга, изменения или полного удаления кода. Затем протестируйте код, чтобы удостовериться, что баг не возникнет снова.
Последнее: винить коллег за ошибки непродуктивно. Если будете плохо или саркастично высказываться о своей кодовой базе, это тоже не решит проблем, только ухудшит ситуацию. Не разрушайте командный дух. Вам нужно уменьшать энтропию в проекте, а не разрушать его устно.
Есть кое-что завораживающее меня в волшебном мире разработки ПО, особенно в стартапах: многие программисты до сих пор не хотят писать автоматизированные тесты.
Почему меня это завораживает? Во всех остальных сферах инжиниринга тестируют то, что делают, следуя строгому процессу. Когда строишь ракету, то необходимо протестировать множество систем, или ракета упадёт. То же самое относится к автомобилям, мостам, самолётам — чему угодно.
Экономия денег.
Простой пример: NASA тщательно тестирует свой код (см. правило 5) [13].
Трудно найти руководителей или разработчиков, которые против тестов, но легко найти тех, кто против автоматизированных тестов. Эти люди предпочтут тратить время на ручное тестирование любых изменений, вместо того, чтобы один раз написать тесты.
Я тоже не без греха. Годами я занимался тем же самым.
Надеюсь, все согласны с тем, что компьютинг — это автоматизация для нас людей, которая экономит наше время и повышает нашу эффективность. Так почему бы не автоматизировать и тесты? Да, я считаю это целесообразным. Тестирование, как и рефакторинг, требует времени на написание кода (как и всё остальное), но экономит время, энергию и рассудок в средне- и долгосрочной перспективе.
Вот очень простой индикатор того, что у приложения может быть высокий уровень энтропии: если есть хорошие автоматизированные тесты, то уровень энтропии может быть низким. Если таких тестов нет, уровень энтропии является высоким.
Чем больше проект, тем сильнее будет последнее заявление.
Если ваши коллеги или лица, принимающие решения, не хотят слышать о тестировании, вам понадобятся сильны аргументы.
Вот конкретный пример. В одном банке из-за недостаточного тестирования было потеряно 1,3 млрд клиентских записей [14]. И вам не нужно быть банком, чтобы иметь баги и терять данные. Достаточно сказать «нет» автоматизированным тестам.
Аргументы против тестов часто связаны со скоростью:
Повторюсь, что, даже если вы потратите какое-то время на написание тестов (хотя я в этом и сомневаюсь), зато сэкономите много времени и энергии в будущем:
Тестирование даст вам ощущения контроля над вашим кодом, и поэтому уменьшит у всех стресс [15].
Я не утверждаю, что нужно всё проверять с помощью модульных тестов. Я не утверждаю, что покрытие должно быть стопроцентным. Я не утверждаю, что модульное тестирование лучше любого другого.
Я говорю, что вам нужно тестировать код, когда это целесообразно. Сэнди Метц хорошо рассказала об этом в своём выступлении [16].
Также полезно тестировать в ходе исправления багов, чтобы удостовериться, что баги не возникнут снова. Затем можете показать тест всем противникам и сказать, что этого бага могло бы не быть, если бы кто-нибудь с самого начала написал тест.
Если после этих аргументов ваша команда всё ещё не хочет писать тесты, то в причина может быть в том, что они просто не умеют. Вместо того, чтобы ругать их, вы можете:
Если в команде есть начинающие разработчики, научите их искусству тестирования. Я часто встречаю точку зрения, что начинающих не нужно обучать тестированию. Это ошибка. Тесты должны считаться частью вашего кода, частью будущего, которое вы создаёте, а не чем-то опциональным, побочным.
Тесты — это клей, который позволяет всей системе чётко работать.
Тестирование ведёт к сбоям, а сбои ведут к пониманию.
Берт Рутан
Очень важно делиться знаниями с командой:
Это снизит энтропию в вашем проекте. Команда будет более мотивирована хорошо выполнить работу, все будут учиться друг у друга писать более качественный, более чистый код.
Как преуспеть в этом начинании?
Совместное программирование — это обмен опытом. Кто-то пишет код и показывает другому, как он это делает. А второй указывает на ошибки, даёт советы и подсказки.
Вот и всё! Если разработчики заинтересованы, то получается забавно.
Но, к сожалению, совместное программирование часто считают потерей времени.
Лёха, ваш коллега, выразил распространённое мнение об этом: «Два разраба будут кодить две разные фичи быстрее, чем одну, верно? К тому же тут один разрабатывает, а второй просто смотрит в экран. Потеря времени!».
Вы можете объяснить ему: мы хотим писать качественный код, а не много кода. Код нам не друг, он источник багов. Нам нужно бороться с энтропией, а не как можно быстрее писать код.
Если те, кто принимает решения, вас не поймут, ищите другую работу. Если вы этого не сделаете, то со временем получите пачку устаревших приложений, которые невозможно сопровождать. Добро пожаловать в ад!
Это ещё один хороший способ делиться своими знаниями. Анализ кода может:
Все должны анализировать чужой код, как их код должен анализироваться. Это верно и для опытных, и для начинающих. Анализ кода позволит находить баги и, что важнее, повысит навыки всей команды.
Вы жалуетесь на Коляна, начинающего разраба, потому что он ничего не знает про принцип единственной ответственности. В его коде бардак?
Всегда лучше учить, а не обвинять. Дайте ему хороший совет, подскажите полезные источники информации, поделитесь знанием и энтузиазмом.
Несколько советов по проведению анализа кода:
Эти подходы могут спровоцировать интересные дискуссии и здоровые обсуждения, что ещё больше повысит ценность вашей команды. Очевидно, что обсуждать нужно уважительно и конструктивно [17]!
Делитесь с коллегами интересными статьями (вроде этой!) в любых мессенджерах и прочих каналах коммуникации.
Важно также экспериментировать с командой. Если вы считаете, что новая технология может решить одну из ваших проблем, проведите совместное программирование и проверьте эти возможности.
Не забудьте, что передача знаний — это забота и повышение эрудиции и опыта команды, в которой вы работаете, и хороший способ писать более качественный и чистый код. Это поможет держать уровень энтропии на минимальном уровне!
Тем, кто всё ещё думает, что первой причиной энтропии в ПО является лень, я возражу, что она никогда не бывает основной причиной. Почему ваши коллеги ленивы? Потому что кадровики наняли не тех? Или у них слишком силён стресс из-за сжатых сроков? Работа приносит им удовлетворение?
Поговорите с командой. Спросите, нравится ли им работать с вами. Интересуйтесь по-настоящему, какие они люди. Прислушайтесь к тому, что они скажут, к их отзывам, даже если вы не согласны с их мнениями.
Честно говоря, вам понадобится приличная порция эмпатии и открытости, чтобы эффективно работать с людьми. Обвинения и критика ничего никому не дадут. А указывать на лень — это обвинение.
Итак. Что вы для себя вынесли из этой статьи?
Идеального ПО не существует. Энтропия всегда будет частью нашей работы. Это не означает, что мы уже проиграли эту битву. Это означает, что снижение энтропии во всей кодовой базе — уже победа!
Полезные ссылки:
Автор: AloneCoder
Источник [22]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/339563
Ссылки в тексте:
[1] Object-Oriented Software Engineering: https://www.goodreads.com/book/show/296981.Object_Oriented_Software_Engineering
[2] подробную статью: https://thevaluable.dev/kiss-principle-explained/
[3] Accelerate: The Science Behind Devops: https://www.goodreads.com/book/show/40313863-accelerate
[4] Джеральд Вайнберг: https://en.wikipedia.org/wiki/Gerald_Weinberg
[5] The Secret of Consulting: https://www.goodreads.com/book/show/566213.The_Secrets_of_Consulting
[6] гораздо ниже значимости вашего образа мышления: https://thevaluable.dev/page/principles/
[7] мышления: http://www.braintools.ru
[8] они должны делать машины: https://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%83%D1%87%D0%BD%D0%B0%D1%8F_%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%82%D1%80%D1%83%D0%B4%D0%B0
[9] Дональд Кнут: https://www.idnes.cz/technet/technika/donald-knuth-interview-computer-science-brno-czech-republic.A191016_112708_tec_technika_pka
[10] The Pragmatic Programmer: https://www.goodreads.com/book/show/4099.The_Pragmatic_Programmer
[11] принцип DRY: https://thevaluable.dev/dry-principle-explained/
[12] я писал об абстракциях: https://thevaluable.dev/abstraction_software_development/
[13] NASA тщательно тестирует свой код (см. правило 5): http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
[14] из-за недостаточного тестирования было потеряно 1,3 млрд клиентских записей: https://increment.com/testing/what-broke-the-bank/
[15] уменьшит у всех стресс: https://thevaluable.dev/developer-stress-management/
[16] своём выступлении: https://www.youtube.com/watch?v=URSWYvyc42M
[17] уважительно и конструктивно: https://thevaluable.dev/guide-debate-software-developer-skill/
[18] The Pragmatic Programmer: https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition
[19] Software Entropy Explained: Causes, Effects, and Remedies: https://www.toptal.com/software/software-entropy-explained
[20] Entropy in software: https://lostechies.com/jimmybogard/2009/02/11/entropy-in-software/
[21] Software Rot, Entropy and the Broken Window Theory: https://codeahoy.com/2016/05/02/software-rot-entropy-and-the-broken-window-theory/
[22] Источник: https://habr.com/ru/post/479516/?utm_campaign=479516&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.