Здравствуйте, eao197, Вы писали:
E>Кстати, приведенный мной черновой вариант

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

решения с timer_thread_t оказался не правильным. И я выбросил его не написав ни одной лишней строчки кода. У меня не возникло соблазна взять какую-то часть написанного кода для нового решения (не знаю как у кого, но у меня такой соблазн всегда был слишком велик).
Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая. И вот ты получил лист A4, и сэкономил несколько строк кода.
Я пока еще не достиг нужного уровня просветления, но довольно давно предпочитаю проектировать в терминах кода. Раньше мне это было не очень удобно, потому что я писал на дельфи, а там еще и изменения в интерфейсе не очень хорошо отображались в имплементейшн. Не говоря уже о внешних ссылках.
Сейчас в студии я пишу код не задумываясь. При этом получается у меня быстрее, чем на бумажке:
— когда я описываю интерфейс или делегат, мне вообще не нужно делать лишних нажатий. За меня почти все дописывает автокомплит.
— когдя я меняю сигнатуру, у меня под рукой рефакторинг, который мгновенно согласованно меняет весь солюшн.
Поэтому мне не страшно сделать ошибку. Я не пользуюсь решарпером, т.к. он еще недостаточно стабилен. Но даже встроенный рефакторинг VS2005 позволяет мне думать кодом.
При этом самое милое — в том, что когда я хочу нарисовать картинку, дизайнер диаграмм делает это гораздо быстрее и аккуратнее, чем карандаш и бумага. И, в отличие от бумаги, эти картинки не теряются под столом, а идут в SVN. И они бесплатно сохраняют актуальность, если я что-то поменял в коде!
Я выбрасываю довольно много кода. Зачастую придуманные мной интерфейсы/классы не переживают очередного витка рефакторинга. Но я отношусь к ним так же, как к бумажкам на столе — периодически выкидываю их из SVN.
Получается, что мне проектировать в студии дешевле, чем на бумаге!

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

internal struct LogRecord
{
  Guid Id;
    DateTime TimeStamp;
    |
}

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