О допустимой сложности

[metaclass]

Очередной раз уткнулся на работе в безумие.
Безумие заключается в том, что теоретически правильные методики работы приводят к разрастанию непонятного кода.
Теоретическая правильность заключается в DRY. Т.е. куски кода и данных, являющиеся отражением одних и тех же сущностей или потоков данных предметной области выносятся в отдельные модули, обобщаются, делаются универсальными и прочее.
Причем тут именно что не натягивание совы на глобус, когда "похожие" функции и данные насильственно обобщаются, а только те, где написание двух раздельных заведомо приведет к необходимости синхронной правки двух и более разных мест кода.

А возникающая непонятность - это то, что в результате один конечный результат работы зависит от десятков модулей, в каждом из которых функции высшего порядка посылают другие функции третим функциям, возвращающим функции, которые обрабатывают списки функций.
Это условно говоря, на практике там ничего сложнее "передать функцию-конвертор и параметры в обобщенную функцию и получить результат" нету. В паре мест есть reduce внутри reduce для сложной группировки, все это занимает 10-20 строк кода и спокойно целиком вмещается на экран.
Подобные вещи для меня являются достаточно простыми и самоочевидными. Даже в чужом коде (нормально написанном) понятно, как с таким работать: открываешь самую верхнюю функцию и начинаешь от нее идти по дереву вызовов, постепенно отсекая неинтересные ветки, пока не доберешься до нужной. Это даже в крестиках-жабах-дотнетах-питонах просто, а в функциональных языках с их лаконичностью и того проще.

А проблема в том, что потом это нужно объяснить коллегам. И тут начинается какая-то знатная хрень, потому что я объяснить не могу.
Для меня очевидно, что map/filter/reduce - это как 2+2, обработка последовательностей, на которой вообще вся эта функциональщина стоит, и что структура данных определяет вызываемые для нее функции и что общие функции и данные нужно выносить в отдельные модули, а не писать каждый раз заново одно и тоже. Но процесс раскладывания в уме ТЗ на эти базовые блоки и обратной сборки конечного результата из блоков - объяснению не поддается.
Писать же код в "понятном стиле", в том смысле, чтобы минимизировать сложность за счет написания в лоб, без зависимостей, не выделять отдельные функции для удобства чтения - это, по моему, какой-то совсем уже бред.

Comments

[falcrum.livejournal.com]

Если ты не можешь объяснить коллегам свой код - для твоего начальства это повод биться в истерике: завтра ты свалишь, и останется непонятное вуду.

[guamoka.livejournal.com]

А проблема в том, что потом это нужно объяснить коллегам. И тут начинается какая-то знатная хрень, потому что я объяснить не могу.

Вообще, имхо, даже безотносительно к фп, у народа явные заструднения с пониманием того, что структура рождается из функционального предназначения. Что при любой парадигме пограммирования сначала идет FA, a уже потом всяческие SA. Говоришь вроде самоочивидные вещи, а на тебя непонимающими глазенками хлопают и опяь за старое, а что если сделать так, а можно сделать так. Да, так а что вы делать-то собрались? Для чего это предназначено, какие функции выполнять будет? А в ответ- хлоп-хлоп.

[vit-r.livejournal.com]

Если объяснять сложно, то абстракции слишком искусственны или слишком низкого уровня. Или имена надо было давать другие

[blackyblack.livejournal.com]

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

[osdm.livejournal.com]

Вам всего-навсего нужно сменить работу на такое место, где коллеги будут вашего уровня и смогут сами разобраться в том, что вы там понаваяли.

[veremeenko-alex.livejournal.com]

Нанимать уже надо 2-3 программистов, чтобы они работали с твоим кодом, вникали в него, вникали в прктики и идеи, делились знаниями с друг другом.

Твоя программа набрала уже такую сложность что для ее дальнейшего функционирования нужно уже создавать сообщество.

[berezovsky.livejournal.com]

самоубийцы

[alexandr0.livejournal.com]

Пора заменить коллег.

[besm6.livejournal.com]

На первом курсе я услышал от своего лектора фразу "Понятие группы естественно, как дыхание". Осознал я ее лет через 6, и полагаю, что вследствие этой естественности он и сам не мог объяснить это понятие нам, которым оно еще не было так естественно. То есть нас можно было научить формально с ним оперировать, а чувствовать, что тут вот будет вот такое (не вполне тривиальное) поведение, потому что вот это вот - группа, мы еще очень долго не могли.

[juan-gandhi.livejournal.com]

Я бы dry перевёл в более душевную форму. Нужно вводить абстракции, и действовать на максимально абстрактном уровне.

И коллег подбирать способных к абстракции.

И это относится не только к сведению всего к тензорному произведению моноидов, а просто к осознанию сути вещей, прежде чем кодировать байтики.

[smalgin.livejournal.com]

Ну поддается же процесс дизайна SQL DB какому-то объяснению. Можно framework и для определения блоков набросать как-то.

Если же объяснять map/filter/reduce людям безграмотным, то я бы, пожалуй, только через linq смог бы :)

Такое чувство, что им нужен ликбез, но фирма ликбез не спонсирует, если я правильно понял.

[victor bolshakov (from livejournal.com)]

Мне вот интересно, много ли людей осознают модель данных, с которыми они работают, глубже чем "это перемножить с этим а результаты просуммировать"?

[thinker8086.livejournal.com]

>> Для меня очевидно, что map/filter/reduce - это как 2+2, обработка последовательностей, на которой вообще вся эта функциональщина стоит

А вот это кстати хитрый момент, 100% согласен, что на этом функциональщина стоит, но сам так думать не умею. Более высокий уровень абстракции, так думать ещё научить надо.

В идеале - ещё в универе на модельных задачах, но тут Вы понимаете...

UPD: Это я всё к тому, что дело не в допустимой сложности (который для меня, скажем, связан с количеством объектов, которыми надо одновременно оперировать), а в допустимом для индивида уровне абстракции.

[os80.livejournal.com]

По-моему, в таких случаях помогает написать статью "для внутреннего пользования".