VGn>>1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя. VGn>>2. Требование — бизнес-сущность. Формальный контракт. Работает на уровне заказчик-исполнитель. VGn>>3. Контракт — общая совокупность ограничений, накладываемых на результат работы. Область действия зависит от контекста.
DG>общий термин для обозначения этих 3 сущностей есть?
А зачем? Чтобы устроить привычный бардак? Назови, к примеру, шнягой. Потому как общее обозначение этих сущностей именно шнягой и будет.
A>Лучше всего закрепляют материал упавшие ракеты. Рецепт, проверенный поколениями. Вообще, конечно, отличный подход, если у нас есть 2, может быть 3, лишние ракеты.
Булава падает через раз. Имхо есть где развернуться
VGn>А зачем? Чтобы устроить привычный бардак? Назови, к примеру, шнягой. Потому как общее обозначение этих сущностей именно шнягой и будет.
затем, чтобы с ними можно было работать общим образом.
все эти три правила по сути одно и тоже — это договоренности между двумя сторонами с нюансом (что одной стороне эта договоренность нужна больше, чем другой стороне).
по сути, бардак уже есть при введении определений, т.к. после введения тобой этим терминов возникли следующие вопросы:
1. из-за того, что в п.2 и п.3 явно не упоминается про правило, следует ли что соглашение и контракт не являются правилом?
2. из п.2 и из п.3 следует ли, что требование — тоже самое, что контракт, но формализованный и для области действия заказчик-исполнитель?
3. область действия и уровень это одно и тоже?
4. из-за того, что в п.2 и п.3 явно не упоминается про взаимность, следует ли, что они не взаимные?
DG>>я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах
I>Покажи.
программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)
менеджмент — в чистом виде — решить проблемы в жестких рамках текущей реальности (сроки, ресурсы, ограничения среды и т.д.)
соответственно, с точки зрения программирования все решения, все языки эквиваленты — главное чтобы язык был тьюринг-полным, все остальное не важно.
поэтому говорить о том, что одно решение сложнее, чем другое; что решение работает быстро/медленно; что стоит экономить ресурсы — в терминах программирования не получается, т.к. там такая задача даже не ставится.
...
Назначенный мне баг состоял в том, что тестеры обнаружили конкретную пару дат, которые DateDiff вычитал некорректно. Я глянул в исходный код одного из вспомогательных методов, которые DateDiff вызывает в процессе своих вычислений. Для моих свежевыпущенных из колледжа глаз, это смотрелось примерно так:
if (frob(x) > 0 && blarg(y)) return x – y;
else if (frob(x) < blarg(y) && blah_blah(x) > 0 || blah_de_blah_blah_blah(x,y)) return frob(x) – x + y + 1;
else if…
И так семь раз.
Первым моим побуждением было смело ввязаться в драку и добавить восьмую особую ветку, которая бы чинила баг. Но меня беспокоила моя способность сделать всё как следует при такой сложности. Это уже выглядело как чрезмерно запутанная для своей задачи функция.
...
с точки зрения программирования решение о том, что надо добавить 8 ветку кода — является нормальным
и лишь с той точки зрения — что программировать мы хотим при ограниченных ресурсах (а именно при ограниченных ресурсах своего времени) — появляется задача переписать этот код так, чтобы эта проблема не возникла никогда (больше не потребовала наших ресурсов)
S>По поводу программистской части работы IT высказался вполне определённо — всё сводится к борьбе со сложностью. Я с ним полностью согласен.
есть еще два направления:
1. уменьшению кол-ва потенциальных ошибок (уменьшение мест где потенциально могут быть ошибки)
2. увеличение скорости разработки
и уменьшение сложности часто идет рука об руку с этим направлениями, т.к. уменьшение сложности часто уменьшает кол-во потенциальных ошибок, и увеличивает скорость разработки.
в том самом примере от Липперта его же именно волновало: что по текущему коду непонятно, есть ли ошибка или нет — и именно это побудило переписать код.
DG>по сути, бардак уже есть при введении определений, т.к. после введения тобой этим терминов возникли следующие вопросы: DG>1. из-за того, что в п.2 и п.3 явно не упоминается про правило, следует ли что соглашение и контракт не являются правилом? DG>2. из п.2 и из п.3 следует ли, что требование — тоже самое, что контракт, но формализованный и для области действия заказчик-исполнитель? DG>3. область действия и уровень это одно и тоже? DG>4. из-за того, что в п.2 и п.3 явно не упоминается про взаимность, следует ли, что они не взаимные?
1. Соглашение может и не быть правилом. Контракт относится к результатам, правило к действиям. Зачем им пересекаться?
3. Уровень — дискретное понятие (роль). Область действия — нет. Здесь я учёл твои высказывания о взаимопроникновении областей ответственности. (предвосхищая вопрос: область действия — на что влияет сущность, область ответственности — за что отвечает и на что обращает внимание субъект. Пересечения есть и могут быть тождественными, но смысл разный.)
2. Да, с учётом 3.
4. Что значит "взаимные"? Зачем заказчику ограничения разработчика? На что их накладывать? (гусары молчать!)
Здравствуйте, DarkGray, Вы писали:
DG>>>поэтому я не понимаю утверждение: в договоре будет что-то написано — и это есть правильно, и то что мы хотели. S>>Этого утверждения никто не делал.
DG>как тогда понимать твою фразу? DG>
DG> На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте.
Подменю товарища
Ничто не идеально. Контракт всегда можно изменить по взаимной договорённости, но игнорировать нельзя. С любой стороны.
DG>программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)
DG>менеджмент — в чистом виде — решить проблемы в жестких рамках текущей реальности (сроки, ресурсы, ограничения среды и т.д.)
DG>поэтому говорить о том, что одно решение сложнее, чем другое; что решение работает быстро/медленно; что стоит экономить ресурсы — в терминах программирования не получается, т.к. там такая задача даже не ставится.
Нет. Во всех процессах приоритезацией задач занимается в том числе и разработчик. На основании чего ему это делать?
Здравствуйте, DarkGray, Вы писали:
VGn>>4. Что значит "взаимные"? Зачем заказчику ограничения разработчика? На что их накладывать? (гусары молчать!)
DG>ты это меня спрашиваешь? этот термин употребил ты в п.1.
DG>
DG>1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя
Правильно. Соглашение ведь не обязательно накладывается на результаты, как требования и другие контракты.
Но вообще "взаимное правило" здесь просто подразумевает договорённость практически без влияния на интересы сторон.
VGn>Нет. Во всех процессах приоритезацией задач занимается в том числе и разработчик. На основании чего ему это делать?
явно, что на основание базовых знаний менеджмента (например, что важное, срочное и рисковое — должно идти в первую очередь)
программирование на этот вопрос вообще не отвечает.
I>>Покажи.
DG>программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)
DG>менеджмент — в чистом виде — решить проблемы в жестких рамках текущей реальности (сроки, ресурсы, ограничения среды и т.д.)
Программирование и менеджмент имеют много общего, в том плане, что и то и другое это организацая работы для обеспечения результата.
В одном случае организовывается работа компьютера, в другом — коллектива людей.
DG>с точки зрения программирования решение о том, что надо добавить 8 ветку кода — является нормальным DG>и лишь с той точки зрения — что программировать мы хотим при ограниченных ресурсах (а именно при ограниченных ресурсах своего времени) — появляется задача переписать этот код так, чтобы эта проблема не возникла никогда (больше не потребовала наших ресурсов)
Программирование оно всегда в каких то ограничениъ происходит (бюджет, сроки, качество и тд и тд) и по другому никогда не бывает.
Здравствуйте, DarkGray, Вы писали:
DG>>>deadlock-и обычно упираются в правильную архитектурную декомпозицию, а под это уже больше половины огней заточено S>>Открою тайну: дедлоки обычно упираются в неверный порядок захвата ресурсов. Про это никаких огней нет; архитектурная декомпозиция к этому никакого отношения не имеет.
DG>что делать вот с этим? DG>deadlock будет происходить очень редко при одновременных вызовах c1.F1() и c1.с2.F2()
1. Воспроизводить deadlock.
2. Чинить.
DG>вопросы: DG>1. как такое проконтролировать снаружи?
Ну, конкретно данный код проконтролировать тяжело. DG>2. что именно (какое правило) в этом коде нарушено?
Сходу не скажу. Но мне вообще трудно судить о качестве бессмысленного кода. DG> а) если ответ "дедлоки обычно упираются в неверный порядок захвата ресурсов", то вопрос все тот же самый, как ты собираешься (даже при наличии исходников) контролировать на примере данного исходника, что нет нарушений этого правила. перебором всех трасс выполнения?
Грубо говоря — да. А что, есть какая-то альтернатива? Пойми, даже если конкретно этот код нарушает какие-то из огней, то не составит проблемы написать другой код — идеально соответствующий огням — и всё еще вызывающий дедлоки
DG>его интересует, когда он получит результат. DG>если в ПП число ошибок после внедрения от времени резко не падает, то получается, что заказчик не получает результата, соответственно заказчика начинает волновать — а почему? и что можно сделать?
Можно, конечно, в такой ситуации ввести "прямое президентское правление", но это — уже форсмажор. Весь менеджмент рисков построен на том, чтобы такой ситуации избежать вообще — потому что нет никакой гарантии, что твой прямой микроменеджмент хоть что-то исправить. Заказчиков никогда не волнует "а почему". Заказчиков волнует "ок, дайте мне реальную дату готовности". DG>а один из побочных эффектов side-эффектов что они часто провоцируют ситуацию — когда от исправления в одном месте, начинает отваливаться что-то другое уже в десяти местах
Ты опять смешиваешь программистскую реальность "побочные эффекты затрудняют верификацию программы" с менеджерской "сроки разработки превышены".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
