спасибо Дмитрию Азараеву за ссылку

http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx

выдержки:

Разработчик ПО — это уникальная профессия, в которой мы можем использовать свои умения, как для работы, так и для хобби. В отличие от бухгалтеров, которые вряд ли спешат домой, чтобы подбить баланс семейного бюджета, многие из нас частенько возятся с кодом забавы ради и удовольствия для.

...

Мы перешли от «тонких клиентов» в «зеленоглазых» терминалах к «толстым клиентам» в виде приложений для ПК. Затем мы переметнулись к «тонким клиентам» на вебе, а с платформами наподобие Windows Presentation Foundation и глазом моргнуть не успеем, как снова окажемся рядом с «толстыми клиентами». Как бы там ни было, наши системы продолжают делать одно и то же: запись/чтение данных.

...

«Уныние» и «скука» — два слова, которые не очень-то вяжутся с девелоперами. Мы — сборище аналитиков, имеющих зачастую образование специалиста компьютерных наук (информационных технологий). И мы способны на гораздо большее, нежели строчка за строчкой сводить фронт-энды с бэк-эндами. Возможно, мы могли бы облегчить нашу работу, используя свои навыки и способности.

Здесь-то и кроется загвоздка.

...

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

...

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

Здравствуйте, Mamut, Вы писали:

M>спасибо Дмитрию Азараеву за ссылку

M>http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx

http://enfranchisedmind.com/blog/posts/programming-doesnt-suck-or-at-least-it-shouldnt/

Здравствуйте, Mamut, Вы писали:

M>http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx

Совершенно согласен. Но как говорило порождение коллективного творчества, некий Козьма Прутков: если хочешь быть счастливым — будь им. Меня программирование в виде мэйнстрима уже давно не привлекает, это действительно скукота смертная. Я — вообще не программист, если уж на то пошло. Я не особо разбираюсь в так называемых "соврменных технологиях". Но я специалист и инженер. И именно по этой причине я все эти так называемые "технологии", которые на практике оказываются тоскливой рутиной типа разноски чая менеджерам — вертел я все эти "технологии" сами знаете на чем. И знаете — парадокс: Чем больше я "вертел", тем боллее лестные предложения о работе получаю. Это правда. Такие дела.

Здравствуйте, Fwiffo, Вы писали:

F>http://enfranchisedmind.com/blog/posts/programming-doesnt-suck-or-at-least-it-shouldnt/
F>

Спасибо! На огромное количество комментов на рсдн можно отвечать этой ссылкой.

Здравствуйте, Mamut, Вы писали:

M>http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx

Вот за это:

Тот код 10-летней давности, написанный на «классическом ASP», не устарел — его просто не так прикольно сопровождать.

хочется поставить отдельную оценку автору! Просто отлично сказано.

Здравствуйте, Mamut, Вы писали:

Настоящие рок-звёзды...

Этот стон у нас песней зовётся. (c)

M>http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx
M>

M>Нелегко принять тот факт, что программное обеспечение, которое мы пишем каждый божий день, независимо от его назначения и целей, — это скукотища смертная. Управление подпиской на журналы. Отчёты о медицинских счетах. Управление реестром недвижимости. Это не те программы, которые изменяют мир. На самом деле они даже вряд ли вызовут улыбку на чьём-нибудь лице. На практике их истинное назначение сводится к повышению производительности неких работников.

На dwtf опять кризис ? Ну так это у них сезонное. Весна скоро ...

Здравствуйте, Mamut, рассказываю по пунктам:

1. Изучайте бизнес.

Здесь нет претензий. Да, предметную область необходимо понимать.

2. Служите интересам бизнеса. Каждый ремесленник хочет использовать самые последние, великолепные и мощные инструменты, но они редко необходимы для работы. Подобно этому практически никогда невозможно мгновенно обновить платформы/библиотеки/языки. Тот код 10-летней давности, написанный на «классическом ASP», не устарел — его просто не так прикольно сопровождать.

