казинакПоскольку документирование и проектирование просто не выгодно программистам.

да не совсем так, всё проще
просто за этот этап редко платят

egorychLast1Cmenпропущено...

да не совсем так, всё проще
просто за этот этап редко платятвсё ещё проще. просто проектировать - это ведь так скучно )) куда увлекательней писать код: и процесс сразу виден, и люди явно чем-то заняты ))

ну почему скучно... не всем
мне например наоборот
а когда уже знаешь как сделать да ещё и получилось описать "на бумаге" то дальше уже кодинг это такааая скукотища :)

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

но как-то работает и как-то работают

казинакПо идее, все так и должно было бы быть.
Если не секрет, что и как вы излагаете на бумаге?


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

казинакLast1Cmenда по разному бывает и на бумаге реально... визио ексель ворд... не суть важно где (желающим поумничать насчет средств проектирования - не тут и без меня)
главное не то где а то что пытаясь изложить свои мысли в осмысленные предложения и графические образы тем самым происходит осмысление картины вцелом
и если получилось описать не только в голове то уже полдела считай есть :)... а если оно и "на бумаге" не работает или не складывается в общую картину то шансов что оно вообще заработает очень мало или это не твое :(
Я когда приступаю к задачке, составляю документ примерно такого плана.
1.Описания таблиц, полей, ключей. ERD.
2.Описания пакетов (или классов), процедур, ф-ций. Пишу в основном цель этого пакета (ф-ции). Алгоритмы и какие-то синтаксические конструкции не описываю.
3.Блок-схемы (Диаграммы UML не нравятся). Укрупненно. В детали не влезаю.
4.Примерный дизайн форм.

Задачки у меня в основном типа CRUD.

А у вас как? Или это ваше секретное ноу-хау:)

третье и второе (причем именно так - в обратном порядке)

первое и четвертое для меня не суть важно потому как первое будет логическим продолжением 3 и 2 а четвертое для финансовой (учетной) сферы моей деятельности не есть высшим приоритетом (не игры или платежные системы и для оператора разве что эргономика будет играть роль а не дизайн)

т.е. главное понять

- что именно необходимо (а это не всегда именно то что озвучивает заказчик)
- как именно можно достичь этого (сам алгоритм, механизм, методика т.е. у вас пункт 3 )
- что необходимо для реализации (вот тут уже пункт 2 т.е. конкретика касательно технологии реализации)

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

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

разумеется это не касается мелких задач или типовых
что там на больших проектах я не знаю не занимался