VGn>>Это называется делегирование ответственности. Ты никогда не сможешь постичь водиночку все детали в крупном корпоративном продукте.

DG>да, поддерживаю
DG>но это не отменяет того факта, что ко всему коду не возникает требований

Давай прекратим бардак.
Ещё раз: у бизнес-заказчика не должно быть требований к коду.
Под твою фразу попадают тоько требования к коду аутсорсеров.
Требования к коду в команде требованиями называть нельзя, потому что "требования" — это бизнес-сущность.
Это можно назвать соглашениями или контрактом.

VGn>> Важен только контракт на разработку.

DG>нет, не только, или даже совсем не только.
DG>т.е. если в контракте не написано, что программа не должна "воровать и убивать (С)", то программа может "воровать и убивать(С)"?

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

VGn>> Реализация контракта — область ответственности исполнителя.

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

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

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

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

DG>что в этом примере надо сделать заказчику:
DG>1. чтобы решить эту ситуацию?
DG>2. что надо принять на будущее, чтобы такой ситуации не возникло в следующий раз?

1. Если возможно в рамках соглашения, надавить материально. Если нет — найти способы заключить доп. соглашение. В любом случае важен результат (в этом случае — качество), а не как оно там написано.
2. Правильно оформлять требования к качеству в ТЗ, ответственность в случае невыполнения требований. Правильно заключать договор на поддержку.

VGn>Ещё раз: у бизнес-заказчика не должно быть требований к коду.

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

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

S>Если у меня нет лишних ресурсов, то откуда я их возьму на code style review? По-прежнему безуспешно намекаю на то, что я не хочу тратить свои ресурсы на погружение в чужую предметную область. Если мне интересно, получу ли я нужный результат, я скорее поговорю с предыдущими кастомерами, и послушаю их фидбек.

Т.е. покупать себе автомобиль вместе с человеком, который в автомобилях разбирается это плохой, неправильный путь?

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

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

Пальцем в такой лозунг можно?

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

ГВ>>Уже теплее. Только опять таки, чтобы интегрировать, нужно очень глубоко разобрать такие высказывания. А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.

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

Надо, но...

То, как это должно быть в норме (-> сопровождается, => то, что получается):

1. [система знаний] + [практика] => [усвоенные знания] -> [метафорическая интерпретация]

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

2. [метафорическая интерпретация] => [?] + [??] => [???]

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

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

S>Вот именно. Зачем задавать вопросы, ответы на которые тебе не помогут? Ну, то есть если чуваки говорят "мы сертифицированы по ISO9001" — то оно конечно хорошо. Но опять же, заметь, вся идея этой сертификации — чтобы её проводил не я, а какие-то другие люди.

ты понимаешь, что ты вот этим утверждениями фактически нарушаешь SRP?
т.е. ты смешиваешь две разные ответственности (функции):
1. заказчику стоит контролировать подрядчика (потому что подрядчик, по умолчанию, старается достичь своих целей, а не целей заказчика)
2. непрофильную стандартную деятельность стоит отдавать на сторону

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

Здравствуйте, Undying, Вы писали:
U>Т.е. покупать себе автомобиль вместе с человеком, который в автомобилях разбирается это плохой, неправильный путь?
Вы путаете разные вещи. Качество сборки автомобиля напрямую влияет на его эксплуатационные характеристики — в частности, частота предстоящего ремонта.
Поэтому при покупке автомобиля с рук мне конечно же крайне важно выяснить — не был ли он реально в аварии, не переставлен ли там двигатель, да и вообще на месте ли все запчасти.
Когда я заказываю код, мне совершенно наплевать, на каком языке он написан — код не подвергается износу; если он один раз протестирован на корректность работы, то он детерминированно продолжит работать корректно всю жизнь.

Если мне делают веб-сайт, то я не полезу в его исходники смотреть, как там всё свёрстано — дивами или таблицами. Я вообще имею право не отличать HTML от HTTP. Зачем мне это?
Мне важнее потребительские характеристики — то есть структура, эстетика наполнения, и скорость загрузки. Если с последним проблемы — это повод потребовать улучшений от подрядчика. А если проблем с этим нет, то совершенно наплевать, какой там CSS применён внутри. Зачем мне забивать себе этим голову?

Вообще, всем людям свойственно преувеличивать важность своей работы. Бухгалтер уверен, что все просто обязаны знать тонкие различия между субсчетами 20-1 и 20-2, в то время как на самом деле всем остальным вообще всё равно, как там что учитывается.
Админ уверен, что нет ничего важнее выбора операционки для гейтвея. Соответственно, программисты тут искренне уверены, что заказчик будет смотреть внутрь вашего кода.
Нет, не будет. Не обязан он это делать. В ваш код никто, кроме peer review и аудиторов, никогда смотреть не будет.

