Здравствуйте, IT

Данное сообщение не является попыткой покритиковать или опровергнуть что-нибудь в рассказе IT. Как я понимаю, Игорь просто поделился своим опытом. У меня же есть мой опыт, исходя из которого я смотрю на некоторые вещи чуть иначе. Так же я думаю, что мы с IT занимаемся разными задачами, что дает возможность нам использовать разные подходы к разработке.
Этот пост в некоторой степени является ответом и на сообщение VladGalkin

Автор: VladGalkin
Дата: 12.02.06

, о хороших результатах инкрементальной разработки и дискредитировавшей себя модели Waterfall.

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

Степень точности зависит от уровня абстракции. На каком-то уровне нужно точно понять, что необходимо разработать инструмент SObjectizer (или ACE, или Spring, или BLToolkit, конкретное имя ничего не значит). Здесь мы можем более-менее расплывчато представлять себе конкретные возможности нового инструмента, но зато точно должны знать, чем этот инструмент отличается от конкурентов и зачем он нужем нам (либо потенциальным покупателям).

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

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

По моему мнению, здесь нет никакой модели Waterfall. На каждом уровне абстракции я нахожусь ровно столько, сколько нужно чтобы понять, что я точно представляю себе работу этого уровня. И что это знание позволяет мне двигаться дальше. Не на всех уровнях возможно написание кода, но если где-то возможно и это имеет смысл, то я пишу код. Но я предпочитаю пользоваться при проектировании именно бумагой, потому что:
* лично меня отвлекает большое количество мелких деталей общения к компьютером (хотя бы необходимость периодически сохранять изменения в документе);
* на компьютере для меня «хуже обзор», т.к. даже на мониторе с большим разрешением я вижу гораздо меньше деталей, чем на двух сложенных рядом листах формата A4;
* в большинстве случаев процесс поиска точного представления напоминает блуждание в тумане, когда перебираются десятки вариантов. Многие варианты отвергаются и затем принимаются к расмотрению по несколько раз, многократно перекраиваются и возвращаются затем к первоначальному варианту. Лично мне не хочется проделывать лишнюю работу и проделывать все это мышкой в Visio, поскольку на бумаге все это для меня гораздо проще.
Кстати, приведенный мной черновой вариант

Автор: eao197
Дата: 10.02.06

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

И еще один важный момент по поводу проектирования. Неявно подразумевается, что проект все равно будет неоднократно пересматриваться, требования к нему будут изменяться и все равно его придется перекраивать и переделывать. В некоторых предметных областях только так и можно, но не везде. При разработке программного инструментария ситуация несколько иная. Если я разрабатываю объектную СУБД, то глупо, имхо, расчитывать на то, что требования к ней будут меняться раз в месяц. Нет, я сразу должен буду получить приемлимый результат. Более того, должен быть выбран такой API для СУБД, который бы позволил выпустить несколько версий СУБД не нарушая совместимости клиентских приложений. А в разработке СУБД есть области, в которых лично я не представляю себе написания кода без точного понимания того, как он будет работать. Например, механизм записи транзакционных изменений посредством write-ahead log. До написания кода я уже должен четко знать, какая метаинформация информация должна быть в log-е, как по этой информации определять актуальность log-а, как по log-у восстанавливать БД после сбоя, можно ли использовать log для организации on-line репликации и пр. Конечно, точный состав и форма представления метаинформации будет меняться по ходу реализации. Сама реализация может быть итерационной, где некоторые части метаинформации будут игнорироваться на разных итерациях. Еще более вероятно, что перед разработкой будет создано и выброшено несколько прототипов. Но суть в том, что лично я не представляю, как придти к механизму write-ahead log-а начав с программирования подсистемы write-ahead log-а.

И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная. Например, если речь идет о вспомогательных библиотеках. Я думаю, что для программиста, использующего ACE, не так уж много пользы даст код метода ACE_Event_Handler::handle_input или ACE_Reactor::run_reactor_event_loop. А в некоторых случаях кода используемой библиотеки нет вовсе. На первое место в таких условях выходит документация, написанная в комментариях к методам и классам. Но чтобы ее написать, довольно часто нужно представлять себе всю картину в целом. Картину, которая открывается мне после предварительного проектирования на бумаге. Поэтому, когда я приступаю к программированию, я приступаю и к документированию. При этом написание doxygen комментариев к коду является, наверное, более трудоемкой и длительной операций, чем кодирование. Зато на выходе получается еще и довольно объемный и актуальный Reference Manual. Конечно, не иногда он не нужен. Но, поскольку я всегда старался заниматься разработкой инструментария, то практически постоянно мне приходилось делать еще и документацию. И предварительное проектирование на бумаге существенно облегчало этот процесс.