В программировании (как и в написании HDL кода и подобных профессиях) есть две школы мысли: чистолисты (строят свою архитектуру с чистого листа и пишут так чтобы поменьше отлаживать) и кодокопатели (отлаживают что есть, дополняя мусором из интернета, чтобы поменьше писать). На это накладывается менеджмент, который пытается комбинировать чистолистов и кодокопателей, иногда неправильным образом, то есть ставит чистолистов править то, что налабали кодокопатели. Это происходит потому, что кодокопатели постоянно выглядят занятыми отладкой, а чистолист часто смотрит в потолок обдумывая дизайн, поэтому менеджмент думает что первые работают быстрее чем вторые, и пытаются соптимизировать “быстроту-качество” вот таким образом.
Программист-чистолист пишет весь продукт или крупный компонент с чистого листа, полностью контролирует его архитектуру и знает все побочные эффекты подкомпонент. При работе в команде чистолист является диктатором джунов - они должны вписаться в его структуры и следовать его стилю. При работе с равными чистолистами происходит явное обозначение территорий, формулируется четко изолирующий API, как с внешними библиотечными модулями. Если возникает баг, после триажа определяется чья это территория, после чего правка является обязанностью чистолиста-владельца. При таком подходе много времени уходит на обдумывания и переписывания, но не на отладку - ее чистолисты не любят и стараются избегать как можно.
У этой школы мысли есть большой плюс: если что-то сделано, то оно как правило работает. И три минуса:
И продукт, и подкомпоненты многократно переписываются прежде чем достигнута прочная и при этом гибкая структура. Это нервирует менеджмент.
Конфликты с джунами, которые не понимают придирок. Вплоть до обвинений в харазменте с наемом индустриального психолога для разруливания ситуации.
Вся структура может не выдержать новой крупной фичи. После чего у чистолиста встает дилемма: все переписывать или бежать. Менеджмент требует скрестить ежа с ужом, для юного чистолиста это предательство идеалов, и даже для опытного - некомфортная операция, от которой он будет пытаться отлынивать частичными решениями или обманом менеджмента.
В другой школе мысли, назовем ее “кодокопатели”, проект начинается с того, что программист лихорадочно гуглит и сваливает у себя кучу кода со всяких свалок, из которого пытается что-то склеить, после чего это склееное отлаживает. Собственно именно отладка является у кодокопателей главной деятельностью - смотреть на чистый лист и на нем что-то писать они очень не любят и пытаются избегать любыми способами.
На одной из предыдущих работ был товарищ, назовем его Вася, который сначала работал как application engineer в маркетинге Raspberry Pi, а потом был поставлен делать образовательный проект с процессором на FPGA плате. Он очень боялся прикасаться к коду. Для него написать страницу кода для реализации valid-ready AXI каналов было страшнее, чем нагуглить на opencores два студенческих моста двадцатилетней давности и слепить кентавра из Wishbone и AHB-Lite, только чтобы не писать самому.
Продукт не был особо принят на рынке, потому что у всех кто это видел сразу вставал вопрос “на фига тут многослойное это, тем более что в индустрии все делается проще и работает эффективнее”. Предсказуемо, что этот человек потом стал основателем no-code стартапа, а теперь гоняет на AI. Теперь вы понимаете, откуда такие люди берутся.
Как я уже сказал, бывает некомпетентный менеджмент, который принимает лихорадочное гугление и слепление за быстроту и дает склейщику кодокопателю карт-бланш что-то наваять, а потом ставит чистолиста это чистить. Это вызывает реакцию “тут надо все переписать”, что в свою очередь бесит менеджмент, который думает, что надо только внести пару правок перед отправкой заказчику.
Реально кодокопательские проекты обычно увязают в отладке и прогресс становится черепашьим, после чего продукт умирает.
У меня был ровно такой случай в середине 2000-х. Чтобы вы поняли масштаб проблемы, скажу что в налабанном коде товарищ, назовем его Петей, использовал трехмерные массивы там где нужно было использовать дерево, и их в разных местах кода тройным циклом обходил. Когда этот товарищ уходил из компании, он спросил меня советов о будущем. Я открыл рот и начал намекать что ему нужно научиться программировать, но он меня перебил, и пояснил свою мысль: он решил что программирование для него слишком просто, поэтому он хочет стать основателем стартапа. И, так как я был основателем сфинансированного венчурными капиталистами стартапа в 1990-х, он хотел совет именно по этой линии.
Тут мне даже не нужно писать, что нынешняя ИИ-движуха - это именно тот триумф той части менеджмента, которая 70 лет ждала момента, когда они могут превратить всех в готовых отлаживать после ИИ кодокопателей, при этом с зорким глазом чистолистов. Ну что-ж, будем ждать первого падения какого-нибудь Боинга или Аирбаса, который поставит под сомнение этот подход.
Комментарии (17)
wladislawmsk
29.04.2026 17:37Исключительно плохие примеры любителей отладки выставляют тут их (нас) в плохом свете и, на мой взгляд, несправедливо.
Полагаю, у всех когда-то был коллега, кто мог отправить в продакшн довольно большой кусок кода, ни разу его не запустив. Это был бы пример некомпетентного чистолиста.
Я сам предпочитаю как можно скорее запустить приложение, чтобы начать отлаживать. Пусть даже оно полностью состоит из заглушек, но главное, что все, что я пишу после того, как оно запущено - я могу потрогать, проверить любое предположение, поиграться со структурой данных и отладить, если что-то пошло не так. В целом в руках подержать то, что пока получается. При этом я редко использую готовый код и предпочитаю обходиться минимальным набором инструментов, когда возможно, а архитектура решений, которые получаются в итоге ничем (я надеюсь) не выдает того, что я не чистолист. Просто подход в том, чтобы думать и делать чередуя, а не разделяя эти процессы.
YuriPanchul Автор
29.04.2026 17:37Я тоже стемлюсь запустить быстрее, но делаю для этого законченную версию с подмножеством фич. А потом иду на другой круг спирали, и делаю версию с большим количеством фич. Стараюсь избегать заглушек и копипасты того что не планирую иметь в будущем.
Я собственно не против людей которые предпочитают отлаживать, а не писать. Я против постановки таких тандемов, где те, кто склонен к отладке и имеют ограниченный опыт, ставится определять архитектуру, а люди с опытом в определении архитектуры - ставятся чтобы это очищать, особенно если он не любит процесс отладки вообще и отлаживать сделанный наспех чужой код в частности.
apevzner
29.04.2026 17:37Тут намечается классификация разработчиков по ещё одному признаку
Одни способны придумать архитектуру из головы, а потом описать её в коде. Ну, по крайней мере, они говорят, что так могут. Живьём я такого не видел (чтобы архитектура при этом получилась удачная), но стандартные практики менеджмента считают такой сценарий развития желательным
Другим надо потрогать вещи руками, чтобы мысли стали на место. А без этого как-то не получается.
Часто выход для этих вторых в написании прототипов перед написанием настоящих реализаций.
Я тоже вру иногда, что делаю прототип, чтобы от меня отвязались. Но почему-то в конечном итоге прототип и становится финальной реализацией :)
D_T
29.04.2026 17:37Пришел я в начале 2000х на проект, где было заявлено что MySQL так крут что индексы не нужны, студенты писали, проект в продакшене заметно тупил, изучил запросы, добавил индексы и все залетало. Кто я был тогда? чистолист или кодокопатель?
YuriPanchul Автор
29.04.2026 17:37Вы переосмыслитель-рационализатор, это отдельная роль. Я такое вчера сделал на работе, показал как некий процесс (синтез проекта на Synopsys Fusion Compiler) можно реорганизовать, чтобы он для решения проблемы разработчика (меня) занимал 15 минут, а не 4 дня на итерацию.
devmargooo
29.04.2026 17:37Ахах, узнала в себе образцового чистолиста :D пока мои друзья обсуждают новый фреймворк, на котором «легче и быстрее» писать, я хвастаюсь за голову, понимая, сколько там будет дебага с такими призрачными ограничениями
serp2002
29.04.2026 17:37К счастью авиация очень консервативная отрасль, до сих пор NOTAM через сеть AFTN передаются, то есть по факту через телеграф. А вы говорите ИИ ))
Yura_PST
29.04.2026 17:37Изучил задачу;
Написал реализацию;
Исправил опечатки;
Работает!
Использую дебагер эпизодически, обычно для поиска segmentation fault или посмотреть стэк вызова, вообще не понимаю как можно более сложные ошибки найти с помощью дебагера.
apevzner
29.04.2026 17:37И продукт, и подкомпоненты многократно переписываются прежде чем достигнута прочная и при этом гибкая структура. Это нервирует менеджмент.
Я - явный чистолист, но в целом обхожусь постоянным вялотекущим рефакторингом вместо многократного переписывания. В остальном всё сходится.
Отладчиком иногда пользуюсь в качестве калькулятора :)
codecity
29.04.2026 17:37Вот классификация - в точку. Именно так все и происходит в реальной жизни. Но термины такие "чистолисты" и "кодокопатели" (хотя они и передают суть - претензий нет) - ранее не встречались.
mvv-rus
29.04.2026 17:37У меня по жизни сложилось впечатление, что написание своих программ и понимание чужих программ (оно же - программная археология) - это два разных навыка. А объединяет их только необходимость понимания, как работают программы: вообще или на конкретном языке, и приемов программирования. А дальше для написания собственных программ требуется умение творить: создавать абстракции и делать из них архитектурные решения, а для чтения чужих - умение понимать: реконструировать ход мысли другого человека, выделять используемые им абстракции и прояснять для себя созданные на их основе архитектурные решения. IMHO эторазные умения, хотя и некоторым образом связанные: например, знание типовых приемов программирования помогает в обоих случаях.
eao197
29.04.2026 17:37Чтобы вы поняли масштаб проблемы, скажу что в налабанном коде товарищ, назовем его Петей, использовал трехмерные массивы там где нужно было использовать дерево, и их в разных местах кода тройным циклом обходил.
Конкретно в этой истории самым интересным является то, как Петя прошел испытательный срок и как ему позволяли творить такую дичь в коде.
vkni
@YuriPanchul
Спасибо, интересная тема.
Предпоследний абзац повторяется дважды, дважды.
Вообще, есть т.н. «спиральный подход» для «чистолистов», когда прототип выбрасывается нафиг. А для того, чтобы это не бесило, и проще было делать прототипы, есть языке с развитой системой типов — Хаскель, к примеру.
И там прототип делается на типах — которые можно рассматривать как очень маленькую дублирующую приблизительную реализацию. Соответственно, когда мы пишем прототип только на типах, оставляя кругом undefined, мы пишем мало, это легко выбрасывать и переписывать. А потом дырки undefined уже можно заполнять.
YuriPanchul Автор
Дважды поправил, спасибо.
Да, у меня тоже спиральный подход, я даже думал это упомянуть, но решил не перегружать заметку. Но в моей спирали с сразу пишу небольшой код с ограниченной но законченной функциональностью, а потом пишу следующий вариант больше, на основе первого опыте. Это мне легче, чем сначала слепить кучу из вторсырья.
vkni
Ну да. Вообще для разных подсистем можно писать каскад прототипов.
Но вот языки с разработанной системой типов позволяют при должном умении писать "приблизительные программы". То есть, вместо детальной реализации алгоритма, вы пишете из каких типов в какие он работает. И если в мелочах вы более-менее правы, то всю систему целиком проверит компилятор. Таким образом, можно делать "наброски".
mvv-rus
Но вот языки с разработанной системой типов позволяют при должном умении писать “приблизительные программы”.
ООП-языки тоже позволяют при должном умении разрабатывать программы сначала начерно, с заглушками на месте функциональности, а потом переписывать набело, с функциональностью. Но умение тут нужно уже другое.
apevzner
Я, обычно, свой код как деревце выращиваю
Сначала появляется базовая реализация чего-то. Потом она постепенно расширяется слоями. Стараюсь придерживаться простой архитектуры, не овердизайнить раньше времени. Если в текущей архитектуре становится тесновато, ну, значит, настало времени её порефакторить
Иногда рефактиринг сводится к тому, чтобы по-другому посмотреть на имеющиеся вещи. В таком случае, изменения в коде минимальны, но могут быть переписаны комментарии или переименованы какие-нибудь штуки - обозначая пересмотренное направление развития, в которое то, что уже есть, более-менее аккуратно укладывается, как частный случай