В ранней юности, начиная более-менее всерьез программировать, писал исключительно "из головы". Если был доступ к машине, то сразу начинал колотить код, если не было — писал на бумаге, потом наколачивал. Разумеется, регулярно вылезали непредусмотренные проблемы (несовместимость, особые случаи, сложности с расширением и т.п.). Иногда приходилось по нескольку раз переписывать изрядную часть кода.
Позже несколько раз пытался, как взрослые, начинать с проектирования. Помогало очень слабо. Общая структура программы, иерархия модулей/классов, их взаимодействие в целом неплохо видны и умозрительно. Если все это оформить в виде схемы или описания на псевдоязыке — выглядит логично и красиво, пока не начинаешь наполнять все это кодом. Почти всегда вылезают те же самые несовместимости, особые случаи, взаимные блокировки параллельных потоков, потеря полезной информации в недрах вложенных вызовов и т.п. Полученное так же приходится изрядно переписывать, плюс добавляется время на само проектирование.
Еще с возрастом усиливается склонность к прокрастинации. Если раньше, когда не было интернета (сперва — никакого, потом — богатого информацией), многое приходилось придумывать самостоятельно и делать с нуля, то теперь все чаще понимаешь, что бОльшая часть нужного уже где-то и как-то сделана, но сразу же встает вопрос, на что потратишь больше ресурсов: на разработку своего, понятного и полностью контролируемого, или на ковыряние в чужом, хождение по скрытым граблям, ожидание исправления багов и прочее. В итоге все больше времени уходит на тягостные раздумья о выборе оптимальных вариантов, а если б то же самое время убить на тупое написание кода, получилось бы не менее (а то и более) эффективно.
Вот сейчас заставил себя взяться за переделку одной из программ, чем собирался заняться уже года три, но в голове никак не складывалась четкая картина того, что должно было получиться в итоге. После нескольких дней наколачивания кода, с периодической переделкой структуры и взаимодействий, стало более-менее понятно, что получится в результате, и в целом уже начало оформляться. На несколько предыдущих попыток, когда пытался заранее спроектировать все красиво и изящно, ушло в разы больше времени — понятно, с нулевым результатом.
О подобных проблемах говорят и писатели: только у гениальных бывает, что текст льется на бумагу/клавиатуру прямо из головы, и потом достаточно лишь внести мелкие правки. Большинство же однозначно утверждает, что нужно тупо фигачить текст в том виде, как он получается прямо сейчас, расставляя метки в сомнительных местах, и заранее понимать, что бОльшую часть придется переписывать еще и еще. Когда я в молодости баловался журналистикой, именно такой подход давал наилучшие результаты. Бывало, наколотив уже половину статьи, понимал, что так выходит полная фигня, и нужно начинать совершенно с другой стороны, в другой последовательности, с другими акцентами и т.п. Иногда достаточно было переставить местами куски и слегка подправить, но приходилось и переписывать почти полностью. Если же силился заранее выстроить полную схему — толком ничего не получалось, пока не начинал писать текст.
Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Лично я просто пишу как получается. На каком-то этапе обычно всё переписываю с нуля, но переиспользуя куски старого кода, когда станет очевидно, что задуманная изначально архитектура не учитывала определённые вещи. Вероятно мне помогает то, что я использую Java, с которой такие трюки хорошо проходят в силу развитой IDE. Обычно со второго раза получается результат, который меня устраивает. Потом он обрастает дополнительным функционалом, доработками и тд, и в конце концов можно переписать всё ещё раз.
При таком подходе главное стараться писать код максимально изолированно, чтобы при переписывании собственно переписывания было как можно меньше, а было как можно больше переиспользования.
Но такой подход категорически не подойдёт, если разработчиков более одного человека.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>О подобных проблемах говорят и писатели: только у гениальных бывает, что текст льется на бумагу/клавиатуру прямо из головы, и потом достаточно лишь внести мелкие правки.
Это не у гениальных, просто талантливых. Тексты, как известно, диктуются духами, писакам достаточно просто их переносить на бумагу.
Не слышишь голосов в голове — не стоит и тужиться, все равно на выходе будет лажа.
ЕМ>Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Вообще для себя у меня есть как бы трекер задач.
Вот он и вносит какой-то порядок в планирование, приоритизацию, ну и просто чтобы не забыть.
Все спроектировать, а потом генерировать код, пыталась в Rational Rose, сейчас они вроде отдыхают на помоечке.
Предпочитаю начать делать хоть что-нибудь, большие куски, потом детали. Сразу в коде, да.
Свои проекты у меня слишком мелкие (как правило меньше 20к строк), чтобы для них потребовалась реальное проектирование.
Ну вот еще всякие юнит-тесты помогают, позволяют понять и задекларировать,
что вообще требуется и как должно работать, хотя я ни разу не фанат TDD.
А вот в компании, где больше нескольких программистов, доска с квадратиками и стрелками уже работает, обеспечивает общее понимание.
Тут может быть лучше несколько дней потерять на совещаниях и обсуждениях прежде чем начинать что-то пилить.
"Умные книги" зачастую заточены скорее под командную разработку, причем немаленьких систем (ну скажем больше 100к строк кода)
Здравствуйте, vsb, Вы писали:
vsb>При таком подходе главное стараться писать код максимально изолированно
Когда есть возможность оформлять функциональные блоки изолированно, проблем возникает минимум. Самые затыки начинаются, когда нужно делать взаимодействие со внешними подсистемами, которые могу вызывать я, а они — меня. А когда все это еще и асинхронно и многопоточно — вообще вилы. Ближайший пример — фильтры DirectShow.
это потому что программировать вы учились как самоучка
а не в высшем учебном заведении по правильной литературе
и ни дизайн патеррны, ни другие умные книги по правильной декомпозиции не читали
поэтому у вас краш как только много сущностей которые вы не знаете как связать
Здравствуйте, bnk, Вы писали:
bnk>Предпочитаю начать делать хоть что-нибудь, большие куски, потом детали.
Когда такая возможность есть — это просто отлично. Например, типичная интерактивная программа с менюшками и кучей функций, где можно сперва реализовать "Open File", потом "Close File", потом "Copy", "Paste" и т.п. А когда делается расширение какой-нибудь подсистемы, которое на почти любое действие получает от той подсистемы серию запросов, каждый из которых должно обработать полностью и корректно, иначе все упадет — это моя реальность.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда такая возможность есть — это просто отлично. Например, типичная интерактивная программа с менюшками и кучей функций, где можно сперва реализовать "Open File", потом "Close File", потом "Copy", "Paste" и т.п. А когда делается расширение какой-нибудь подсистемы, которое на почти любое действие получает от той подсистемы серию запросов, каждый из которых должно обработать полностью и корректно, иначе все упадет — это моя реальность.
Но разве тогда вообще есть выбор?
Если все интерфейсы и протоколы взаимодействия фиксированы, ты можешь контролировать (проектировать) только ту часть, которая связана собственно с функциональностью.
Я бы тогда вообще не парился по этому поводу, а напротив, радовался — за тебя все уже спроектировали, тебе осталось только реализовать как сказано, добавив свой кусочек.
Здравствуйте, reversecode, Вы писали:
R>это потому что программировать вы учились как самоучка
Учиться программировать я начинал в школе программистов у Ершова, на приличных языках (слова "фортран" и "бэйсик" там употреблялись наравне с матами), и с профессиональными учителями.
R>а не в высшем учебном заведении по правильной литературе
В высшем учебном заведении я учился во второй половине 80-х, когда в ходу (и в приоритетах) были совсем другие парадигмы. В частности, ООП тогда было сугубой экзотикой, а C++ только народился.
R>и ни дизайн патеррны, ни другие умные книги по правильной декомпозиции не читали
Читал, а толку? В применении к моим задачам это выглядит, как "я знаю самбо, дзюдо, каратэ и еще много страшных слов". Сможете показать, как с помощью дизайн-паттернов и подобных техник заранее (то есть, на этапе проектирования) избежать избыточных зависимостей, дедлоков, гонок, инверсий приоритетов и т.п.?
Здравствуйте, bnk, Вы писали:
bnk>Если все интерфейсы и протоколы взаимодействия фиксированы, ты можешь контролировать (проектировать) только ту часть, которая связана собственно с функциональностью. bnk>Я бы тогда вообще не парился по этому поводу, а напротив, радовался — за тебя все уже спроектировали, тебе осталось только реализовать как сказано, добавив свой кусочек.
Когда надо добавить именно локальный "кусочек" (например, расширение Explorer'а в винде, чтобы показывать свои пункты в контекстных менюшках), то отдельный этап проектирования даже в голову не приходит.
А когда нужно сделать, например, драйвер, который не просто тупо программирует устройство и обслуживает прерывания, но и расширяет его функциональность, гоняя какие-нибудь асинхронные обработки в параллельных потоках, то классическое проектирование мало что дает. Выстраиваешь изящную иерархию и вроде бы корректное взаимодействие, а потом оказывается, что уведомление о каком-нибудь событии присылается в неподходящем контексте. Делаешь, как советует дядя Боб, 100500 мелких функций, вызывающих одна другую в разных комбинациях, а потом выясняется, что эти комбинации должны работать на разных приоритетах, где доступны не все ресурсы и не все возможности API. Делаешь меньше критических секций, используя их для крупных блоков кода — получаешь тормоза, делаешь больше — получаешь дедлоки. Надежных способов бороться со всем этим не придумали — только разнообразные костыли и эмпирика.
А еще, когда делаешь подобные расширения — они часто вообще не заработают, пока не напишешь практически все. Для пресловутого интерактивного приложения, в котором за менюшки дергает только юзер, можно написать функции-затычки — тестировщику этого достаточно. А в сложносвязанной подсистеме нужно написать 80-90% всего когда, чтобы она более-менее зашевелилась. И это тоже сильно напрягает — фигачишь неделю, месяц, и даже не знаешь, будет оно нормально работать в таком виде, или придется переписывать половину. Отсюда и прокрастинация.
Здравствуйте, L.K., Вы писали:
LK>Т.е. сначала должна быть хотя бы "программа-минимум". Как всё должно быть, чтобы всё стало "более-менее удовлетворительно".
С "программой-минимум" как раз проблем нет. То есть, общая структура, функциональные блоки, схема взаимодействия понятны и так, в голове, без отдельного этапа проектирования. Задница начинается, когда уже написана изрядная часть кода, и выясняется, что не учтены нюансы, частные случаи, но их обработка требует или костылей, или изрядной переделки структуры. Чтобы обнаружить это на этапе проектирования, нужно фактически провести почти тот же объем работы, выписав хотя бы все форматы данных, внешние интерфейсы, функции API, наборы параметров и прочее, и уже потом писать со всего этого код. Проще и быстрее сразу начинать писать код.
ЕМ>С "программой-минимум" как раз проблем нет. То есть, общая структура, функциональные блоки
"Программа-минимум" — это не структура и не блоки, а вещи более высокого уровня. Для чего выполняется работа? Что будет в итоге? Куча бабла, мировая известность, спасение человечества?
Если задача не выполняется три года, то, может быть, она не нужна и не важна? А если нужна и важна, то получается, что вместо неё делается что-то менее нужное и важное?
Здравствуйте, L.K., Вы писали:
LK>"Программа-минимум" — это не структура и не блоки, а вещи более высокого уровня. Для чего выполняется работа? Что будет в итоге? Куча бабла, мировая известность, спасение человечества?
Если дать ответы на все эти вопросы, как это поможет лучше выполнить чисто техническую часть?
LK>Если задача не выполняется три года, то, может быть, она не нужна и не важна? А если нужна и важна, то получается, что вместо неё делается что-то менее нужное и важное?
Все, что делается, определенно нужно и важно, но для того, чтобы более-менее объективно определить степень нужности/важности каждого аспекта, нужно проводить отдельные бизнес-исследования. А речь, напомню, о разработчике-одиночке, а не о компании.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Всё сложно.
С одной стороны, мне хочется какой-то идеальный фреймворк, в который идеально ляжет моё приложение и всё будет идеально, поддерживаемо, расширяемо и тестируемо.
С другой стороны, время, убитое на попытки сделать единообразно и хорошо, очень существенно превышает время, потраченное на делание велью.
С третей стороны, код, который я реально переиспользовал на практике — это код, который не зависит от остального приложения и библиотек с нестабильным API.
Но с четвертой стороны, чтобы собрать приложение из изолированных модульных кусочков, нужно писать очень много glue code — для интеграции этих кусочков между собой.
И я пока (примерно за 15 лет) не понял, какой путь правильный.
Общая структура программы, иерархия модулей/классов, их взаимодействие в целом неплохо видны и умозрительно. Если все это оформить в виде схемы или описания на псевдоязыке — выглядит логично и красиво, пока не начинаешь наполнять все это кодом. Почти всегда вылезают те же самые несовместимости, особые случаи, взаимные блокировки параллельных потоков, потеря полезной информации в недрах вложенных вызовов и т.п. Полученное так же приходится изрядно переписывать, плюс добавляется время на само проектирование.
