но не могут?

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

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

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

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

> но не могут?

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

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

так голосуем.
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

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

А что сейчас актуально?

mvvm например будет поновее.

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

так это не взаимозаменяемо
например в том же вебе (сервер) наворачивать мввм себе дороже, а мвс хоть бы что. )

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

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

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

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

и там естественно никаких мвц, мввм и прочего не было и не могло быть.

чисто процедурный подход.

> [24] FreeAndNil ©   (20.12.18 00:10)
> сил и воли

А мне нравится это сочетание букаф. Про потопы только не очень нравитс.

> [25] Inovet ©   (20.12.18 03:55)
> нравитс.

нравится.

Ваш недуг есть в МКБ-10 https://tinyurl.com/nnkvan7

С этим надо что-то делать, а не сидеть сложа руки. Тем более если не нравится.
Например найти одну любую картину про эту страну (гравюру, открытку, рисунок, иллюстрацию в книжке...) 18 века или старше.

И чтобы там была зима. Но не просто как время года, а как когда на улице снег.

PS "Взятие снежного городка" Сурикова - не подходит. это середина девятнадцатого.

Зиму не рисовали не потому что зимы не было, а потому что рисовать нечего, все белое. Не интересно. ))))

не, не так.

вот были руинисты, но у них у всех поголовно был бзик. они рисовали фантазии.
теперь говорим, что реалисты-пейзажисты тоже все поголовно были нездоровы на голову и не рисовали зиму со снегом вплоть до 19 века.

так будет правильнее.

и главное не останавливаться в этом деле.
вот многотомный научный труд https://tinyurl.com/ydat89xs
прослеживается история военного костюма с 862 года до времен николая 1

и как говорится "найди кота". или угадай в чем ходили в январскую зимнюю стужу русские солдатики.

и если это там не зафиксировано в чем они ходили, то это значит что?
правильно. это значит что висковатый - он тоже "того".

ну это просто, воевали летом, зимой пироги пекли и на печи грелись

> [27] FreeAndNil ©   (20.12.18 09:29)
> Ваш недуг есть в МКБ-10 https://tinyurl.com/nnkvan7

Нет, недуг не у меня и не этот. Ты же не привёл не единого аргумента, а я, и не только я, бы принял, коли б они были. Но раз нет, то только верунство в тайны остаётся. А я, и такие как я, не веруны. Вот и весь диагноз, и этот диагноз мне нравится.

> [29] FreeAndNil ©   (20.12.18 11:30)

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

Я понимаи, это от тогго, что ничего другого не остаётся кроме клоунады.

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

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

и все что тебе остается - тупо отрицать.

> [33] FreeAndNil ©   (20.12.18 22:07)
> и все что тебе остается - тупо отрицать.

Не, мне интересно всякое, совсем не отрицание. Да и любому, ну большенству, я полагаю, тоже. Тем кто не просто дилетаски что-то там болтает на ДМ, как я и ты, а занимается этими науками всю жизнь. Но нужна более аргументированная база. Пока что всё это похоже на фантазии с притягиванием желаемых "доказательств". А ведь реально было бы круто, будь оно более обосновано. Был бы вообще переворот всего.

а я, и не только я, бы принял, коли б они были.

смотри как легко ломается твой шаблон:

аргументов было множество и ни один ты не смог опровергнуть.
даже попыток не было, а только отрицание.

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

теперь взламываем твой мозг детским матом:

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

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

но назвать какого рода аргументы тебя устроят ты тоже не сможешь.
потому что а вдруг их у меня есть и не один? и что тогда?

> [35] FreeAndNil ©   (20.12.18 22:52)

Да я же с тобой уже год почти веду переписку, так что уточнять ещё раз нет желания. Я только не могу понять, как ты сам не видишь своих заблуждений, ну вроже бы очевидно всё. Что тут такое кроется в психологи ли или в чём ещё. А в чём ещё, сам же на психологию ссылаешся. Увы мне - не могу понять, хоть и постоянно встречаюсь с этим явлением. И даже, ты не поверишь, у себя самого иной раз сейчас или в прошлом. Так что про разрыв шаблонов ты правильно понимаешь, только бы ещё умел применить - разорвать т.е.. Но, сдаётся мне, что мы переходим на обсуждение личных качеств вместо интересных вопросов?

так что уточнять ещё раз нет желания.

чтобы уточнять (да еще и "еще раз") нужно сначала иметь что уточнять.
а я ни разу не услышал про то, какого рода аргументы годятся тебе для обсуждения.

что ты там собрался уточнять?

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

так что это оно и есть защитное отрицание. функция психики.

Я только не могу понять, как ты сам не видишь своих заблуждений

я помогу тебе понять почему.

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

и тебя это то ли тревожит, то ли сильно раздражает.

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

Господа, не проясните, об чем речь с отсутствующими зимними одежками и пейзажами?