О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

Нужен контекст. Заказчик пытается решить какую то проблему, нужно понять какую. Ему эта сумма чисел зачем нужна?

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

Ему эта сумма чисел зачем нужна?

А какие варианты? С учётом того, что задача не является законченной программой, заказчик у нас разработчик чего-то крупного.

Пусть будет, «сумма от 1 до 100» – это размер для хранения каких-то данных, оцененный аналитиком. Или пусть это будет пример в тексте для пользователя (t.Text = "Например, компьютер может посчитать сумму чисел от 1 до 100. Это будет " + yourModule::sum_1_to_100()).

Если программист-фрилансер, то да. Ещё как юрист должен составить договор и как главбух сдать отчётность и заплатить налоги.

Если он именно программист, то ему приходит согласованное ТЗ, в котором лигвистические неоднозначности по возможности убраны, а его задача составить алгоритм, а потом закодировать на выбранном языке программирования. Иногда на вторую подзадачу берут отдельного человека — кодера (он знает язык программирования, но не умеет программировать без готового детального алгоритма).

Все зависит от ценности заказчика для меня, если это контрольная на уроке информатики то вариант return 5050 вполне может прокатить) есть прецеденты.)

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

Пусть будет, «сумма от 1 до 100» – это размер для хранения каких-то данных, оцененный аналитиком.

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

Или пусть это будет пример в тексте для пользователя (t.Text = "Например, компьютер может посчитать сумму чисел от 1 до 100. Это будет " + yourModule::sum_1_to_100()).

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

Если он именно программист, то ему приходит согласованное ТЗ, в котором лигвистические неоднозначности по возможности убраны, а его задача составить алгоритм, а потом закодировать на выбранном языке программирования. Иногда на вторую подзадачу берут отдельного человека — кодера (он знает язык программирования, но не умеет программировать без готового детального алгоритма).

Если честно я не часто сталкивался с аутсорсом, там реально такой дикий ад?

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

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

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

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

Если честно я не часто сталкивался с аутсорсом, там реально такой дикий ад?

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

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

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

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

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

Время программиста

Время программиста которого ты описываешь не может стоить дорого) он же ни о чем не задумывается)

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

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

Время программиста которого ты описываешь не может стоить дорого) он же ни о чем не задумывается)

В смысле? Он составляет алгоритмы. И, в общем случае, никто кроме него алгоритм составить не может: ни заказчик, ни аналитик, ни кодер.

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

Не очень понял зачем.

Более того, не в каждом тексте (см п.12) имеет смысл давать трогать руками.

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

В смысле? Он составляет алгоритмы. И, в общем случае, никто кроме него алгоритм составить не может: ни заказчик, ни аналитик, ни кодер.

Любой дурак с улицы программист по объявлению может написать так что бы программа просто работала. Если он этого не может то он даже не программист. А градация программистов определяется тем чем дольше их код работает в проекте. Если человек может написать чтобы работало но на следующий день его код отрефакторят из за того что условия изменились то толку с такого программиста очень мало.

Любой программист по объявлени может написать так что бы программа просто работала. Если он этого не может то он даже не программист.

Да ну? Или «просто работала» в математическом смысле? Наименьший общий делитель находим перебором чисел, начиная с 2, а задачу об упаковке рюкзака решаем полным перебором?

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

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

Не очень понял зачем.

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

Да ну? Или «просто работала» в математическом смысле? Наименьший общий делитель находим перебором чисел, начиная с 2, а задачу об упаковке рюкзака решаем полным перебором?

Ну да, это что не алгоритм? не решение задачи?

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

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

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

А ты готов подорваться в 3 часа ночи что бы отрефакторить проект?

Ну да, это что не алгоритм? не решение задачи?

В постановке задачи ещё ограничение по времени есть. Поэтому не решение.

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

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

А ты готов подорваться в 3 часа ночи что бы отрефакторить проект?

В 3 часа ночи внезапно изменится постановка задачи? Так не бывает.

Вот хороший пример про прогнозирование: https://habr.com/ru/post/153225/

