Что такое энтропия в информатике простыми словами
Введение в понятие энтропии и ее многоликость
Как может показаться, анализ сигналов и данных — тема достаточно хорошо изученная и уже сотни раз проговоренная. Но есть в ней и некоторые провалы. В последние годы словом «энтропия» бросаются все кому не лень, толком и не понимая, о чем говорят. Хаос — да, беспорядок — да, в термодинамике используется — вроде тоже да, применительно к сигналам — и тут да. Хочется хотя бы немного прояснить этот момент и дать направление тем, кто захочет узнать чуть больше об энтропии. Поговорим об энтропийном анализе данных.
В русскоязычных источниках очень мало литературы на этот счет. А цельное представление вообще получить практически нереально. Благо, моим научным руководителем оказался как раз знаток энтропийного анализа и автор свеженькой монографии [1], где все расписано «от и до». Счастью предела не было, и я решила попробовать донести мысли на этот счет до более широкой аудитории, так что пару выдержек возьму из монографии и дополню своими исследованиями. Может, кому и пригодится.
Итак, начнем с начала. Шенноном в 1963 г. было предложено понятие меры усредненной информативности испытания (непредсказуемости его исходов), которая учитывает вероятность отдельных исходов (до него был еще Хартли, но это опустим). Если энтропию измерять в битах, и взять основание 2, то получим формулу для энтропии Шеннона 
, где Pi это вероятность наступления i-го исхода.
То есть в этом случае энтропия напрямую связана с «неожиданностью» возникновения события. А отсюда вытекает и его информативность — чем событие более предсказуемо, тем оно менее информативно. Значит и его энтропия будет ниже. Хотя открытым остается вопрос о соотношениях между свойствами информации, свойствами энтропии и свойствами различных ее оценок. Как раз с оценками мы и имеем дело в большинстве случаев. Все, что поддается исследованию — это информативность различных индексов энтропии относительно контролируемых изменений свойств процессов, т.е. по существу, их полезность для решения конкретных прикладных задач.
Энтропия сигнала, описываемого некоторым образом (т.е. детерминированного) стремится к нулю. Для случайных процессов энтропия возрастает тем больше, чем выше уровень «непредсказуемости». Возможно, именно из такой связки трактовок энтропии вероятность->непредсказуемость->информативность и вытекает понятие «хаотичности», хотя оно достаточно неконкретно и расплывчато (что не мешает его популярности). Встречается еще отождествление энтропии и сложности процесса. Но это снова не одно и то же.
Для того, чтобы немного обрисовать области применения энтропии к анализу данных, рассмотрим небольшую прикладную задачку из монографии [1] (которой нет в цифровом виде, и скорей всего не будет).
Пусть есть система, которая каждые 100 тактов переключается между несколькими состояниями и порождает сигнал x (рисунок 1.5), характеристики которого изменяются при переходе. Но какие — нам не известно.
Разбив x на реализации по 100 отсчетов можно построить эмпирическую плотность распределения и по ней вычислить значение энтропии Шеннона. Получим значения, «разнесенные» по уровням (рисунок 1.6).
Как можно видеть, переходы между состояниями явно наблюдаются. Но что делать в случае, если время переходов нам не известно? Как оказалось, вычисление скользящим окном может помочь и энтропия так же «разносится» на уровни.В реальном исследовании мы использовали такой эффект для анализа ЭЭГ сигнала (разноцветные картинки про него будут дальше).
Теперь еще про одно занятное свойство энтропии — она позволяет оценить степень связности нескольких процессов. При наличии у них одинаковых источников мы говорим, что процессы связаны (например, если землетрясение фиксируют в разных точках Земли, то основная составляющая сигнала на датчиках общая). В таких случаях обычно применяют корреляционный анализ, однако он хорошо работает только для выявления линейных связей. В случае же нелинейных (порожденных временными задержками, например) предлагаем пользоваться энтропией.
Рассмотрим модель из 5ти скрытых переменных(их энтропия показана на рисунке ниже слева) и 3х наблюдаемых, которые генерируются как линейная сумма скрытых, взятых с временными сдвигами по схеме, показанной ниже справа. Числа-это коэффициенты и временные сдвиги (в отсчетах).
Так вот, фишка в том, что энтропия связных процессов сближается при усилении их связи. Черт побери, как это красиво-то!
Такие радости позволяют вытащить практически из любых самых странных и хаотичных сигналов (особенно полезно в экономике и аналитике) дополнительные сведения. Мы их вытаскивали из электроэнцефалограммы, считая модную нынче Sample Entropy и вот какие картинки получили.
Можно видеть, что скачки энтропии соответствуют смене этапов эксперимента. На эту тему есть пара статей и уже защищена магистерская, так что если кому будут интересны подробности — с радостью поделюсь. А так по миру по энтропии ЭЭГ ищут уже давно разные вещи — стадии наркоза, сна, болезни Альцгеймера и Паркинсона, эффективность лечения от эпилепсии считают и тд. Но повторюсь-зачастую расчеты ведутся без учета поправочных коэффициентов и это грустно, так как воспроизводимость исследований под большим вопросом (что критично для науки, так то).
Резюмируя, остановлюсь на универсальности энтропийного аппарата и его действительной эффективности, если подходить ко всему с учетом подводных камней. Надеюсь, что после прочтения у вас зародится зерно уважения к великой и могучей силе Энтропии.
Энтропия? Это просто!
Этот пост является вольным переводом ответа, который Mark Eichenlaub дал на вопрос What’s an intuitive way to understand entropy?, заданный на сайте Quora
Энтропия. Пожалуй, это одно из самых сложных для понимания понятий, с которым вы можете встретиться в курсе физики, по крайней мере если говорить о физике классической. Мало кто из выпускников физических факультетов может объяснить, что это такое. Большинство проблем с пониманием энтропии, однако, можно снять, если понять одну вещь. Энтропия качественно отличается от других термодинамических величин: таких как давление, объём или внутренняя энергия, потому что является свойством не системы, а того, как мы эту систему рассматриваем. К сожалению в курсе термодинамики её обычно рассматривают наравне с другими термодинамическими функциями, что усугубляет непонимание.
Так что же такое энтропия?
Энтропия — это то, как много информации вам не известно о системе
Например, если вы спросите меня, где я живу, и я отвечу: в России, то моя энтропия для вас будет высока, всё-таки Россия большая страна. Если же я назову вам свой почтовый индекс: 603081, то моя энтропия для вас понизится, поскольку вы получите больше информации.
Почтовый индекс содержит шесть цифр, то есть я дал вам шесть символов информации. Энтропия вашего знания обо мне понизилась приблизительно на 6 символов. (На самом деле, не совсем, потому что некоторые индексы отвечают большему количеству адресов, а некоторые — меньшему, но мы этим пренебрежём). 
Или рассмотрим другой пример. Пусть у меня есть десять игральных костей (шестигранных), и выбросив их, я вам сообщаю, что их сумма равна 30. Зная только это, вы не можете сказать, какие конкретно цифры на каждой из костей — вам не хватает информации. Эти конкретные цифры на костях в статистической физике называют микросостояниями, а общую сумму (30 в нашем случае) — макросостоянием. Существует 2 930 455 микросостояний, которые отвечают сумме равной 30. Так что энтропия этого макросостояния равна приблизительно 6,5 символам (половинка появляется из-за того, что при нумерации микросостояний по порядку в седьмом разряде вам доступны не все цифры, а только 0, 1 и 2).
А что если бы я вам сказал, что сумма равна 59? Для этого макросостояния существует всего 10 возможных микросостояний, так что его энтропия равна всего лишь одному символу. Как видите, разные макросостояния имеют разные энтропии.
Пусть теперь я вам скажу, что сумма первых пяти костей 13, а сумма остальных пяти — 17, так что общая сумма снова 30. У вас, однако, в этом случае имеется больше информации, поэтому энтропия системы для вас должна упасть. И, действительно, 13 на пяти костях можно получить 420-ю разными способами, а 17 — 780-ю, то есть полное число микросостояний составит всего лишь 420х780 = 327 600. Энтропия такой системы приблизительно на один символ меньше, чем в первом примере.
Мы измеряем энтропию как количество символов, необходимых для записи числа микросостояний. Математически это количество определяется как логарифм, поэтому обозначив энтропию символом S, а число микросостояний символом Ω, мы можем записать:
Это есть ничто иное как формула Больцмана (с точностью до множителя k, который зависит от выбранных единиц измерения) для энтропии. Если макросостоянию отвечают одно микросостояние, его энтропия по этой формуле равна нулю. Если у вас есть две системы, то полная энтропия равна сумме энтропий каждой из этих систем, потому что log(AB) = log A + log B. 
Из приведённого выше описания становится понятно, почему не следует думать об энтропии как о собственном свойстве системы. У системы есть опеделённые внутренняя энергия, импульс, заряд, но у неё нет определённой энтропии: энтропия десяти костей зависит от того, известна вам только их полная сумма, или также и частные суммы пятёрок костей.
Другими словами, энтропия — это то, как мы описываем систему. И это делает её сильно отличной от других величин, с которыми принято работать в физике.
Физический пример: газ под поршнем
Классической системой, которую рассматривают в физике, является газ, находящийся в сосуде под поршнем. Микросостояние газа — это положение и импульс (скорость) каждой его молекулы. Это эквивалентно тому, что вы знаете значение, выпавшее на каждой кости в рассмотренном раньше примере. Макросостояние газа описывается такими величинами как давление, плотность, объём, химический состав. Это как сумма значений, выпавших на костях.
Величины, описывающие макросостояние, могут быть связаны друг с другом через так называемое «уравнение состояния». Именно наличие этой связи позволяет, не зная микросостояний, предсказывать, что будет с нашей системой, если начать её нагревать или перемещать поршень. Для идеального газа уравнение состояния имеет простой вид:
Величины типа давления, температуры и плотности называются усреднёнными, поскольку являются усреднённым проявлением постоянно сменяющих друг друга микросостояний, отвечающих данному макросостоянию (или, вернее, близким к нему макросостояниям). Чтобы узнать в каком микросостоянии находится система, нам надо очень много информации — мы должны знать положение и скорость каждой частицы. Количество этой информации и называется энтропией.
Как меняется энтропия с изменением макросостояния? Это легко понять. Например, если мы немного нагреем газ, то скорость его частиц возрастёт, следовательно, возрастёт и степень нашего незнания об этой скорости, то есть энтропия вырастет. Или, если мы увеличим объём газа, отведя поршень, увеличится степень нашего незнания положения частиц, и энтропия также вырастет.
Твёрдые тела и потенциальная энергия
Если мы рассмотрим вместо газа какое-нибудь твёрдое тело, особенно с упорядоченной структурой, как в кристаллах, например, кусок металла, то его энтропия будет невелика. Почему? Потому что зная положение одного атома в такой структуре, вы знаете и положение всех остальных (они же выстроены в правильную кристаллическую структуру), скорости же атомов невелики, потому что они не могут улететь далеко от своего положения и лишь немного колеблются вокруг положения равновесия. 
Если кусок металла находится в поле тяготения (например, поднят над поверхностью Земли), то потенциальная энергия каждого атома в металле приблизительно равна потенциальной энергии других атомов, и связанная с этой энергией энтропия низка. Это отличает потенциальную энергию от кинетической, которая для теплового движения может сильно меняться от атома к атому.
Если кусок металла, поднятый на некоторую высоту, отпустить, то его потенциальная энергия будет переходить в кинетическую энергию, но энтропия возрастать практически не будет, потому что все атомы будут двигаться приблизительно одинаково. Но когда кусок упадёт на землю, во время удара атомы металла получат случайное направление движения, и энтропия резко увеличится. Кинетическая энергия направленного движения перейдёт в кинетическую энергию теплового движения. Перед ударом мы приблизительно знали, как движется каждый атом, теперь мы эту информацию потеряли.
Понимаем второй закон термодинамики
Второй закон термодинамики утверждает, что энтропия (замкнутой системы) никогда не уменьшается. Мы теперь можем понять, почему: потому что невозможно внезапно получить больше информации о микросостояниях. Как только вы потеряли некую информацию о микросостоянии (как во время удара куска металла об землю), вы не можете вернуть её назад. 
Давайте вернёмся обратно к игральным костям. Вспомним, что макросостояние с суммой 59 имеет очень низкую энтропию, но и получить его не так-то просто. Если бросать кости раз за разом, то будут выпадать те суммы (макросостояния), которым отвечает большее количество микросостояний, то есть будут реализовываться макросостояния с большой энтропией. Самой большой энтропией обладает сумма 35, и именно она и будет выпадать чаще других. Именно об этом и говорит второй закон термодинамики. Любое случайное (неконтролируемое) взаимодействие приводит к росту энтропии, по крайней мере до тех пор, пока она не достигнет своего максимума.
Перемешивание газов
И ещё один пример, чтобы закрепить сказанное. Пусть у нас имеется контейнер, в котором находятся два газа, разделённых расположенной посередине контейнера перегородкой. Назовём молекулы одного газа синими, а другого — красными.
Если открыть перегородку, газы начнут перемешиваться, потому что число микросостояний, в которых газы перемешаны, намного больше, чем микросостояний, в которых они разделены, и все микросостояния, естественно, равновероятны. Когда мы открыли перегородку, для каждой молекулы мы потеряли информацию о том, с какой стороны перегородки она теперь находится. Если молекул было N, то утеряно N бит информации (биты и символы, в данном контексте, это, фактически, одно и тоже, и отличаются только неким постоянным множителем).
Разбираемся с демоном Максвелла
Ну и напоследок рассмотрим решение в рамках нашей парадигмы знаменитого парадокса демона Максвелла. Напомню, что он заключается в следующем. Пусть у нас есть перемешанные газы из синих и красных молекул. Поставим обратно перегородку, проделав в ней небольшое отверстие, в которое посадим воображаемого демона. Его задача — пропускать слева направо только красных, и справа налево только синих. Очевидно, что через некоторое время газы снова будут разделены: все синие молекулы окажутся слева от перегородки, а все красные — справа.
Получается, что наш демон понизил энтропию системы. С демоном ничего не случилось, то есть его энтропия не изменилась, а система у нас была закрытой. Получается, что мы нашли пример, когда второй закон термодинамики не выполняется! Как такое оказалось возможно?
Решается этот парадокс, однако, очень просто. Ведь энтропия — это свойство не системы, а нашего знания об этой системе. Мы с вами знаем о системе мало, поэтому нам и кажется, что её энтропия уменьшается. Но наш демон знает о системе очень много — чтобы разделять молекулы, он должен знать положение и скорость каждой из них (по крайней мере на подлёте к нему). Если он знает о молекулах всё, то с его точки зрения энтропия системы, фактически, равна нулю — у него просто нет недостающей информации о ней. В этом случае энтропия системы как была равна нулю, так и осталась равной нулю, и второй закон термодинамики нигде не нарушился.
Но даже если демон не знает всей информации о микросостоянии системы, ему, как минимум, надо знать цвет подлетающей к нему молекулы, чтобы понять, пропускать её или нет. И если общее число молекул равно N, то демон должен обладать N бит информации о системе — но именно столько информации мы и потеряли, когда открыли перегородку. То есть количество потерянной информации в точности равно количеству информации, которую необходимо получить о системе, чтобы вернуть её в исходное состояние — и это звучит вполне логично, и опять же не противоречит второму закону термодинамики.
Энтропия (в теории информации)
В теории информации, энтропия Шеннона, или информационная энтропия — мера неопределённости, связанной со случайной величиной (с.в.); определяет количество информации, содержавшейся в сообщении (обычно в битах или битах на символ); минимальная длина сообщения, необходимая для передачи информации; также абсолютный предел наиболее возможного сжатия без потерь любого сообщения: при представлении сообщения рядом символов, кратчайшее представление, необходимое для передачи сообщения — это энтропия Шеннона в битах на символ, умноженная на число символов в исходном сообщении.
Эквивалентно, энтропия Шеннона — мера среднего информационного содержания с.в., которое наблюдатель (получатель сообщения) теряет, когда ему неизвестно значение (исход) с.в.
Содержание
Определение
Энтропия Шеннона дискретной с.в. 
, которая может принимать значения , равна величине
Характеризация
Определим и меру информационной энтропии
Информационная энтропия характеризуется следующими пожеланиями (desiderata):
Непрерывность Мера должна быть непрерывной — то есть, изменение значения одной из вероятностей на очень маленькую величину должно изменить энтропию также на маленькую величину. Симметрия Мера не должна меняться, если исходы переупорядочены: и т.д. Максимум Мера должна быть максимальной, если все исходы одинаково вероятны (неопределённость является самой высокой, когда все возможные события равновероятны). Для равновероятных событий энтропия должна увеличиваться с увеличением их числа: Аддитивность Количество энтропии не должно зависеть от того, как система событий разделена на части (подсистемы). Это последнее функциональное отношение характеризует энтропию системы с подсистемами и требует, чтобы энтропия системы могла быть вычислена через энтропии ее подсистем, если мы знаем, как подсистемы взаимодействуют с друг другом. Дан ансамбль из равномерно распределённых элементов, которые произвольно разделены на коробок (подсистем) с элементами соответственно; энтропия всего ансамбля должна быть равна сумме энтропии системы коробок и индивидуальных энтропий коробок, взвешенных с вероятностью обнаружения элемента в соответстувующей коробке. Для положительных целых чисел , Выбор подразумевает, что энтропия конкретного исхода равна нулю:
Можно показать, что любое определение энтропии, удовлетворяющее этим предположениям имеет форму
где — постоянная, соответствующая выбору единицы измерения.
Пояснения
Пример
Дальнейшие свойства
Увеличение энтропии Байеса — закон, согласно которому по мере увеличения выборки сравнения объектов А` для идентификации объекта А, индивидуальные особенности объекта А размываются по отношению к выборке, а идентификация становится бессмысленной. Другими словами с увеличение выборки у объекта А по отношению к ней увеличивается энтропия.
Считается, что закон был открыт эмпирически, до его математического доказательства британским математиком Томасом Байесом. В настоящее время в разных интерпретациях используется в кибернетике, информатике, теории систем, менеджменте и других науках. Некоторые математики и физики считают этот закон еще одним из начал термодинамики.
Пример. Если кто-то захочет установить личность человека, попавшего на видеокамеры, то процесс будет становится тем более бессмысленным, чем с большим количеством людей будет сравнен человек.
Что такое энтропия в ПО и как ею управлять?
Сегодня солнечный день. Вы едете по дороге в вашу деревню, в которой живут все ваши друзья, ваша семья и ваша любимая собака. Прекрасный день! Неожиданно вы слышите ужасный, кошмарный вопль, разрывающий окрестности. Огромная отвратительная Гидра приближается к деревне, чтобы её уничтожить! Вы хватаете меч (конечно, у вас есть меч!) и стараетесь защитить всех, кого любите. Но есть небольшая проблема: у чудовища много голов, и когда вы отрубаете одну из них, быстро вырастает новая!
Кажется, что вы не можете победить в этой битве. Возможно, вы сможете играть с Гидрой достаточно долго, так чтобы вся деревня успела улететь от ужасной угрозы? Наконец, вы станете настоящий героем всего мира! Кому этого не хочется?
В роли Гидры выступает энтропия в ПО: это ваш враг, он вас измотает, но вы никогда не сможете полностью от него избавиться. Но с ним всё равно нужно бороться, чтобы ваши приложения (и коллеги) оставались здоровыми и вменяемыми.
Знай своего врага
Что такое энтропия и как она оказалась в моём приложении?
Иногда полезно выяснить этимологию используемых слов, особенно таких специфических, как энтропия. В перевод с греческого оно означает «трансформация». Изменение. Нечто, к чему вы должны привыкнуть как разработчик ПО.
Энтропия ссылается на второй закон термодинамики. Он гласит, что в закрытой изолированной системе количество хаоса со временем не уменьшается. Оно остаётся стабильным или растёт.
Идея энтропии в ПО возникла благодаря книге Object-Oriented Software Engineering. Чем больше меняется программа, тем больше в ней хаоса, её энтропия увеличивается.
Первое, что нужно уяснить нам, бедным разработчикам, это трагическая правда: мы можем бороться с количеством энтропии в наших программах, но никогда не сможем от неё избавиться.
Создайте лучшую команду (с вашим участием, разумеется!), лучшую среду, лучший менеджмент, лучшую культуру в компании, лучший проект. Что произойдёт со временем?
Если вы объясните это Лёхе, вашему коллеге-разработчику, то он ответит:
«Нифига! Ты дурак? Хаосу и беспорядку не место в моём прекрасном приложении! Моя репутация не будет запятнана какой-то чушью! Я хозяин своей судьбы! Если я не меняю свою программу, то сложность не будет расти, и в связи с этим доказательством противоречия, я заявляю, что ты ошибаешься, а я — лучший!»
Вы можете спокойно, убедительно и решительно объяснить Лёхе, что даже если не менять программу, то изменится всё вокруг неё. Если у тебя есть сторонние библиотеки, которые не обновляются, то будут проблемы с безопасностью. А если их обновить, это откроет дверь изменениям и энтропии.
Более того, если однажды вам понадобится изменить что-то в своём ПО спустя длительное время, то вы уже не будете помнить всех подробностей. И вам не поможет даже лучшая документация. Мир изменился, и то, что было верно вчера, уже может никогда не быть верным, как на технологическом уровне, так и на уровне бизнеса.
Подобные изменения разом привносят большое количество энтропии.
Так что вопрос не в избавлении от неё, а в замедлении. Это настоящее сражение, в которое брошены мы, разработчики.
Определение энтропии в ПО
Качество ПО
Как узнать, что в вашем приложении высокий уровень энтропии? Хорошим индикатором является качество кода.
Что это такое и как его измерить? Согласно книге Accelerate: The Science Behind Devops:
Демон сложности
Даже если у вас код максимального качества, сложность может легко возрастать, когда дело доходит до самих возможностей программы. Сам бизнес является источником необходимой сложности, от которой вы не сможете избавиться.
При избыточной сложности бизнеса разработчикам придётся потратить много сил, чтобы построить хорошую ментальную модель бизнеса компании. Поэтому они будут делать ошибки, пытаясь перевести бизнес-требования в код.
Давайте подробнее поговорим о сложности бизнеса: действительно ли нам нужны все эти сложные фичи, которые нам спускают?
Причина энтропии, и как с ней бороться
Водопад энтропии
Проблема
Более-менее очевидно, что основной причиной энтропии в ПО являются сами разработчики. Они ленивы, им не хватает квалификации, особенно Саньку, с которым вы работаете. Он задаёт столько вопросов!
Я категорически не согласен с таким мнением. По моему опыту, основной причиной энтропии является руководство, особенно в компаниях, придерживающихся водопадного стиля управления.
Даже если это чисто техническая проблема, её происхождение всегда можно отследить вплоть до действия или бездействия руководства.
Я знаю, что вы подумали: «Ты ошибаешься! Руководство не всегда отвечает за всё! Просто разработчикам удобно во всём обвинять начальство!»
Я не говорю, что во всём виновато руководство, но у него всегда есть какая-то доля ответственности. Разработчик сделал что-то плохое? Тебе нужно пересмотреть процедуру найма. Спецификации были плохо реализованы? Возможно, кто-то из руководство не знает, чего на самом деле хочет, поэтому и спецификации для него не имеют значения.
Поэтому так трудно быть руководителем! Чем выше ты в иерархии, тем труднее.
Как разработчики, насколько сильно вы влияете на принятие решений? Если на 100 %, то поздравляю, во всём виноваты вы. Если на 0 %, то вашей вины нет. Между этими полюсами лежит весь спектр влияния. И водопад не подразумевает его большого количества.
Используете Scrum, Kanban и покер планирования? Конечно, вы не применяете водопад! Вы применяете Agile так же, как ребёнок строит дом с помощью отвёртки.
Конечно, инструменты важны, но их значимость гораздо ниже значимости вашего образа мышления, которое необходимо для корректной разработки ПО. Процитирую манифест Agile:
Личности и взаимодействия важнее процессов и инструментов.
Применение Scrum не означает, что ты применяешь «Agile», особенно если у тебя отсутствует образ мышления, которому пытается научить эта методология.
При водопадном управлении кто-то выше вас принимает решение, уровнем выше другие люди принимают новые решения, и так далее.
На нижних уровнях иерархии находятся сотрудники, чьё проклятие заключается в следовании всем принятым решениям. Какова их задача? Производить, словно рабочие на сборочном конвейере автозавода. Им не нужно думать, они должны делать машины.
Плохие новости: являясь разработчиком, вы будете на дне иерархии.
Если кто-то наверху принимает решения относительно функций приложения, и у вас практически нет возможностей повлиять на процесс принятия решений, тогда добро пожаловать в водопад! К сожалению, чаще всего высшее руководство не видит, что в мире разработки ПО не существует фазы производства. Разработчики занимаются проектированием системы, а эта задача далека от конвейерной сборки кабины.
Почему? Потому что, в отличие от автомобиля, приложения постоянно меняются! Вам нужно корректно проектировать их, чтобы они работали, отвечали потребностям пользователей, чтобы приложения имели приемлемую производительность, чтобы они были масштабируемы и были устойчивы к изменениям, при этом сохраняя энтропию на низком уровне. Для этого вам нужно принимать много решений о том, как отражать бизнес-знания в вашем коде.
Если вы не влияете на сложность, которая спускается вам руководством, то придётся потратить много сил на управление ей в коде. Это будет считаться «необходимой» сложностью: той, которой нельзя избежать.
Возможный результат? Уровень энтропии может расти очень, очень быстро.
Возможное решение
В компании необходимо как можно активнее практиковать совместное принятие решений и ответственность.
Если вы узнали в описанной мной водопадной модели свою компанию, то вам нужно поговорить с теми, кто принимает решения:
Учитывая всё это, если вы чувствуете, что бизнес-решения добавляют слишком много сложности в ваше приложение, и что вы ничего не можете с этим сделать, даже попытавшись, то советую найти другую работу. Это изматывает — изо дня в день работать с высокой энтропией, а делать раздутый продукт удовольствия мало… или использовать его. Это может дать вам подсказку относительно успеха, который ожидает ваш продукт.
И последнее: то, что может выглядеть сложным на уровне бизнеса, можно упростить, если вы хорошо знаете бизнес-процессы. Это крайне важно. Поэтому узнавайте больше о деятельности своей компании, что здесь делают и что не делают, это поможет упростить фичи и кодовую базу.
По мере выражения своего архитектуры мы что-то объясняем компьютеру. А для этого нам нужно хорошо понимать то, что мы объясняем.
Качество кода и технический долг
Проблема
Помимо «необходимой» сложности, привносимой бизнесом, энтропия в ПО тесно связана с качеством кода и техническим долгом.
Что такое технический долг? Попросту говоря, это упрощения (хаки), которые вы используете для экономии времени, зная, что позднее вам это может аукнуться. Особенно в тех случаях, если от этих хаков зависят другие фичи: вам придётся это исправлять с процентами, как и при настоящем долге, в виде сложностей и головной боли.
В зависимости от задачи вашего приложения, технический долг может быть более или менее приемлемым. Если программа должна прожить пару месяцев, то можно вообще не думать о техническом долге, энтропии или качестве. Просто соедините куски кода, и готово!
К примеру, это может быть временным решением, прежде чем создавать более сложное приложение с нуля. Или так можно быстро написать прототип, чтобы проиллюстрировать идею, а затем всё переписать или отказаться от концепции.
С другой стороны, обычно компании хотят разрабатывать более долгоживущие приложения. Это разумно: переписывание приложение может стоить очень дорого (особенно, если оно большое), и никто не гарантирует, что его уровень энтропии окажется ниже. Переписывание — занятие очень рискованное.
В подобных случаях вам нужно быть очень осторожными с техническим долгом и качеством кода. Это важная часть вашей работы как разработчика.
В известной книге The Pragmatic Programmer (в которой помимо много другого введён принцип DRY) приведена интересная аналогия технического долга. Здесь описано исследование, в котором сопоставлены разрушения городских зданий с… выбитыми в них окнами. Разбитое окно создаёт впечатление заброшенности, вдохновляя каждого хулигана в округе. В результате здания с разбитыми окнами подвергаются вандализму быстрее, чем здания с целыми окнами.
Технический долг — это упрощение или хак в вашем коде, разбитое окно. Когда другой разработчик, или даже вы сами в будущем, заметит это, то возникнет соблазн добавить ещё больше технического долга, потому что «здесь всё равно есть плохой код, так чего париться?»
Пример: вы написали обход для одного сложного бага, потому что не было времени его выискивать. Другой разработчик (или вы сами позднее) поверх этого обхода может написать другой код, решая другую проблему. Очень быстро нарастут слои обходных решений, в которых никто никогда не разберётся.
Решение
Во-первых, как узнать, что в коде есть технический долг?
Встречая такие паттерны, пожалуйста, не расценивайте их как разрешение добавлять ещё больше технического долга:
Рефакторьте маленькие фрагменты кода за раз и часто прогоняйте тесты, чтобы убедиться, что система ведёт себя как ожидается.
Наконец, в ходе рефакторинга вам могут понадобиться хорошие аргументы:
Нам, людям, трудно даются прогнозы в средне- и долгосрочной перспективе. Поэтому не всегда просто рефакторить или «продавать» нечто с прицелом на неизвестное будущее.
Технический долг отражает дуализм между простым и правильным путями. Первый быстр и привлекателен, второй сделает ваш проект масштабируемым и лёгким в сопровождении. Вам понадобится самодисциплина, чтобы как можно чаще выбирать второй путь. Иначе будущее будет наполнено страданиями.
Если вы слишком устали, раздражены или полны других мыслей или эмоций, снижающих вашу мотивацию, чтобы придерживаться правильного пути, а не простого, то лучше пока не программируйте. Прогуляйтесь, поговорите с коллегами, сделайте перерыв. Вернитесь к коду со свежими мозгами.
Чаще всего технический долг добавляется при отладке. Если вы исправляете баг, добавляя обходное решение, то вы ничего не исправили. Баг остался, просто его труднее запустить и случайно найти. Исправлять баги нужно с помощью рефакторинга, изменения или полного удаления кода. Затем протестируйте код, чтобы удостовериться, что баг не возникнет снова.
Последнее: винить коллег за ошибки непродуктивно. Если будете плохо или саркастично высказываться о своей кодовой базе, это тоже не решит проблем, только ухудшит ситуацию. Не разрушайте командный дух. Вам нужно уменьшать энтропию в проекте, а не разрушать его устно.
Автоматизированные тесты
Проблема
Есть кое-что завораживающее меня в волшебном мире разработки ПО, особенно в стартапах: многие программисты до сих пор не хотят писать автоматизированные тесты.
Почему меня это завораживает? Во всех остальных сферах инжиниринга тестируют то, что делают, следуя строгому процессу. Когда строишь ракету, то необходимо протестировать множество систем, или ракета упадёт. То же самое относится к автомобилям, мостам, самолётам — чему угодно.
Трудно найти руководителей или разработчиков, которые против тестов, но легко найти тех, кто против автоматизированных тестов. Эти люди предпочтут тратить время на ручное тестирование любых изменений, вместо того, чтобы один раз написать тесты.
Я тоже не без греха. Годами я занимался тем же самым.
Надеюсь, все согласны с тем, что компьютинг — это автоматизация для нас людей, которая экономит наше время и повышает нашу эффективность. Так почему бы не автоматизировать и тесты? Да, я считаю это целесообразным. Тестирование, как и рефакторинг, требует времени на написание кода (как и всё остальное), но экономит время, энергию и рассудок в средне- и долгосрочной перспективе.
Вот очень простой индикатор того, что у приложения может быть высокий уровень энтропии: если есть хорошие автоматизированные тесты, то уровень энтропии может быть низким. Если таких тестов нет, уровень энтропии является высоким.
Чем больше проект, тем сильнее будет последнее заявление.
Решение
Если ваши коллеги или лица, принимающие решения, не хотят слышать о тестировании, вам понадобятся сильны аргументы.
Вот конкретный пример. В одном банке из-за недостаточного тестирования было потеряно 1,3 млрд клиентских записей. И вам не нужно быть банком, чтобы иметь баги и терять данные. Достаточно сказать «нет» автоматизированным тестам.
Аргументы против тестов часто связаны со скоростью:
Я говорю, что вам нужно тестировать код, когда это целесообразно. Сэнди Метц хорошо рассказала об этом в своём выступлении.
Также полезно тестировать в ходе исправления багов, чтобы удостовериться, что баги не возникнут снова. Затем можете показать тест всем противникам и сказать, что этого бага могло бы не быть, если бы кто-нибудь с самого начала написал тест.
Если после этих аргументов ваша команда всё ещё не хочет писать тесты, то в причина может быть в том, что они просто не умеют. Вместо того, чтобы ругать их, вы можете:
Тесты — это клей, который позволяет всей системе чётко работать.
Тестирование ведёт к сбоям, а сбои ведут к пониманию.
Делитесь знаниями, чтобы избегать ошибок
Очень важно делиться знаниями с командой:
Как преуспеть в этом начинании?
Совместное программирование
Совместное программирование — это обмен опытом. Кто-то пишет код и показывает другому, как он это делает. А второй указывает на ошибки, даёт советы и подсказки.
Вот и всё! Если разработчики заинтересованы, то получается забавно.
Но, к сожалению, совместное программирование часто считают потерей времени.
Лёха, ваш коллега, выразил распространённое мнение об этом: «Два разраба будут кодить две разные фичи быстрее, чем одну, верно? К тому же тут один разрабатывает, а второй просто смотрит в экран. Потеря времени!».
Вы можете объяснить ему: мы хотим писать качественный код, а не много кода. Код нам не друг, он источник багов. Нам нужно бороться с энтропией, а не как можно быстрее писать код.
Если те, кто принимает решения, вас не поймут, ищите другую работу. Если вы этого не сделаете, то со временем получите пачку устаревших приложений, которые невозможно сопровождать. Добро пожаловать в ад!
Анализ кода
Это ещё один хороший способ делиться своими знаниями. Анализ кода может:
Вы жалуетесь на Коляна, начинающего разраба, потому что он ничего не знает про принцип единственной ответственности. В его коде бардак?
Всегда лучше учить, а не обвинять. Дайте ему хороший совет, подскажите полезные источники информации, поделитесь знанием и энтузиазмом.
Несколько советов по проведению анализа кода:
Делитесь знаниями
Делитесь с коллегами интересными статьями (вроде этой!) в любых мессенджерах и прочих каналах коммуникации.
Важно также экспериментировать с командой. Если вы считаете, что новая технология может решить одну из ваших проблем, проведите совместное программирование и проверьте эти возможности.
Не забудьте, что передача знаний — это забота и повышение эрудиции и опыта команды, в которой вы работаете, и хороший способ писать более качественный и чистый код. Это поможет держать уровень энтропии на минимальном уровне!
Держите Гидру энтропии подальше от своих проектов!
Тем, кто всё ещё думает, что первой причиной энтропии в ПО является лень, я возражу, что она никогда не бывает основной причиной. Почему ваши коллеги ленивы? Потому что кадровики наняли не тех? Или у них слишком силён стресс из-за сжатых сроков? Работа приносит им удовлетворение?
Поговорите с командой. Спросите, нравится ли им работать с вами. Интересуйтесь по-настоящему, какие они люди. Прислушайтесь к тому, что они скажут, к их отзывам, даже если вы не согласны с их мнениями.
Честно говоря, вам понадобится приличная порция эмпатии и открытости, чтобы эффективно работать с людьми. Обвинения и критика ничего никому не дадут. А указывать на лень — это обвинение.
Итак. Что вы для себя вынесли из этой статьи?