А здесь начинается каша в голове. Если инструменты "великолепны и мощны", то очевидно, они необходимы и бизнесу тоже. В противном случае они не мощны и не великолепны. И следовательно, пресловутому ремесленнику даром не нужны.

3. Учитесь вне работы.

Допустим. Хотя на самом деле процесс обучения очень тесно переплетён с работой. Такова уж наша специфика: если проблема хорошо знакома, то она уже закодирована, а если проблема не знакома, то что-то предварительно следует изучить.

4. Кодируйте главным образом бизнес-логику.

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

... А теперь добавьте весь код, необходимый для валидации и сохранения данных, полученных из UI. Если математика меня не подводит, в результате мы получаем туеву хучу унылого, скучного кода.

и едва ли не необходимым:

Для определения скучного ПО есть специальный термин — «информационные системы».

Хотя если разобрться, то сам себе противоречит. Посмотрите на этот код повнимательней:

txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;

Я выделил действительно прикладной код жирным шрифтом. Остальное — это никакая не бизнес-логика, а инфраструктурный код. Это очень легко проверить, подменив инфраструктуру:

MyForm.assignData(txtFirstName, 30, 50, Validations.LettersOnly, securityContext.CanEdit, customerRecord.FirstName);

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

5. От скуки не уйти. Никакие O/R-мапперы или генераторы кода не смогут избавить вас от факта, что записи, поля, валидаторы и т.п. должны быть прописаны вручную, по крайней мере, в двух местах (фронт-энд и бэк-энд). И UI, генерируемая из базы — это также плохо, как база, генерируемая из UI.

Определённо, автор ничему не учился ни на работе, ни вне работы. Во всяком случае, своей головой он дошёл только до того, что "от скуки не уйти". Собственнно, сужение пространства доступных решений заметно вот тут: "UI, генерируемая из базы — это также плохо, как база, генерируемая из UI". Фокус в том, что между UI и "базой" можно поставить ещё очень много всего интересного, из чего уже впоследствии "отобразить" и базу, и UI.

Но автор, по-видимому, не преуспел в подобных изысках. Я хочу обратить внимание вот на это высказывание:

[...]И мы способны на гораздо большее, нежели строчка за строчкой сводить фронт-энды с бэк-эндами. Возможно, мы могли бы облегчить нашу работу, используя свои навыки и способности.

Здесь-то и кроется загвоздка. Как выразился Майкл А. Джексон в своих «Принципах проектирования программ» 1975 года, «Программисты… часто находят спасение в их, в общем-то, понятном, но на деле губительном стремлении к усложнениям и ухищрениям в своей работе. Отстранённые от создания чего-либо большего, чем просто программа, они отвечают тем, что делают эту программу до такой степени замысловатой, чтобы она была достойным вызовом для их профессиональных навыков».

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

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

Ну что тут скажешь? "Кто виноват, что ты устал?" (c) Кто виноват, что кроме желания посоревноваться с самим собой за твоими изысками ничего стоящего не было? Только ты сам.

6. Ищите удовлетворение повсюду.

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

7. Найдите себе другую работу.

Можно ведь и не на иждивение проситься.

Здравствуйте, eao197, Вы писали:

E>Вот за это:
E>

E>Тот код 10-летней давности, написанный на «классическом ASP», не устарел — его просто не так прикольно сопровождать.

E>хочется поставить отдельную оценку автору! Просто отлично сказано.

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

Здравствуйте, Геннадий Васильев, Вы писали:

E>>

E>>Тот код 10-летней давности, написанный на «классическом ASP», не устарел — его просто не так прикольно сопровождать.

E>>хочется поставить отдельную оценку автору! Просто отлично сказано.

ГВ>Только предварительно нужно закрыть глаза на контекст.