В 3 часа ночи внезапно изменится постановка задачи? Так не бывает.

Мы захардкодили объем данных для аналитики. Поздно вечером аналитики готовили отчеты для аудита, место закончилось, формула «сумма от 1 до 100» оказалась не верной, 3 часа тупили, бегали по офису не зная что делать и потом позвонили тебе, если ничего не сделать то компания лишается лицензии и банкротится.

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

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

В смысле? Он просто делает минимально работающее решение. Условно, return 5050. Пришли новые вводные (не до 100, а до произвольного числа), добавит один параметр return n*(n+1)/2 и т.д.

В смысле? Он просто делает минимально работающее решение.

Он делает решение которое не приходится рефакторить! Каким раком он это делает одному богу известно но он ценный программист.

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

При этом виноваты сами, так как при постановке задачи за язык их никто не тянул. Сделаю в 3 часа ночи по 30-кратной стоимости.

Он делает решение которое не приходится рефакторить!

Гм… ты представляешь, как на каждой итерации с нуля переписывается createBread? В этом смысле return 5050 тоже не приходится рефакторить: будет новая задача там будет новый код.

При этом виноваты сами, так как при постановке задачи за язык их никто не тянул. Сделаю в 3 часа ночи по 30-кратной стоимости.

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

А вот в случае информированного согласия можно сказать: «Ну я же вас предупреждал, вы отказались, а теперь будьте добры х30 оплату.»

Гм… ты представляешь, как на каждой итерации с нуля переписывается createBread? В этом смысле return 5050 тоже не приходится рефакторить: будет новая задача там будет новый код.

И каким то образом он предсказал что изменение задачи каждый раз будет приводить к написанию кода с 0. Сделал все в одном методе который и будет переписываться, идеально же. Думаю он что то знал о ПМ.

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

Вот если Маркус регулярно принимает подобные качественные решения то он явно что то понимает в программировании.

Не пойму, это сарказм? Или ты действительно считаешь, что это правильный подход, когда всё в одном методе?

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

Договор, заверенный с двух сторон печатями, является информированным согласием (как бы информированней не придумаешь). По крайней мере у нас ещё не приходится на микроволновках писать «не сушите животных», а на всех программах «может прекратить работу при недостатке оперативной памяти».

Не пойму, это сарказм?

Нет это не сарказм.

Или ты действительно считаешь, что это правильный подход, когда всё в одном методе?

В истории с Маркусом это оказалось правильным решением. Ты так не считаешь?

Я же написал что правильное решение это то которое приводит к меньшим проблемам в будущем. Необходимость рефакторинга это один из маркеров. А каким образом программистам удается принимать правильные решения это их профессиональный секрет.

Бездумное накручивание паттернов не является правильным решением.

Договор, заверенный с двух сторон печатями, является информированным согласием (как бы информированней не придумаешь). По крайней мере у нас ещё не приходится на микроволновках писать «не сушите животных», а на всех программах «может прекратить работу при недостатке оперативной памяти».

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

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

Вот хороший пример про прогнозирование: https://habr.com/ru/post/153225/

Гениальная статья. Наглядно объясняет нашу тему. Но ещё интереснее продолжение: Хлеб Маркуса и YAGNI. Маркус спокойно менял код без переписывания с нуля, а просто добавлением конкретных классов и enum-ов. И почти никакого наследования - только в конце добавился один абстрактный класс, без которого можно было бы и обойтись с помощью композиции.

Я вот только не могу понять, как эта цитата совмещается с этой:

Не пойму, это сарказм? Или ты действительно считаешь, что это правильный подход, когда всё в одном методе?

и этой:

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

Но ты предлагаешь ввести презумцию неадекватности, считать всех клиентов неадекватами.

Так наоборот же. Считать, что если клиент что-то указал явно, то это истина. Если не указал, выбираем наиболее разумное умолчание (цвет и размер шрифта, требования к скорости выполнения, структура хранения данных, …).

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

