но не могут?

обычно потому, что нашелся другой программист, который успел "структурировать" раньше )

Конкретные примеры будут?

> Почему программисты хотят структурировать код,

Чтобы их не побили другие программисты, которым потом пришлось иметь дело с этим кодом.

> но не могут?

Только те, кого мало били те самые другие программисты... :)

> Конкретные примеры будут?

так голосуем.
1) Программисты у которых с структурированием проекта все в порядке
2) И остальные которые не могут :)

Невозможно программировать, не имея представления о структуре проекта.
Так что у всех с этим полный порядок.
Ну, по крайней мере, они так думают )

> Невозможно программировать, не имея представления о структуре
> проекта.

О! Месье явно не имел дела с индусами... :)

> Месье явно не имел дела с индусами

мнения разделились :)

> SergeyIT ©   (08.12.18 22:36) [2]
>
> Конкретные примеры будут?

Поддерживаю.
Что значит "структурировать код"?

> Что значит "структурировать код"?

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

То есть структура - это некий скелет проекта, на который уже наращивают мясо функционала.
В период поддержки проекта для пользователей, затруднительно менять структуру,
поскольку на нем держится весь функционал и перестройка структуры приведет к новому
витку наращивания мяса функционала (а кому сие повторное действие надо?)

Это в первом приближении :)

Одним из известных способов структурирования проекта является система
MVC = Model + View + Controller
https://ru.wikipedia.org/wiki/Model-View-Controller

> Одним из известных способов структурирования проекта является
> система

ну и другие шаблоны проектирования:
Фасад (шаблон проектирования)
https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D1%81%D0%B0%D0%B4_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BC%D0%B5%D1%81%D1%82%D0%B8%D1%82%D0%B5%D0%BB%D1%8C_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

см. также Адаптер, Декоратор и т.д.

потому что это сложно

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

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

> xayam ©   (09.12.18 09:34) [9]

MVC касается визуальной части и конкретного программиста, структура поглубже будет.

Переделать большой проект, написанный в стиле "вся обработка - в обработчиках кнопок" на MVC обычно трудно из-за трудно отслеживаемого и трудно понимаемого течения управления: взаимного влияния обработчиков, вызовов Click из OnClick, большого числа контролов на форме и тучи рефрешей, которые обновляют в них данные. И только когда рефреши становятся циклическими, "программист" начинает подозревать, что, возможно, он что-то делает не так.

В этом случае, первое, что надо сделать, - отдать GIU другому программисту.

Обычно к этому моменту программа уже находится в эксплуатации и перевод проекта на MVC может затянуться из-за необходимости одновременно с этим править баги и реализовывать новые пожелания пользователей. Придется переводить поэтапно.

Контролировать данные в стиле MVC обычно проще, мне больше нравится сразу создать что-то вроде MVVM: одна модель для "внешнего" мира, другая для "экранного".

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

Ну а после этого можно браться за "красоту".

> Невозможно программировать, не имея представления о структуре
> проекта.
Как бы в задаче не про то спросили. ))

Интересное дело
Хотят (по крайней мере, из топика) структурировать но какие то трудности а еще и с оплатой за такие выкрутасы. А бесструктурно фигачить только в путь и платят?
Я тада за бесструктурность.))

> Sha ©   (09.12.18 11:53) [13]
...
> В этом случае, первое, что надо сделать, - отдать GIU другому
> программисту.

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

Потому что не могут?

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

>xayam ©   (09.12.18 09:34) [9]
>> Что значит "структурировать код"?
>некое действие над начальным кодом, которое уменьшит последующие глобальные
>переделки проекта в угоду заказчику,функционалу, либо еще каким-то причинам.

Обычно это принято называть архитектурой.

>Одним из известных способов структурирования проекта является система
>MVC = Model + View + Controller

MVC крайне противоречивая штука... Даже в приведенной ссылке приводятся несколько вариантов, которые противоречат исходно обозначенному взаимодействию ее 3х составляющих.

Есть несколько противоречий:
-Представление дергает контроллер, о котором знать не должно.
-Активная модель содержит всю бизнес-логику и доступ к данным. Представление реагирует на действия пользователя. К чему тогда контроллер?
-Современное представление по сути является смесью представления и контроллера, что никак не учитывается в MVC.
-Представление отображает изменение Модели, но где и как оно берет данные для отображения, особенно в случае больших таблиц?
-В случае если изменения состояния одних элементов Представления требует изменения отображения в других элементах Представления можно ли реализовать это на уровне Представления или делать через Контроллер?
и т.д.

Лично я считаю это основным признаком и критерием профессионализма программиста: умение делать продукт, удобный пользователю, а не "структурированный программистом".

Это так себе критерий.
Если такое умение есть, это ни о чем не еще говорит.

Одним из известных способов структурирования проекта является система
MVC = Model + View + Controller

именно что проекта, но не кода.
к тому же про этого мамонта (мвц) все давно уже забыли еще позавчера.