Контекст может восприниматься по разному. Ты его воспринял практически так же, как и автор сего опуса: http://enfranchisedmind.com/blog/posts/programming-doesnt-suck-or-at-least-it-shouldnt/
Я же воспринял его по другому. И с моей точки зрения, между этими двумя фрагментами кода:

txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;

и

MyForm.assignData(txtFirstName, 30, 50, Validations.LettersOnly,
  securityContext.CanEdit, customerRecord.FirstName);

нет никакой принципиальной разницы. Ведь перед программистом стоит все одна и та же унылая задача: установить максимальную длину, длину видимого текста и пр. Задачу эту можно решить и так, и так, и еще несколькими способами. Но увлекательности задаче ни однин из способов решения не добавит.

Если только разработчик не решит создать минифреймворк для автоматического конфигурирования контролов на основании информации из конфигурационного файла. После чего код будет заменен на что-то типа:

MyForm.SetControlProperties(txtFirstName, "MyForm.FirstName");

с переносом всей прикладной лабуды в XML:

<form name="MyForm">
  <edit id="FirstName">
    <displayWidth value="30" />
    <maxLength value="50" />
    <validation type="LettersOnly" />
    <enabled value="$(SecurityContext.CanEdit)" />
    <value>$(CustomerRecord.FirstName)</value>
  </edit>
</form>

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

Здравствуйте, eao197, Вы писали:

E>Если только разработчик не решит создать минифреймворк для автоматического конфигурирования контролов на основании информации из конфигурационного файла. После чего код будет заменен на что-то типа:
E>

E>MyForm.SetControlProperties(txtFirstName, "MyForm.FirstName");
E>

E>с переносом всей прикладной лабуды в XML:
E>

E><form name="MyForm">
E>  <edit id="FirstName">
E>    <displayWidth value="30" />
E>    <maxLength value="50" />
E>    <validation type="LettersOnly" />
E>    <enabled value="$(SecurityContext.CanEdit)" />
E>    <value>$(CustomerRecord.FirstName)</value>
E>  </edit>
E></form>
E>

E>Да, программист сделает задачу интереснее для себя. Даже какое-то время будет гордится своим творением. Пока его не забабахает сопровождать свой минифреймворк. Или пока этот минифреймфорк не перейдет на сопровождение кому-то другому. Но проблема-то в том, что подобный минифреймворк вообще нафиг здесь не нужен. Это всего лишь попытка программиста "творчески" подойти к решению задачи. И, что характерно, подходят и делают что-то подобное. Чтобы потом, лет через надцать, понять, что нифига это не нужно было. И что для тупых задач нужно применять тупые решения. А если это кому-то не нравится, то он может сменить работу

Не поверишь, на позапрошлой (или позапозапрошлой, не суть) работе мы как раз сделали такой минифреймворк, декларативное описаное GUI на XML, с механизмом байндингов. Сделали простенький редактор. В итоге формочки рисовали сами заказчики, мы лишь делали некоторые специфические контролы. Для чего это делалось? Думаешь попытка программистов "творчески" подойти к решению задачи? А ннет... это было пожелание заказчиков. Как результат очень сильно повысилась производительность всего процесса добавления новой функциональности в области GUI, им не надо было писать спеку на GUI, нам его делать, итд... И что странно, работу у нас как раз меняли те, кто считали это тупой задачей и хотели применять тупые решения. Так то. А Вам видимо очень "повезло" с вашей работой

Здравствуйте, Mamut, Вы писали:

M>http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx

Мне кажется, автор неправильно понял смысл KISS principle

Здравствуйте, yumi, Вы писали:

Y>Не поверишь, на позапрошлой (или позапозапрошлой, не суть) работе мы как раз сделали такой минифреймворк, декларативное описаное GUI на XML, с механизмом байндингов.

Поверю. Люди постоянно делают глупости. Например, придумывают XML и запихивают его в каждую дырку.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А здесь начинается каша в голове. Если инструменты "великолепны и мощны", то очевидно, они необходимы и бизнесу тоже. В противном случае они не мощны и не великолепны. И следовательно, пресловутому ремесленнику даром не нужны.