Поэтому все практики насчёт кода — ваше глубоко личное дело. Впутывать сюда заказчиков против их воли не надо. Вас водоканал терзает вопросами типа "правильно ли мы заменили чугунные трубы в магистрали на металлопластиковые?"? Нет? Вот и вы к нему не лезьте со своей атомарностью.

Здравствуйте, DarkGray, Вы писали:
DG>ты понимаешь, что ты вот этим утверждениями фактически нарушаешь SRP?
Нет, не понимаю. Это ты нарушаешь SRP, предполагая, что заказчик будет формулировать требования не только в терминах "что", но и в терминах "как".
DG>т.е. ты смешиваешь две разные ответственности (функции):
DG>1. заказчику стоит контролировать подрядчика (потому что подрядчик, по умолчанию, старается достичь своих целей, а не целей заказчика)
DG>2. непрофильную стандартную деятельность стоит отдавать на сторону
Это вообще какой-то бред написан. Ты извини, но ответственность не формулируется в терминах "стоит"; и ответственности "отдавать деятельность" не может быть.
Причем две стороны одной и той же деятельности (делегация исполнения задачи и контроль её результатов) ты считаешь разными ответственностями.
Разберись с кашей в голове.

хм, мне кажется, что происходит не понимание что такое Заказчик и Разработчик из начального поста.

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

ответственность Заказчика:
1. выбрать Разработчика
2. поставить задачу
3. оплатить работу
4. проконтролировать выполнение
5. воспользоваться результатом

ответственность Разработчика
1. разработать продукт

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

одной из распространенных трансформаций является появление посредника между Заказчиком и Разработчиком обычно он называется Представитель Заказчика
(факторы которые это вызывают уже несколько прозвучали в треде:
1. заказчик не хочет/не умеет/не оптимально разбираться в не своей области,
2. разработчик не хочет передавать контроль над своими действиями заказчику
и т.д.
)

Заказчик => Представитель Заказчика => Разработчик
со следующим распределением ответственностей
Заказчик:
0. Выбрать Представителя Заказчика
1. оплатить работу
2. воспользоваться результатом

Представитель Заказчика
1. Выбрать Разработчика
2. Поставить задачу
3. Проконтролировать выполнение

Разработчик
1. Разработать продукт

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

S>Причем две стороны одной и той же деятельности (делегация исполнения задачи и контроль её результатов) ты считаешь разными ответственностями.

Согласен, что в идеале они должны делаться совместно, и должны являться двумя сторонами одного и того же.

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

S> Ты извини, но ответственность не формулируется в терминах "стоит"; и ответственности "отдавать деятельность" не может быть.

а в каких терминах должна формулироваться ответственность?

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

S>Разберись с кашей в голове.

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

DG>почему? и зачем?
DG>сформулировать можешь? или так было написано в "святой библии программиста" которой ты догматично предан?

Несколько раз всё объяснил. Причём с разных сторон. Читай ветку.

DG>может идти размывание роли Представитель Заказчика, но все это происходит в ранее сформулированной модели.

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

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

DG>а в каких терминах должна формулироваться ответственность?
В терминах "обязан".
Ты уверенно лезешь в дебри. Какая тебе разница, какие еще ответственности есть у заказчика?
В рамках взаимоотношений заказчика и подрядчика вся ответственность заказчика — принять работы, т.е. либо подтвердить соответствие результата заявленным требованиям, либо предъявить список обоснованных претензий. Ну и своевременно провести оплату работ. Ты что, договоров никогда не читал?

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

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

DG>Заказчик и Разработчик — это две крупные роли с довольно сильно отличающимися целями, ответственностями и т.д.
Ну да, всё правильно. И откуда в этой чудной модели возникнет заказчик, который лезет в исходники?

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

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

L>>>Ну, как то ты в крайности бросаешься, честное слово. Смысл в том, что учиться нужно не по лозунгам.
M>>Это очевидно что за лозунгом лежит практика в которой необхобимо разобраться. А вот без лозунга ты можешь и не узнать что такая практика существует , и потратить годы пытаясь сформировать критерии.

L>Т.е. я правильно понял, что лозунг нужен для обучения вида: увидел лозунг — пошёл разбираться, что на самом деле имел в виду агитпроп — обучился новой практике?

Да, на мой взгляд именно эту функцию может выполнять краткий яркий лозунг.

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

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

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

ГВ>Пальцем в такой лозунг можно?

SRP — подходит ?

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

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

Возможно я особо непонятливый и мне ориентиры помогают.