vit_r

Продолжаю сеанс терапевтической графомании, немного изменив модель поста про жестокость реального мира.

В принципе, это просто заметки на память. Делать что-то понятно и серьёзно долго и смысла не имеет.

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

Естественно, я не написал. Первым делом, жаль времени и сил. Во-вторых это никому не нужно. Макимально я получу пару комментариев «О да! Ты совершенно прав.»

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

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

Большинство задач для программистов чётко заданы и, как правило, уже имеют простое решение. (Вроде таблицы в Екселе, пузырьковой сортировки или процесса, выполняемого руками.) Простое решение по каким-то причинам не удовлетворяет людей с деньгами или свободным временем, и ресурсы бросаются на то, чтобы сделать это быстрее, красивее, компактнее, «как у Гугла» или просто заняться рефакторингом из любви к красивому слову и самому процессу. (Корень «фак» тут явно ссылается на онанизм.)

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

Перевод техзадания в код может быть трудоёмким и сложным, но кроме граблей и оставленных предыдущими поколениями гадостей там ничего интересного не найдёшь. А вот с движением в неизвестном направлении всё гораздо интереснее. Те, кто читал Вайнберга, могут вспомнить замечательный пример с картой и вертолётом. Впрочем, вполне подходит и ёжик из заголовка.

Это не agile. Точнее, не проповедуемый сейчас на всех углах agile первого уровня, который банально перекладывают ответственность на клиента, который обязан говорить, что нужно делать, как и с каким приоритетом. То есть, клиент решает задачу, программисты переводят решение на язык компьютеров, только клиент вдобавок ещё и платит за все косяки, глупости и ошибки. Причём не только свои, но и программистские.

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

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

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

То, чем я занимаюсь, напоминает и exploratory programming, но им не является. Потому как цель не просто выяснить, «как оно работает на самом деле», а понять, что и зачем нужно делать. Исследуется не решение задачи, а её формулировка. С кодом в руках, с кучей тестов и реальных примеров. Желательно ещё и с конечным пользователем под боком.

Это не prototyping. Потому что в нормальных условиях первый прототип выбрасывается. Я же могу менять 150% кода, но не сразу и не с нуля.

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

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

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

Продолжение следует.

Copyright

(CC BY-NC-ND 3.0) vit_r, 2012

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Перевод на английский запрещён, потому как нефиг портить хорошую вещь.