а чо ж тогда немераль-то не выстреливает?... (вопрос риторический, навеян соседней темой)

ну вообще, про "великолепные и мощные инструменты" оно, с одной стороны так, но с другой сидит god class.

Здравствуйте, Mamut, Вы писали:

M>спасибо Дмитрию Азараеву за ссылку

M>http://ru.thedailywtf.com/Articles/Programmirovanie--otstoj!-Ili-chtoto-vrode-togo.aspx

M>выдержки:
M>

Нелегко принять тот факт, что программное обеспечение, которое мы пишем каждый божий день, независимо от его назначения и целей, — это скукотища смертная. Управление подпиской на журналы. Отчёты о медицинских счетах. Управление реестром недвижимости. Это не те программы, которые изменяют мир.

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

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

А где упонинание о самом главном, о качестве?
Хотя судя по его "богатому" опыту, качество вовсе не является определяющим критерием.
Главное быстренько забабахать горе-софтинку, получить деньги и бежать, бежать, бежать ...

Здравствуйте, 4058, Вы писали:

4>А где упонинание о самом главном, о качестве?

Качество в массовом софтостроении уже давно не главное.

4>Хотя судя по его "богатому" опыту, качество вовсе не является определяющим критерием.

Не является.

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

Зачем же бежать. Потом можно получать деньги и за сопровождение горе-софтинки.

Здравствуйте, ili, Вы писали:

ГВ>>А здесь начинается каша в голове. Если инструменты "великолепны и мощны", то очевидно, они необходимы и бизнесу тоже. В противном случае они не мощны и не великолепны. И следовательно, пресловутому ремесленнику даром не нужны.

ili>а чо ж тогда немераль-то не выстреливает?... (вопрос риторический, навеян соседней темой)

Я правильно помню, что риторические вопросы не требуют ответа?

ili>ну вообще, про "великолепные и мощные инструменты" оно, с одной стороны так, но с другой сидит god class.

Моя твоих понимать нет. Почему с другой сидит, почему со своей не присядет? Свою обижает, с другой садится... Ай-яй-яй...

Здравствуйте, eao197, Вы писали:

E>Зачем же бежать. Потом можно получать деньги и за сопровождение горе-софтинки.

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

Другое дело, что отмывание денег на IT, сейчас очень популярно,
что собственно и привело к росту таких вот "философов", на подобие автора статейки и его "братьев по разуму".

Здравствуйте, 4058, Вы писали:

4>Другое дело, что отмывание денег на IT, сейчас очень популярно,
4>что собственно и привело к росту таких вот "философов", на подобие автора статейки и его "братьев по разуму".

Да ладно глобальных врагов выискивать. Достаточно в зеркало посмотреть. Вот, скажем, жизненый пример -- делается ремонт в собственной квартире, для себя любимого, за собственные деньги. Можно купить ламинат 31-го класса за $15 за квадрат, можно 32-го за $25, можно 33-го за $40 (условно говоря). Понятно, что качество 33-го класса гораздо лучше качества 31-го. Будете вы покупать именно 33-й класс?

Здравствуйте, eao197, Вы писали:

E>...делается ремонт в собственной квартире, для себя любимого, за собственные деньги. Можно купить ламинат 31-го класса за $15 за квадрат, можно 32-го за $25, можно 33-го за $40 (условно говоря). Понятно, что качество 33-го класса гораздо лучше качества 31-го. Будете вы покупать именно 33-й класс?

Если денег хватит, то да. Или 32-й, если комната не особо "ходовая". Правда кроме класса у ламината ещё и рисунок, например, есть.
А ещё понятие "собственная квартира" немного размыто. Она совсем собственная, и та, в которой живёшь именно ты?
Или, например, та, где любимая тёща живёт?