Тяжела и неказиста...

[recoder]

Всё-таки удивительная штука - жизнь практикующего программиста.

Вот бывает, проектируешь что-нибудь, ну например систему "автомобиль". Напрягаешь свою стареющую память, вспоминаешь все похожие задачи, пишешь так чтобы в случае чего, не напрягаясь, расширять систему по ходу добавления требований. Рассчитываешь чтобы можно было легко наращивать грузоподъёмность. Чтобы можно было подменить стандартный двигатель на аэротурбину или десять мопедных моторчиков. Чтобы количество колёсных пар можно было неограничено увеличивать. Чтобы водители на ходу могли меняться. Чтобы любой прицеп можно было прикрутить и сзади, и сверху, и с любого бока. И чтобы могла ездить и вперёд и назад не теряя ходовых качеств (ведь бывали и такие случаи в практике). И думаешь, что теперь предусмотрел всё и дальше будешь, поплёвывая в потолок, спокойно развивать систему.

А потом внезапно приходят новые требования, в которых пишут "А ещё надо чтобы сверху были вращающиеся рога с воздушными шариками!"

Comments

[mpak666.livejournal.com]

В общем-то излишнее проектирование тлен!

Очень хороший манифест по ряду вещей - http://programming-motherfucker.com/

[recoder]

Сложно спорить. А какие альтернативы?

Манифесту - зачёт (хотя я конечно too old for this extremist shit).

[mpak666.livejournal.com]

Альтернатив мне кажется нету, любой большой проект превращается в словнов, подпорки и десяток хоботов для ученых. Писать, рефакторить.... это же работа, нам за нее и платят!

[recoder]

Intelligence is the ability to avoid doing work, yet getting the work done.
- Linus Torvalds

[zubian.livejournal.com]

как это знакомо :))))

[plumqqz.livejournal.com]

Воот. Всего не предусмотришь.

[recoder]

Но это же не повод заниматься экспресс-говнокодингом?

[plumqqz.livejournal.com]

Это повод писать максимально просто.

[russuv.livejournal.com]

ох тяжела!! и не говори!

[bamsic.livejournal.com]

Да, очень трудно объяснить заказчику, почему "вот это крохотное" изменение требует таких затрат...

[larubin.livejournal.com]

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

Но вообще по топику - исходно выполнен громадный overengineering

[recoder]

Ну почти так. Но не так. Дело-то в том, что разработка зачастую начинается на раннем этапе, когда ещё не совсем понятно что же должно быть в результате ("наверное что-то похожее на автомобиль"). И поэтому дизайн системы идёт исходя не из чётких требований с клиентской стороны (даже если клиент - соседняя команда), а из общих размышлений и житейского опыта. А то что ты тут называешь "overengineering" - это просто желание предугадать направления развития и смягчить себе удар от изменения требований. Часто это срабатывает, но иногда бывает как в посте...

[recoder]

А, кстати, какие вообще есть альтернативы ситуациям "Жарьте рыбу, а рыба будет!"? Кроме "См. рисунок #1".

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

[larubin.livejournal.com]

> Пока что вышеописаный процесс - лучшее что у меня получалось.

Я не спорю, что процесс работающий, self-satisfying и вообще кому-то right way to do.

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

[recoder]

Amen, bro!

Увы, я мало видел *-менеджеров, готовых сказать "Ништяк! Прототип рулит. А теперь мы всё выбрасываем и переписываем набело". Обычно бывает по-другому, и постаревшему мне уже сложно их винить...

[recoder]

Коллега недавно порадовал байкой:

— Прошло уже две недели разработки — покажите что-нибудь.
— Смотрите: вот архитектура, вот документация, вот тесты, вот прототип.
— Вы что же, за две недели НИЧЕГО НЕ СДЕЛАЛИ?

[bamsic.livejournal.com]

Да, и такое тоже часто бывает.

[larubin.livejournal.com]

> вот прототип

Не, в этом месте "ничего не сделали" уже не катит

[resiner.livejournal.com]

Как человек, который просит время от времени приделать рога к автомобилю, хочу спросить - при чем тут автомобиль? Делали нечто четырехколесное, потом приделали к нему рога, стало рогомобиль, мы его и делали. Автомобиль был в голове работника, а на самом деле делали рогомобиль.
Случается так, подходишь к сотруднику и говоришь в неясных образах, смысл которых сводится к задаче клиента, а точнее говоря, чтобы тому было хорошо. Начинаешь объяснять то, что и сам не понимаешь, работник нервничает, говорит, типа, отстань от меня, я могу складывать и умножать, неясные образы мне чужды, они не ложатся ни в фон неймана архитектуру, ни в нейроподобный мозгх. В конце концов, чтобы от него отстали он решает делать автомобиль, а там будь что будет. Будь, что будет наступает в конце, в виде рогов, когда переделывать уже поздно.

[recoder]

Тут дело-то в том, что формальный сотрудник-исполнитель не может привнести полезной информации, он просто не располагает ею. Поэтому результат не может быть точнее чем исходное задание. И если было дано задание "хочу четырёхколёсную херню" - то в базовом случае и получишь четырёхколёсную херню, к примеру четыре колеса скрученые проволокой в стопку.

И получается, что очень важно насколько исполнитель является аналитиком в предметной области или насколько он опытен вообще. Первый попытается понять логику и назначение поставленной задачи и может угадать недосказанное в задании, но может и не угадать. А второй - начнёт строить общие решения, типа колёсной базы для чего угодно, что позволит в будущем менять направление развития, но ценой первичной разработки и последующей эффективности.

Увы, программирование - это не просто.