Фрагмент из книги Макконнелла "Совершенный код". В ней же: "На конструирование кода обычно приходятся около 65% работы в небольших и 50% в средних проектах. Во время конструирования допускаются около 75% ошибок в небольших проектах и от 50 до 75% в средних и крупных." Нетрудно заметить, что по мере роста объема текста возрастает процент ошибок, связанных не с квалификацией "наборщика текста", а с неправильным проектированием.

Да, вот это важная тема на самом деле. Давайте обсудим. Вот я, обычно прежде, чем приступить к написанию кода некоторое время трачу на проработку архитектуры будущей программы и её ключевых компонентов. Рисую там схемы, строю логические диаграммы и т.п. И вот когда я решаю что все, архитектура достаточно проработана - делаю логические схемы ключевых элементов. И уже потом начинаю писать код. Это очень просто - смотреть на схему и писать код. И далее постепенно детализирую код в обе стороны - наверх в сторону логики и исходных данных и вниз в сторону низкоуровневых процедур и выходного результата.

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

На самом деле процесс циклический. Я его называю – «анализ – синтез». Анализ = изучаешь язык программирования и его возможности, Синтез = придумываешь под него архитектуру своей программы и пишешь код. Язык программирования определяет архитектуру программы. И так по кругу. Через некоторое время опять Анализ, все ли получается и опять синтез.
Вывод: без разницы с чего начинать, все зависит от опыта.
Я вот столкнулся с тем, что один и тот же алгоритм не изменяя положить на Форт и С подобный язык проблематично.

В рамках Форта можно использовать любой синтаксис и Си в том числе.

Нет, время не значительно. А если сразу писать что-то, что не требует проработки, то потом оно может оказать ненужным. Поэтому я сначала думаю - а уже потом пишу код.

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


Конечно проблематично, если сравнить каким и как объёмом информации оперирует Си и Форт. (как одно из решений в этом направлении и было
введение в ANSI94 стандарт локальных переменных и некоторых других неоднозначных плюшек)

P.S. И Да, если не сокращать "выразительную" семантику кода программы (в основном через "удачный" лексикон слов) и как следствие размер программы,
то ошибки, с большой вероятностью, будут значительные. Отсутствие "формализованного синтаксиса Форт программы" в большей степени способствует
нивелирования этого. ( "Замыливание восприятия" минимально.)

Это время должно увеличиваться при росте объема проекта. Если это время значительно, это должно значить то, что качество проработки проекта улучшается и ошибок при его реализации будет меньше.

А потом то, что все же требует предварительной проработки, будет делаться по наитию? Причем каждый раз переписываться по-разному, в зависимости от того, с каким настроением программист сел за клавиатуру?

Только изучение языка программирования - это изучение инструмента. Анализ должен быть "анализом решаемой задачи".

А это совсем неправильно. Получается, что язык программирования определяет задачу целиком? То есть получается, что кто-то просит видеоплейер, но получает просмотр картинок, потому что язык программирования не может реализовать плейер? Решаемая задача определяет выбор инструментов, а не наоборот.

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

Лирическое отступление в тему.

Приезжаю я тут из отпуска, и вижу потекший холодильник. Пока нас не было, выгорел какой-то кусок проводки, идущий от подъездного распределителя. В квартире работает только освещение и единственная розетка, которая оказалась конструктивно совмещена с выключателем в коридоре, и на нее подано питание с того же автомата, что и на все люстры. То есть розеток нет на 99%, и на видных местах обрыва нет. Проведено все давно, многожильной медью вперемешку с алюминием, так что все надо перетягивать.

Что я сделал:
1. Нарисовал эскиз квартиры, усадил рядом жену и показал ей места установки новых розеток. Отдельно посчитали все приборы, которые надо будет включать в конкретные места, вместо удлинителей и тройников я заложил розетки на 2-3-4 прибора. Все места отмечены на эскизе.
2. Ткнул пальцем в место установки защитного автомата и три раза переспросил, нормально ли будет, если тут будет висеть "примерно вот такой" шкаф. От автомата рулеткой отмерил расстояние ДО КАЖДОЙ розетки, включая все повороты и изгибы. Записал все это, с отдельными строчками для кабель-каналов разных цветов (под обои, дверные косяки и штукатурку). Отметил на эскизе и записал количество распределительных коробок.

Ради интереса - пусть кто-нибудь напишет свои предположения по суммарной длине провода.

3. Составил список из 10 пунктов с подробным перечнем того, что и в каком количестве нужно. Далее с этим списком я "сделал дневную выручку" ближайшему строительному магазину.

4. Записал себе порядок монтажа розеток с учетом приоритетов в виде холодильников, микроволновки и стиральной машины.

Что в итоге:
1. В процессе работы из инструментов или проводов/розеток больше ничего не покупалось. Всего хватило, с учетом запаса на неминуемые потери.
2. В очень неудобных местах (8 сегментов кабель-канала, по углам и изгибам потолка) было желание пересмотреть это все и кинуть как-нибудь еще. Желание подавлено на корню, вместо этого замерил время монтажа одного сегмента и пообещал себе сделать перерыв, когда дотяну кабель до определенной точки.
3. Проводка получилась "модульной" - с аккуратными распределительными коробками, которые позволяют при необходимости обесточить конкретные розетки и перетянуть небольшой отрезок провода. Внутри никаких скруток и изоленты - потратил время на монтаж в клеммные колодки (которые также заложил предварительно в план).
4. Работа перфоратором СТРОГО в разрешенное время, соблюдая установленный по просьбе жильцов перерыв от 14:00 до 17:00 на дневной сон детей. Количество отверстий под крепеж было сосчитано заранее и прикинуто время, требуемое для них.

Результат: никаких мотков провода с торчащими клочьями изоленты. Никакого потенциального обрыва или нагрева от плохого контакта. Да, один раз постучали по батарее - перфоратор мощная штука К выходу на работу штатного электрика жилконторы все было готово к подключению автомата к подъездному щитку.

Аналогию с выполнением программного проекта кто-нибудь проведет?

+1

Насколько я помню, это три или четыре комнаты. На вскидку - метров сто кабеля ушло, а в комнатах наверняка по несколько мест установки розеток, то может даже и 150-200 метров.

Как-то так:
1. Разработка функционала, проектирование интерфейса система <> пользователь.
1.1 Выбор используемых компонентов и инструментов.
2. Разработка архитектуры.
3. Поиск и скачивание необходимых компонентов, настройка IDE и прочее.
4. Планирование порядка написания кода.

Я бы, наверное, не согласился. Получается, что какое-то одно решение является основой для всех последующих, а ничего принципиально нового при таком подходе не появляется. Локальные трансформации очень сильно тяготеют к тому, чтобы дойти до предела, за которым будет лучше уже все переписать. Не зря рекомендуют периодически полностью переписывать продукт, чтобы груз мелких изменений не начал тянуть его назад.

До чего же невозможный человек, ну никогда без шпильки не угомонится, вот уже и до Ксении Анатольевны докатился...

Именно это я и имел ввиду. Пример: Есть задача. Если мы свободны в выборе языка, то можно воспользоваться наработками и библиотеками. А если язык навязан сверху (у меня как правило именно такая ситуация), вот и приходится вначале ломать голову как положить общую схему проекта на новый язык и в конце от предыдущего варианта остается очень мало. Я к тому, что прога слияния разнородных БД выглядит по разному для С++ и 1С. Даже более простой пример. D и SPF - не могу впрямую совместить алгоритм из за небольших но имеющихся различий. Фразы Форт может всё - это всего лишь фразы, без поддержки реальным кодом.