Все стремится к энтропии

В каком-то источнике, я однажды прочитал, что в должностной инструкции Senior+ инженеров в Google указано, что часть их работы это “уменьшать хаос”. Сейчас, когда мне пришла идея этого поста, то я уже не смог найти источник, но это во мне срезонировало и я часто об этом думаю.

Мы разрабатываем информационные системы, это не только микросервисы или приложения, это еще и тесты, процессы, люди, железо. Весь этот механизм как-то пыхтит, скрипит, но работает. Но если его не трогать, то он точно когда-нибудь развалиться 🧨.

Существует даже физический закон “Закон неубывания энтропии” (беспорядка) — в изолированной системе энтропия не уменьшается. Информационную систему с внешними зависимостями сложно назвать стабильной. Поэтому, если перенести этот физический закон в наш абстрактный IT мир, то можно сделать вывод — если жизнь в нашей системе не поддерживать, то она точно сломается.

Проблема в том, что нельзя точно расписать все процессы, которые поддерживают в системе жизнь. Можно постараться, но все расписать точно нельзя. Если представить, что на каждое действие должен быть таск, то можно умереть ☠️ в бюрократии.

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

Примеры:
1. Заметил(а), что в README.md что-то уже не актуально? — удали
2. Заметил(а), что не хватает какой-то документации — добавь
3. Какой-то процесс не задокументирован? — напиши документацию
4. В Slack вашу команду о чем-то спросили? — ответь
5. Кто-то болел и потерял контекст? — созвонитесь и расскажите ему что произошло

Есть идиома "это последняя соломинка, которая сломает спину верблюду”. Одна из задач Хорошего разработчика это убирать эти соломинки, тогда спина нашего верблюда никогда не сломается.

Какие еще примеры приходят вам в голову?

#истории