Записки программиста

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

Положения великой колхозной доктрины (она же ВКД, Kolkhoz Doctrine, Kolkhoz Driven Development или просто Учение):

1. Главная цель любого программиста — работающий продукт и счастливые пользователи. Пользователи никогда не должны страдать (во всяком случае, больше обычного). Если, например, вы выкатили фикс, который приводит к страданиям пользователей, не важно по какой причине, откатывайте свой фикс и разбирайтесь с проблемой в отдельной ветке. Глупые пользователи ничего не знают о плохих людях, заюзавших недокументированные возможности вашего прекрасного API и так далее. Прямое следствие данного положения заключается в том, что любое изменение продукта должно делать его не хуже, чем он был до этого. Если выясняется, что продукт стал хуже, откатываем его к предыдущей версии.
2. Помните, что вы в команде не одни. Допустим, вы считаете, что проблему можно решить, просто прикрутив Paxos. Но помимо вас в команде есть еще пять человек и едва ли они вообще хотят знать, что такое этот ваш Paxos. И вряд ли к вам на собеседование каждый день заходят люди, которые хотя бы слышали это слово. Проблема не в ваших коллегах, проблема в вас, ваше решение сможете поддерживать только вы сами. Решение не подходит для вашей команды, найдите другое. Не будьте категоричны, ищите компромиссы, найдите способ разрешения конфликтов, который устроит всех. Например, последнее слово человека, назначенного тимлидом.
3. Только ситхи все возводят в абсолют. Например, запускать в Docker строго один процесс на контейнер, использовать только неизменяемые переменные, или наоборот, практиковать исключительно ООП подход, писать все только в Vim, позиционировать макбуки как идеальные устройства которые «просто работают», говорить, что Java нельзя использовать из-за сборщика мусора, который иногда делает stop the world, или, например, что в Erlang есть remsh и горячее обновление кода, и потому все остальные языки ни на что не годятся — это все еретические учения. Другая трактовка заключается в том, что следует избегать категорических заявлений типа «совершенно очевидно, что во всем виновата база данных (язык программирования), давайте смигрируем все на MongoDB (перепишем на Haskell)». Технологии редко оказываются настоящей причиной проблем, на самом деле почти всегда виноваты люди. Внимательно анализируйте каждую конкретную ситуацию отдельно и выбирайте подходящий инструмент, используя строгие критерии, а не свои фантазии о том, что есть правильно.
4. Боритесь с перфекционизмом. Говнокод — это нормально. Над проектом долго работало сильно больше одного программиста. Требования, а следовательно и код, постоянно менялись. Было бы странно не получить местами говнокод. Работает — не трожь! Также не докапывайтесь слишком сильно до чужих pull requests. Возможно, вы бы назвали переменные немного иначе, лучше расставили бы отступы, и написали бы чуть более быстрый код. Но едва ли все это сильно повлияет на счастье пользователей. А потому не следует тратить время впустую на споры о подобных вещах.
5. Не изобретайте велосипедов. Вряд ли вы столкнулись с чем-то таким особенным, что до вас никто никогда не пытался решить и не выложил в опенсорс. Или не предоставляет недорого в виде SaaS, как это делает, например, Datadog. Если вы не знаете, как решить задачу, не бойтесь спросить у более опытных коллег. Наверняка где-то уже есть известное решение. Не следует сломя голову бросаться писать свой ORM или свою распределенную БД. Берите готовое или постарайтесь понять, почему никто так не делает.
6. Проверяйте все самостоятельно. Не ведитесь на маркетинговый булшит, ставьте под сомнение мнение «экспертов», игнорируйте слухи типа «мой друг использовал DynamoDB и потерял все данные» и микробенчмарки годовалой давности, на малых объемах данных или которые нельзя повторить. Если в WhatsApp используется Erlang, это не значит, что с его помощью вы автоматически построите крутую распределенную и отказоустойчивую систему. Riak в первую очередь является key-value базой данных. Если Basho в довесок обещает вам MapReduce, полнотестовый поиск, и хрен знает что еще, совсем не факт, что они в Riak очень хорошо работают. Загрузите в PostgreSQL ваши объемы ваших данных на вашем железе и проверьте, сколько ваших транзакций в секунду он реально держит с тюнингом тех настроек, которые вы смогли осилить. Поднимите свой Cassandra кластер хотя бы с помощью Vagrant и проверьте, как он ведет себя при падении узлов и нетсплитах, теряются ли при этом данные и так далее.
7. Используйте самые простые и проверенные временем решения. Все эти свистелки и перделки типа чистого ФП, теории категорий, зависимых типов, доказательства корректности программ и так далее, скорее всего, вам не нужны. Потому что, угадайте что, пользователям все равно, сколько монад вы использовали в проекте и сколько теорем вы в процессе доказали. Потратьте лучше время на написание дополнительных интеграционных и нагрузочных тестов, простых и проверенных временем. Если почти все высоконагруженные и не очень веб-проекты успешно строятся на базе РСУБД типа MySQL или PostgreSQL со своими скриптами для решардинга и прочими костылями, то незачем вам тащить в проект MongoDB. Скорее всего, только кучу граблей соберете.
8. Оставайтесь консервативны, но не бойтесь изучать при этом новые подходы и инструменты. Возможно, Git и вправду намного лучше Subversion, а программируя на Scala вместо Java вы станете заметно более продуктивны. Да и в этих ваших новомодных микросервисах с DevOps что-то есть. Главное, поймите для себя, какую конкретно проблему вы хотите решить при помощи этой новизны, и двигайтесь осторожно.
9. Написание кода — это не все. Многие задачи можно решить вообще не техническим образом. Например, если приложение уперлось в память, можно просто докупить оперативной памяти, а не заниматься долгой и дорогостоящей оптимизацией. Бизнесу зачастую не нужны девять девяток, и намного проще донести это до начальства, чем бросаться реализовывать девять девяток. Еще одна трактовка заключается в том, что программистам следует уметь отдыхать, избегать переработок. Разумеется, если только не страдают пользователи, так как смотри первое положение доктрины. Если начальство внезапно требует от программистов переработок, потому что «хехей, мы же команда, компания рассчитывает на вас», значит вас либо тупо разводят, либо кто-то в компании не умеет планировать. Так или иначе, от уставшего программиста мало толку, и любые переработки создают только иллюзию более быстрой разработки.
10. Колхозная доктрина прекрасна и вечна. Это единственная правильная доктрина и все команды рано или поздно приходят к ней в результате естественного отбора. Поэтому нет особого смысла ее кому-то сильно навязывать. Но иногда в команду приходят особо ярые еретики и их, конечно, следует как можно скорее отлучать от программирования. В этой компании.

Главное, что нужно помнить. Колхозная доктрина — не о том, как сделать тяп-ляп, она о том, как сделать максимально просто и понятно. Чтобы работоспособность решения была очевидна безо всяких там хитроумных доказательств. Чтобы любой толковый программист понял, что и как работает, после пяти минут объяснения в худшем случае. Еще она об объективности, а не действиям наугад, согласно веяниям моды или исходя из своих фантазий об идеальном мире. И самое главное, она о прагматизме, создании рабочих приложений для решения конкретных задач в разумные сроки и за разумные деньги, пусть эти решения и не будут красивыми с точки зрения математики. Потому что красивые решения никому не нужны, если они не работают в нашем с вами, реальном, мире.

А на чьей вы стороне — ордена или те-еретиков?

Дополнение: Этот пост был переведен на английский язык: The Great Doctrine or 10 simple rules that any developer should follow.

Метки: Разработка, Философия.