S>Ты уверенно лезешь в дебри. Какая тебе разница, какие еще ответственности есть у заказчика?
потому что если я не догадаюсь, что хочет заказчик, но не может сказать, то это сделает другой.
и заказчик уйдет к нему.
разве нет?
S>Всё. Никакой ответственности по делегированию чего-то кому-то у заказчика нет. Ну, если только ты не пытаешься сейчас изобрести тезисы курса "Эффективный менеджер".
ответь тогда на следующий вопросы:
1. кто отвечает за то, чтобы все заработало в целом? при условии, что ты утверждаешь, что исполнитель/разработчик отвечает только за то, что написано в договоре?
2. ты понимаешь что в договоре нельзя учесть все нюансы, иначе это фактически будет равно тот код, который должен быть сделать исполнитель/разработчик?
3. как заказчик выполняет п.1., если в договоре все нюансы прописать нельзя по определению, и Заказчик не контролирует ведение работ Исполнителем?
VGn>Ещё раз: у бизнес-заказчика не должно быть требований к коду.
а какие требования у него могут быть?
у него может быть требование к платформе на которой это должно быть реализовано?
может ли заказчик требовать, чтобы ему для тестирования предоставили ПП как "белый ящик", а не как "черный ящик"?
VGn>Под твою фразу попадают тоько требования к коду аутсорсеров. VGn>Требования к коду в команде требованиями называть нельзя, потому что "требования" — это бизнес-сущность. VGn>Это можно назвать соглашениями или контрактом.
чем отличаются друг от друга:
1. соглашение
2. требование
3. контракт
?
S>Ну да, всё правильно. И откуда в этой чудной модели возникнет заказчик, который лезет в исходники?
из пункта "проконтролировать выполнение".
и из того факта, что ряд вещей очень плохо контролируются по результату (методом "черного ящика"), и намного лучше контролируются при наличие доступа внутрь (методом "белого ящика")
например,
1. требование, что ПП устойчиво работает при многопоточном выполнении — очень тяжело контролируется методом "черного ящика".
2. требование, что программа не имеет ошибок (или имеет кол-во ошибок меньше заданного на кол-во функциональный точек) — тоже методом "черного ящика" контролируется достаточно трудоемко.
3. сроки и бюджет частично можно контролировать через черный ящик, но затруднительно — спиральная модель помогает, но не спасает от наблюдения, что первые 80% делаются за 80% бюджета, а оставшиеся 20% за другие 80% бюджета.
4. контроль по черному ящику не помогает от "посадки на иглу", когда после внедрения первой версии начинает искусственно вздуваться стоимость последующих работ.
ГВ>На самом деле, такие плакаты всегда дополняют "прокачивание" мозгов
каким образом должно происходить, по твоему, "прокачивание" мозгов разработчиков?
ты, вроде, периодически упоминал что это должен делать институт, но, имхо, это тупиковый путь — потому что рабочий стаж как минимум 25 лет, а институт в лучшем случае может дать "прокачку" на пару лет вперед, в худшем (как например сейчас) — лет на двадцать назад.
VGn>>Ещё раз: у бизнес-заказчика не должно быть требований к коду.
DG>а какие требования у него могут быть? DG>у него может быть требование к платформе на которой это должно быть реализовано? DG>может ли заказчик требовать, чтобы ему для тестирования предоставили ПП как "белый ящик", а не как "черный ящик"?
Заказчик может требовать, чтобы разработчики стояли на голове и пели гимн Канады. Как договоритесь.
VGn>>Под твою фразу попадают тоько требования к коду аутсорсеров. VGn>>Требования к коду в команде требованиями называть нельзя, потому что "требования" — это бизнес-сущность. VGn>>Это можно назвать соглашениями или контрактом.
DG>чем отличаются друг от друга: DG>1. соглашение DG>2. требование DG>3. контракт DG>?
1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя.
2. Требование — бизнес-сущность. Формальный контракт. Работает на уровне заказчик-исполнитель.
3. Контракт — общая совокупность ограничений, накладываемых на результат работы. Область действия зависит от контекста.
?. Регламенты, стандарты и т.д.
DG>2. ты понимаешь что в договоре нельзя учесть все нюансы, иначе это фактически будет равно тот код, который должен быть сделать исполнитель/разработчик?
Ты не видел ТЗ на военную технику
За что получают деньги те толпы людей вокруг разработчиков?
Здравствуйте, DarkGray, Вы писали: DG>из пункта "проконтролировать выполнение". DG>и из того факта, что ряд вещей очень плохо контролируются по результату (методом "черного ящика"), и намного лучше контролируются при наличие доступа внутрь (методом "белого ящика")
Это всё необоснованные углубления в дебри. На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте. Есть требования — есть их проверка. Дальнейшее, вообще говоря, излишество. DG>1. требование, что ПП устойчиво работает при многопоточном выполнении — очень тяжело контролируется методом "черного ящика".
Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил? DG>2. требование, что программа не имеет ошибок (или имеет кол-во ошибок меньше заданного на кол-во функциональный точек) — тоже методом "черного ящика" контролируется достаточно трудоемко.
Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?
Выписанные тобой огни хоть как-то влияют из твоего списка исключительно на выполнение бюджетов. Но я позволю себе в очередной раз напомнить, что бюджеты — это не программистская епархия. Вопросам выполнения бюджетов посвящены совершенно отдельные "огни менеджмента", их преподают на post-graduate курсах.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>потому что если я не догадаюсь, что хочет заказчик, но не может сказать, то это сделает другой. DG>и заказчик уйдет к нему. DG>разве нет?
В данном контексте это совершенно неважно. Ты действительно хочешь озаглавить список огней "как сделать так, чтобы заказчик не ушёл к другому"?
Это совершенно отдельный вид деятельности. Ей занимаются sales managers, и делают они это совершенно не так, как ты тут себе фантазируешь.
DG>ответь тогда на следующий вопросы: DG>1. кто отвечает за то, чтобы все заработало в целом? при условии, что ты утверждаешь, что исполнитель/разработчик отвечает только за то, что написано в договоре?
Что такое "всё" и что такое "в целом"? DG>2. ты понимаешь что в договоре нельзя учесть все нюансы, иначе это фактически будет равно тот код, который должен быть сделать исполнитель/разработчик?
Понимаю. А какое отношение это имеет к обсуждаемой теме? Мы же говорим об ответственностях "по понятиям", а не "по документам". Заказчик обязан как можно лучше объяснить задачу, и обязан проверить, соответствует ли результат его задаче. Исполнитель обязан как можно лучше понять задачу, и решить именно её.
В этом уравнении нигде не фигурируют исходники — за исключением уже упомянутого вырожденного случая аутсорсинга, где покупается не решение, а инструмент.
DG>3. как заказчик выполняет п.1., если в договоре все нюансы прописать нельзя по определению, и Заказчик не контролирует ведение работ Исполнителем?
Контролирует, но не ведение, а результат.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали: DG>из этого я понял, что у тебя каши в голове нет, поэтому ты прямо сейчас готов системно изложить свое видение по обсуждаемой теме?
Не вижу смысла. Я вообще не до конца понимаю, что именно вам хочется обсудить.
По поводу программистской части работы IT высказался вполне определённо — всё сводится к борьбе со сложностью. Я с ним полностью согласен.
Всё остальное, что ты тут фантазируешь, относится к области менеджмента, и вообще говоря никак к программированию не относится.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Это всё необоснованные углубления в дебри. На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте. Есть требования — есть их проверка. Дальнейшее, вообще говоря, излишество.
это формальный подход
а формальный подход работает только если мы сначала договорились как должно быть, а потом эту договоренность формализовали.
а мы сейчас находимся на стадии когда пытаемся договорится что должно быть из позиции win-win
поэтому я не понимаю утверждение: в договоре будет что-то написано — и это есть правильно, и то что мы хотели.
DG>>1. требование, что ПП устойчиво работает при многопоточном выполнении — очень тяжело контролируется методом "черного ящика". S>Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?
как минимум в п.8 и п. 10
8. Атомарность
а) Tell, don't ask
10. Программа всегда(даже после ошибки) должна стремиться находиться в корректном состоянии
a) транзакционность (изменение состояния делается только в самом конце)
b) безопасность исключений
deadlock-и обычно упираются в правильную архитектурную декомпозицию, а под это уже больше половины огней заточено
DG>>2. требование, что программа не имеет ошибок (или имеет кол-во ошибок меньше заданного на кол-во функциональный точек) — тоже методом "черного ящика" контролируется достаточно трудоемко. S>Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?
все огни направлены на уменьшение кода и соответственно на уменьшение кол-ва ошибок
как пример
25. a) должно быть как можно меньше side-effect-ов
выполнения этого правила уменьшает кол-во ошибок в коде, который эту функцию использует.
S>Всё остальное, что ты тут фантазируешь, относится к области менеджмента, и вообще говоря никак к программированию не относится.
зачем ты хочешь разделить менеджмент и программирование?
получить упрощение задачи? а ты уверен, что при таком упрощении не потеряешь кучу всего важного?
я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах
VGn>1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя. VGn>2. Требование — бизнес-сущность. Формальный контракт. Работает на уровне заказчик-исполнитель. VGn>3. Контракт — общая совокупность ограничений, накладываемых на результат работы. Область действия зависит от контекста.
общий термин для обозначения этих 3 сущностей есть?
S>>Всё остальное, что ты тут фантазируешь, относится к области менеджмента, и вообще говоря никак к программированию не относится. DG>зачем ты хочешь разделить менеджмент и программирование?
Я тоже люблю винигрет, но только как салат.
DG>я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах
Здравствуйте, DarkGray, Вы писали:
DG>поэтому я не понимаю утверждение: в договоре будет что-то написано — и это есть правильно, и то что мы хотели.
Этого утверждения никто не делал.
DG>как минимум в п.8 и п. 10 DG>
DG>8. Атомарность
DG> а) Tell, don't ask
Чем это помешает проверке результата?
DG>10. Программа всегда(даже после ошибки) должна стремиться находиться в корректном состоянии
DG> a) транзакционность (изменение состояния делается только в самом конце)
DG> b) безопасность исключений
Чем это помешает проверке результата? DG>deadlock-и обычно упираются в правильную архитектурную декомпозицию, а под это уже больше половины огней заточено
Открою тайну: дедлоки обычно упираются в неверный порядок захвата ресурсов. Про это никаких огней нет; архитектурная декомпозиция к этому никакого отношения не имеет.
DG>все огни направлены на уменьшение кода
Это не так. Перечитай еще раз огни и прикинь, какие направлены на уменьшение, какие на увеличение, а какие индифферентны к размеру кода.
DG>и соответственно на уменьшение кол-ва ошибок DG>как пример DG>
DG>25. a) должно быть как можно меньше side-effect-ов
DG>выполнения этого правила уменьшает кол-во ошибок в коде, который эту функцию использует.
Во-первых, выполнение этого правила ничего не уменьшает. Контрольный вопрос: пусть в коде, вызывающем функцию с side-effects, было 0 ошибок. Сколько ошибок станет в нём после того, как side-effects будут убраны?
Во-вторых, какое отношение это имеет к приёмке кода заказчиком? Намекну на всякий случай, что заказчика не интересует наличие либо отсутствие побочных эффектов внутри кода. Заказчика интересует наличие заказанных прямых эффектов и отсутствие незаказанных.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10
Откуда это взялось ? Почему не (int)((6-8 + 3-10*6-8 + 3 — 8 )/2*0.0001) == 0 ?
Здравствуйте, Геннадий Васильев, Вы писали:
DG>>т.е. учили стандартным ремесленным способом от мастера к подмастере? когда мастер подает пример подмастере, и пару лет личным примером показывает как надо? ГВ>Два, может быть — три раза. Лучше всего закрепляют материал собственные отбитые пальцы. Рецепт, проверенный поколениями.
Лучше всего закрепляют материал упавшие ракеты. Рецепт, проверенный поколениями. Вообще, конечно, отличный подход, если у нас есть 2, может быть 3, лишние ракеты.
DG>>deadlock-и обычно упираются в правильную архитектурную декомпозицию, а под это уже больше половины огней заточено S>Открою тайну: дедлоки обычно упираются в неверный порядок захвата ресурсов. Про это никаких огней нет; архитектурная декомпозиция к этому никакого отношения не имеет.
что делать вот с этим?
class C1
{
public C1()
{
this.c2 = new C2(this);
}
public readonly C2 c2;
readonly object sync = new object();
public void F1()
{
lock(sync)
{
this.X = 5;
this.Y = 10;
}
}
public int X
{
get {lock(sync){return _X;}}
set {lock(sync){_X = value;}}
}
int _X;
public int Y
{
get {lock(sync) {return c2.Y;}}
set {lock(sync) {c2.Y = value;}}
}
}
class C2
{
public C2(C1 c1) {this.C1 = c1;}
readonly C1 c1;
readonly object sync = new object();
public int Y
{
get {lock(sync){return _Y;}}
set {lock(sync){_Y = value;}}
}
int _Y;
public void F2()
{
lock(sync)
{
this.Y = c1.X + 10;
}
}
}
deadlock будет происходить очень редко при одновременных вызовах c1.F1() и c1.с2.F2()
вопросы:
1. как такое проконтролировать снаружи?
2. что именно (какое правило) в этом коде нарушено?
а) если ответ "дедлоки обычно упираются в неверный порядок захвата ресурсов", то вопрос все тот же самый, как ты собираешься (даже при наличии исходников) контролировать на примере данного исходника, что нет нарушений этого правила. перебором всех трасс выполнения?
DG>>все огни направлены на уменьшение кода S>Это не так. Перечитай еще раз огни и прикинь, какие направлены на уменьшение, какие на увеличение, а какие индифферентны к размеру кода.
переформулирую: все огни направлены на уменьшение сложности (я кол-во кода (если он хороший) считаю по кол-ву сложности, поэтому для меня они синонимы)
S>Во-первых, выполнение этого правила ничего не уменьшает. Контрольный вопрос: пусть в коде, вызывающем функцию с side-effects, было 0 ошибок. Сколько ошибок станет в нём после того, как side-effects будут убраны?
хз, кстати, т.к. этот код мог уже завязываться на эти side-эффекты, что и приводит нас к проблеме, что бывают ПП построенных так, что при исправление ошибок число ошибок оставшихся(включая внесённые исправлениями) в целом не уменьшается.
S>Во-вторых, какое отношение это имеет к приёмке кода заказчиком? Намекну на всякий случай, что заказчика не интересует наличие либо отсутствие побочных эффектов внутри кода. Заказчика интересует наличие заказанных прямых эффектов и отсутствие незаказанных.
его интересует, когда он получит результат.
если в ПП число ошибок после внедрения от времени резко не падает, то получается, что заказчик не получает результата, соответственно заказчика начинает волновать — а почему? и что можно сделать?
а один из побочных эффектов side-эффектов что они часто провоцируют ситуацию — когда от исправления в одном месте, начинает отваливаться что-то другое уже в десяти местах