Я работаю на компанию. Лично гендир заказчик редко, но все остальные нормально воспринимают ситуацию «вы здесь писали, что должно быть так, поэтому сделано так».

Необходимость рефакторинга это один из маркеров.

Так у Маркуса надо каждый раз полностью рефакторить (единственный) метод. А у его конкурента на каждой итерации 90% кода неизменны (и их потенциально можно повторно использовать).

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

но все остальные нормально воспринимают ситуацию «вы здесь писали, что должно быть так, поэтому сделано так».

гос контора?

А что не так? Я пытаюсь понять точку зрения своего оппонента.

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

гос контора?

ООО на 500 человек. АСУшников 10.

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

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

ООО на 500 человек. АСУшников 10.

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

Если тебя просят накидать скрипт который один раз должен отработать и ты его выкинешь

То, на что этот ответ, работает в долгоживущих проектах (модификации кода 1С). Если что-то можно сделать функцией, это лучше сделать функцией, а не городить новый класс.

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

Всё равно нужно согласование реализации. Пожелание «надо видеть остаток по материалам». Предложенная реализация «давай сделаем отчёт по остаткам», уточнённая реализация от заказчика «в документе списания пусть внизу пишет остаток по текущей строке», далее ещё одно уточнение касательно текста строки и её положения и это окончательная постановка задачи.

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

То, на что этот ответ, работает в долгоживущих проектах (модификации кода 1С). Если что-то можно сделать функцией, это лучше сделать функцией, а не городить новый класс.

Это был ответ на абстрактное утверждение о том как ты используешь ооп. работает и хорошо.

Всё равно нужно согласование реализации. Пожелание «надо видеть остаток по материалам». Предложенная реализация «давай сделаем отчёт по остаткам», уточнённая реализация от заказчика «в документе списания пусть внизу пишет остаток по текущей строке», далее ещё одно уточнение касательно текста строки и её положения и это окончательная постановка задачи.

Ну да, обсуждать то ни кто не запрещает.

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

Для сортировки что важнее.

Для сортировки что важнее.

Ясно. Мне проще у заказчика спросить, если вдруг от одного заказчика несколько заявок прилетело. К тому же, если спрашивать зачем, то будет расплывчатое «улучшение скорости работы», «повышение удобства работы» и как из этого выбирать что срочнее, совсем не очевидно.

А что не так? Я пытаюсь понять точку зрения своего оппонента.

Возможно, я рано влез. Просто мне приходилось работать и с архитектурой Бориса и с архитектурой Маркуса из статьи. Так вот рефакторить (менять код без изменения функционала) код Маркуса намного проще, чем рефакторить код Бориса, особенно, если этих UML-диаграмм они тебе не предоставили. Да что там рефакторить, его и понять проще. Я уже не говорю о том, что в код Маркуса проще добавлять новый функционал.

Что касается «весь код в одном методе», то это не так. На такой UML диаграмме не требуется указывать приватные методы. Соответственно, Маркусу ничего не мешает делегировать из публичного метода в дополнительные приватные.

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

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

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

Это был ответ на абстрактное утверждение о том как ты используешь ооп. работает и хорошо.

В ответе была пресуппозиция, что я его так использую в одноразовых скриптах.

Ну да, обсуждать то ни кто не запрещает.

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

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

Я до сих пор не понимаю у вас аутсорс или вы между отделами заключаете договора и в случае чего подаете в суд на соседний отдел из той же компании?

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

Но при этом «всем известно», что код Бориса правильнее. Я почему про 1С и вспомнил. В версии 7.7 и даже 8.1 они писали в стиле Маркуса. Чинить при необходимости было достаточно легко. Сейчас (последние лет 5) всё переписали в стиле Бориса, к тому же большую часть операций вытащили в фоновые потоки. Отладка и исправление теперь просто кошмарны. Зато «по канонам ООП».

Но при этом «всем известно», что код Бориса правильнее.

Это «известно» тем кто начитался умных книжек про паттерны но не понял зачем все это нужно. Да таких много, в основном неопытные прогеры.

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

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