Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>О подобных проблемах говорят и писатели: только у гениальных бывает, что текст льется на бумагу/клавиатуру прямо из головы, и потом достаточно лишь внести мелкие правки.
Это не у гениальных, просто талантливых. Тексты, как известно, диктуются духами, писакам достаточно просто их переносить на бумагу.
Не слышишь голосов в голове — не стоит и тужиться, все равно на выходе будет лажа.
ЕМ>Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Вообще для себя у меня есть как бы трекер задач.
Вот он и вносит какой-то порядок в планирование, приоритизацию, ну и просто чтобы не забыть.
Все спроектировать, а потом генерировать код, пыталась в Rational Rose, сейчас они вроде отдыхают на помоечке.
Предпочитаю начать делать хоть что-нибудь, большие куски, потом детали. Сразу в коде, да.
Свои проекты у меня слишком мелкие (как правило меньше 20к строк), чтобы для них потребовалась реальное проектирование.
Ну вот еще всякие юнит-тесты помогают, позволяют понять и задекларировать,
что вообще требуется и как должно работать, хотя я ни разу не фанат TDD.
А вот в компании, где больше нескольких программистов, доска с квадратиками и стрелками уже работает, обеспечивает общее понимание.
Тут может быть лучше несколько дней потерять на совещаниях и обсуждениях прежде чем начинать что-то пилить.
"Умные книги" зачастую заточены скорее под командную разработку, причем немаленьких систем (ну скажем больше 100к строк кода)