Комментарии 36
«Поэтому аналитику стоит описывать алгоритм настолько полно, насколько это важно в плане бизнес-логики, второстепенные проверки программист сам обязан предусмотреть в коде. [...] В алгоритме указана всего одна проверка, но очевидно, что при написании кода метода программист должен реализовать проверки на входные параметры; выбросить исключение, если текущий пользователь не определен и т.д. „
А кому это очевидно? Например, почему если пользователь не определен, должно быть исключение, а не сообщение об ошибке с перенаправлением на механизм входа в систему?
Собственно, меня в этом подходе смущает “программист _обязан_». У нас в таких случаях четко предупреждают «поведение системы в случаях, не описанных в требованиях, _не определено_».
А кому это очевидно? Например, почему если пользователь не определен, должно быть исключение, а не сообщение об ошибке с перенаправлением на механизм входа в систему?
Собственно, меня в этом подходе смущает “программист _обязан_». У нас в таких случаях четко предупреждают «поведение системы в случаях, не описанных в требованиях, _не определено_».
Например, почему если пользователь не определен, должно быть исключение, а не сообщение об ошибке с перенаправлением на механизм входа в систему?
Я согласен, что тут возможны варианты. Обычно это определяется архитектурой приложения. Это всего лишь пример.
“программист _обязан_». У нас в таких случаях четко предупреждают «поведение системы в случаях, не описанных в требованиях, _не определено_».
Из того, что оно не определено (в требованиях), не следует, что программист его не должен учесть. А он должен. Надеюсь, не будем отрицать необходимость проверок на корректность входных параметров -)?
>> Из того, что оно не определено (в требованиях), не следует, что программист его не должен учесть.
Под «не определено» подразумевается «любое поведение системы, которое последует — корректно».
>> Надеюсь, не будем отрицать необходимость проверок на корректность входных параметров -)?
Будем. Вы путаете правила хорошего тона программиста с требованиями. Понятие «корректность входных параметров» — очень широкое. Например, надо ли проверять, что цена не отрицательная? А что она не ноль? Вот и с null-значениями то же самое — _правила хорошего тона_ рекомендуют проверить, что обязательное значение присутствует, как можно раньше и явно, чтобы было легче отлаживать систему, но для пользователя разницы нет: и так, и так будет техническая ошибка — до тех пор, пока это правило не будет вынесено в бизнес и не описано явно.
Самая страшная вещь в требованиях — это умолчания.
Под «не определено» подразумевается «любое поведение системы, которое последует — корректно».
>> Надеюсь, не будем отрицать необходимость проверок на корректность входных параметров -)?
Будем. Вы путаете правила хорошего тона программиста с требованиями. Понятие «корректность входных параметров» — очень широкое. Например, надо ли проверять, что цена не отрицательная? А что она не ноль? Вот и с null-значениями то же самое — _правила хорошего тона_ рекомендуют проверить, что обязательное значение присутствует, как можно раньше и явно, чтобы было легче отлаживать систему, но для пользователя разницы нет: и так, и так будет техническая ошибка — до тех пор, пока это правило не будет вынесено в бизнес и не описано явно.
Самая страшная вещь в требованиях — это умолчания.
Будем.
Зря. При делении на 0 система накроется, а могла бы выдать человеческую ошибку.
Вы путаете правила хорошего тона программиста с требованиями.
Я не путаю. Я говорю о том, что невозможно все отразить в требованиях (или это потребует неадекватно больших трудозатрат аналитика). Аналитик решает, что важно (например, может решть, что — из вашего примера — проверка на неотрицательную цену — очень важна), а что не важно. И важные проверки описывает.
Но у программиста — помимо требований от аналитика — есть еще и опыт, и требования по архитектуре (от архитектора / ведущего разработчика / менеджера проекта).
… _правила хорошего тона_… чтобы было легче отлаживать систему
Это не хороший тон, а обязанность программиста. И дело не в отладке, а в том, что (1) система не должна падать и (2) пользователю надо выдать корректную ошибку.
для пользователя разницы нет
Есть — и очень большая: получить сообщение runtime на английском или user-fiendly с описанием того, что происходит в ему понятных бизнес-терминах.
>> При делении на 0 система накроется, а могла бы выдать человеческую ошибку.
И тут мы немедленно упираемся в вопрос «что такое человеческая ошибка».
>> И важные проверки описывает.
Именно. Вы же сами решаете, что остальные фрагменты поведения системы _не важны_, иначе бы их определил аналитик. Вот система себя и ведет, как придется.
>> И дело не в отладке, а в том, что (1) система не должна падать и (2) пользователю надо выдать корректную ошибку.
Утверждение «система не должна падать» (а) недостижимо и (б) противоречит принципу fail early. Я искренне убежден в том, что столкнувшись с непредусмотренной ситуацией система должна упасть, чтобы не усугублять положение.
>> Есть — и очень большая: получить сообщение runtime на английском или user-fiendly с описанием того, что происходит в ему понятных бизнес-терминах.
Чтобы получить описание в понятных бизнес-терминах, ошибка должна быть описана в бизнес-терминах. Бизнес-терминологией владеет аналитик — вернулись к началу.
Понимаете ли, для пользователя сообщение «Текущий пользователь не определен» ничем не лучше «NullReferenceException» — он в обоих случаях не знает, что делать дальше.
И тут мы немедленно упираемся в вопрос «что такое человеческая ошибка».
>> И важные проверки описывает.
Именно. Вы же сами решаете, что остальные фрагменты поведения системы _не важны_, иначе бы их определил аналитик. Вот система себя и ведет, как придется.
>> И дело не в отладке, а в том, что (1) система не должна падать и (2) пользователю надо выдать корректную ошибку.
Утверждение «система не должна падать» (а) недостижимо и (б) противоречит принципу fail early. Я искренне убежден в том, что столкнувшись с непредусмотренной ситуацией система должна упасть, чтобы не усугублять положение.
>> Есть — и очень большая: получить сообщение runtime на английском или user-fiendly с описанием того, что происходит в ему понятных бизнес-терминах.
Чтобы получить описание в понятных бизнес-терминах, ошибка должна быть описана в бизнес-терминах. Бизнес-терминологией владеет аналитик — вернулись к началу.
Понимаете ли, для пользователя сообщение «Текущий пользователь не определен» ничем не лучше «NullReferenceException» — он в обоих случаях не знает, что делать дальше.
кстати, в некоторых случаях — 0 также вполне корректная цифра выражения стоимости, например, в финансовых системах. Столкнулись с таким, когда добавил в чат проверку на пустое сообщение вида empty() — а там 0 не пропускает, хотя на вопрос о стоимости актива ответ 0 часто полностью корректен (как и отрицательные числа также)
Вот система себя и ведет, как придется.
Она так ведет себя не потому, что аналитик не описал, а потому, что программисту все равно. Если программист считает себя чистым кодером, то ОК, просто не берем его в команду. Но если ему не все равно — то он участвует в формировании поведения системы — удобного для пользователя.
Я искренне убежден в том, что столкнувшись с непредусмотренной ситуацией система должна упасть, чтобы не усугублять положение.
Вы смотрите на систему с т.з. отладки, а не использования ее в реальных условиях (для чего она предназначена). Для систем класса предприятия (о них речь в статье) падение — тяжкий грех. Из того, что это недостижимо не следует, что не надо к этому стремиться.
Бизнес-терминологией владеет аналитик — вернулись к началу.
Вовсе нет. Я как раз писал, что бизнес-терминологией должен владеть и программист и тестировщик.
«Текущий пользователь не определен» ничем не лучше «NullReferenceException» — он в обоих случаях не знает, что делать дальше.
С т.з. программиста — да, все равно. Но с т.з. пользователя — нет. Даже ели брать такой экстремальный пример — то «тон делает музыку». С кем вам приятнее разговаривать: с тем, кто орет без повода, пусть даже говорит умные вещи, или с тем, кто разговаривает спокойно? Помните классический пример про коды ошибок в IBM (когда надо было лезть в мануал, чтобы найти описание ошибки, чей код показался на экране)?
Также я говорю об общих принципах — в 80% случаях ошибки можно сформулировать в бизнес-терминах. Еще 10% пользователь скорее всего не увидит никогда (они не возникнут — проверки не сработают — как раз случай с отсутствием текущего пользователя), еще 10% — надо стараться сформулировать по-человечески.
Еще раз: программист — не просто кодер — он участник команды по созданию системы. Ему нужны требования — ок, аналитик их дает. Но и программист должен думать, как лучше сделать для пользователя. В каких-то случаях нужно что-то уточнять у аналитика, в каких-то — полагаться на разработанные архитектурные и т.п. принципы, в каких-то — додумывать самому.
>> Но если ему не все равно — то он участвует в формировании поведения системы — удобного для пользователя.
Программист не знает, как удобно пользователю. Откуда?
>> Для систем класса предприятия (о них речь в статье) падение — тяжкий грех.
Нет. Для системы класса предприятия тяжкий грех — это потеря данных и отказ в обслуживании. А падение, которое не влияет на остальные операции — не грех, а нормальная, регулярно встречающаяся ситуация.
>> Но и программист должен думать, как лучше сделать для пользователя.
Это немножко не входит в круг его навыков (если входит — то он уже не [только] программист). Поэтому в его суждениях по этому поводу могут быть ошибки, и они, что самое важное, ненаказуемы. Вы хотите, чтобы программист брал на себя часть аналитической работы. Само по себе это не вполне допустимо, только вы должны понимать, что в этот момент вы просите человека выполнять две конфликтующих обязанности. Результат будет соответствующим.
И да, то, о чем вы говорите, описывается банальным требованием «все ошибки, достигающие пользователя, должны быть сформулированы по-русски». После этого умолчание из требований исчезает, а ожидаемое поведение становится очевидным.
Программист не знает, как удобно пользователю. Откуда?
>> Для систем класса предприятия (о них речь в статье) падение — тяжкий грех.
Нет. Для системы класса предприятия тяжкий грех — это потеря данных и отказ в обслуживании. А падение, которое не влияет на остальные операции — не грех, а нормальная, регулярно встречающаяся ситуация.
>> Но и программист должен думать, как лучше сделать для пользователя.
Это немножко не входит в круг его навыков (если входит — то он уже не [только] программист). Поэтому в его суждениях по этому поводу могут быть ошибки, и они, что самое важное, ненаказуемы. Вы хотите, чтобы программист брал на себя часть аналитической работы. Само по себе это не вполне допустимо, только вы должны понимать, что в этот момент вы просите человека выполнять две конфликтующих обязанности. Результат будет соответствующим.
И да, то, о чем вы говорите, описывается банальным требованием «все ошибки, достигающие пользователя, должны быть сформулированы по-русски». После этого умолчание из требований исчезает, а ожидаемое поведение становится очевидным.
Извините, задумался в процессе предложения. «Само по себе это вполне допустимо» («не» — лишнее).
Программист не знает, как удобно пользователю. Откуда?
Это лукавство, желание уйти в свой мирок кодирования и отвечать лишь за применение шаблонов. Программист разве сам не пользуется ПО? О, сколько раз я слышал, что что-то в ReSharper сделано не так -). Ну, а кроме того, общие принципы работы разрабатываемой системы разве не всей командой обсуждаются?
А падение, которое не влияет на остальные операции
Ну, тут просто у нас терминология не совпала. Я, как программист С++, считаю, что падение = отказ в обслуживании. Для вас (наверно, Java/C#) падение — это исключение, попавшееся на глаза пользователю.
в его суждениях по этому поводу могут быть ошибки, и они, что самое важное, ненаказуемы
Я никого не хочу наказывать. Я пытаюсь объяснить, что ПО делается всей командой. И нет идеальной ситуации, когда аналитик описал на словах целиком алгоритм, а программисту надо только перевести его на язык программирования. И, кстати, хорошо, что такой ситуации нет (поскольку возникает синергия).
А разве в рамках вашей парадигмы не конфликтует написание unit-тестов с реализацией методов?
В рамках моей — нет, поскольку программист — не кодировщик, а «человек думающий» -), т.е. понимает то, что кодирует с т.з. бизнеса.
«все ошибки, достигающие пользователя, должны быть сформулированы по-русски»
Не, это упрощение. Я не о языке (кто сказал, что мы только для России пишем? -) — я о бизнес-смысле, заложенном в сообщении об ошибке (см выше — где я писал о 80-10-10).
>> Это лукавство, желание уйти в свой мирок кодирования и отвечать лишь за применение шаблонов. Программист разве сам не пользуется ПО?
Пользуется. Но ПО, которое удобно программисту, далеко не всегда удобно бизнес-пользователю. В обратную сторону, кстати, тоже работает.
>> Ну, а кроме того, общие принципы работы разрабатываемой системы разве не всей командой обсуждаются?
Далеко не обязательно. И уж до программистов (которые исполнители) тем более редко доходит.
>> Я, как программист С++, считаю, что падение = отказ в обслуживании. Для вас (наверно, Java/C#) падение — это исключение, попавшееся на глаза пользователю.
Для меня падение — это когда система (или ее конкретный модуль) была полностью остановлена и перезапущена начисто.
>> Я пытаюсь объяснить, что ПО делается всей командой.
ПО действительно делается всей командой. Просто важно понимать цели каждого члена этой команды.
>> А разве в рамках вашей парадигмы не конфликтует написание unit-тестов с реализацией методов?
Нет, не конфликтует. А вот функциональное тестирование с разработкой — уже конфликтуют.
>> программист — не кодировщик, а «человек думающий» -), т.е. понимает то, что кодирует с т.з. бизнеса.
Зачем тогда вобще нужны аналитики?
>> Не, это упрощение. Я не о языке (кто сказал, что мы только для России пишем? -) — я о бизнес-смысле, заложенном в сообщении об ошибке (см выше — где я писал о 80-10-10).
Значит, переформулируйте требование. Важно, чтобы оно было явно озвучено.
Пользуется. Но ПО, которое удобно программисту, далеко не всегда удобно бизнес-пользователю. В обратную сторону, кстати, тоже работает.
>> Ну, а кроме того, общие принципы работы разрабатываемой системы разве не всей командой обсуждаются?
Далеко не обязательно. И уж до программистов (которые исполнители) тем более редко доходит.
>> Я, как программист С++, считаю, что падение = отказ в обслуживании. Для вас (наверно, Java/C#) падение — это исключение, попавшееся на глаза пользователю.
Для меня падение — это когда система (или ее конкретный модуль) была полностью остановлена и перезапущена начисто.
>> Я пытаюсь объяснить, что ПО делается всей командой.
ПО действительно делается всей командой. Просто важно понимать цели каждого члена этой команды.
>> А разве в рамках вашей парадигмы не конфликтует написание unit-тестов с реализацией методов?
Нет, не конфликтует. А вот функциональное тестирование с разработкой — уже конфликтуют.
>> программист — не кодировщик, а «человек думающий» -), т.е. понимает то, что кодирует с т.з. бизнеса.
Зачем тогда вобще нужны аналитики?
>> Не, это упрощение. Я не о языке (кто сказал, что мы только для России пишем? -) — я о бизнес-смысле, заложенном в сообщении об ошибке (см выше — где я писал о 80-10-10).
Значит, переформулируйте требование. Важно, чтобы оно было явно озвучено.
И уж до программистов (которые исполнители) тем более редко доходит.
По-моему у нас именно в этом месте основное противоречие -). При написании ПО возможны разные парадигмы. Я придерживаюсь той, кот говорит, что программист — не простой кодировщик. Кроме того мой опыт показывает, что лучшие программисты — это не простые кодировщики. Но, если верно обратное (программист=кодировщик) — то соглашусь, что на плечи аналитика ложатся и задачи описания низкоуровневых проверок (с чем он, скорее всего, не справится).
Значит, переформулируйте требование. Важно, чтобы оно было явно озвучено.
Требование очень простое — ошибка должна быть сформулирована в бизнес-понятиях и быть понятна пользователю. У нас, кстати, это было записано.
Вообще, интересно, что все то, что мы обсуждаем (замечу, что не это является основным смыслом статьи), я усиленно доносил до нашей команды программистов в первые три месяца разработки. В результате народ, хоть и скрепя сердцем, но согласился. -)
К сожалению, ваши формулировки, особенно по части программиста, действительно противоречивы и сильно зависят от того, что вы делаете и как устроена команда.
С одной стороны, у вас может работать Петя. Петя ничего не понимает в бизнес-поцессах заказчика, зато умеет решать алгоритмические задачи со множеством параметров и мысль «объектами». В таком случае, вашему аналитику придется донести до Пети все возможные низкоуровневые проверки, поскольку значение цены null для Пети катастрофой не является.
С другой стороны, в команде может быть Вася. В отличие от Пети, Вася представяет себе как рабоает бизнес заказчика и может хотя бы примерно изобразить если не IDEF-диаграмму процессов, то хотя бы их блок-схемы в Visio. Васе уже не нужен полный перечень низкоуровневых проверок, Вася о них в курсе или докагывается, где они могут быть нужны — если что, спросит.
Нужно заметить, что процесс превращения Пети в Васю возможен, но, как правило, только ненасильственным путем: то есть если Пете станет интересно что происходит на несколько уровней выше — он сможет мутировать в Васю.
Аналогично с падениями системы и прочими нюансами: нельзя просто ждать, что программист по-умолчанию понимает что нужно заказчику.
Отчати эта разница — именно то, что оправдывает использование ГОСТ 34 в качестве методологии при разработке масштабных ИС: ГОСТ (в случае прямого следования ему) обязывает архитектора системы и аналитика четко обозначать максимальное количество низкоуровневых проверок и деталей. Таким образом Петя получает полныц набор информации, а Вася может прочитать часть документации «наискосок» и ему этого будет достаточно.
С одной стороны, у вас может работать Петя. Петя ничего не понимает в бизнес-поцессах заказчика, зато умеет решать алгоритмические задачи со множеством параметров и мысль «объектами». В таком случае, вашему аналитику придется донести до Пети все возможные низкоуровневые проверки, поскольку значение цены null для Пети катастрофой не является.
С другой стороны, в команде может быть Вася. В отличие от Пети, Вася представяет себе как рабоает бизнес заказчика и может хотя бы примерно изобразить если не IDEF-диаграмму процессов, то хотя бы их блок-схемы в Visio. Васе уже не нужен полный перечень низкоуровневых проверок, Вася о них в курсе или докагывается, где они могут быть нужны — если что, спросит.
Нужно заметить, что процесс превращения Пети в Васю возможен, но, как правило, только ненасильственным путем: то есть если Пете станет интересно что происходит на несколько уровней выше — он сможет мутировать в Васю.
Аналогично с падениями системы и прочими нюансами: нельзя просто ждать, что программист по-умолчанию понимает что нужно заказчику.
Отчати эта разница — именно то, что оправдывает использование ГОСТ 34 в качестве методологии при разработке масштабных ИС: ГОСТ (в случае прямого следования ему) обязывает архитектора системы и аналитика четко обозначать максимальное количество низкоуровневых проверок и деталей. Таким образом Петя получает полныц набор информации, а Вася может прочитать часть документации «наискосок» и ему этого будет достаточно.
обязывает архитектора системы и аналитика
Согласен. Я во втором комментарии писал, что "… у программиста — помимо требований от аналитика — есть еще и опыт, и требования по архитектуре (от архитектора / ведущего разработчика / менеджера проекта)."
Кстати, похоже, что на вашем проекте Петя не нужен — ведь аналитик все алгоритмы уже описал. -) Я исхожу из того, что уж если аналитик должен описать все низкоуровневые проверки, то алгоритмы-то уж он точно должен описать.
Если серьезно, то в реальности Петя будет реализовывать системную архитектуру, а Вася — бизнес.
Если серьезно, то в реальности Петя будет реализовывать системную архитектуру, а Вася — бизнес.
стати, похоже, что на вашем проекте Петя не нужен — ведь аналитик все алгоритмы уже описал
а вы не задумывались что на ПК и на часах android будут совершенно разные алгоритмы? Например при работе с графикой.
Я о том, что есть ограничение ресурсов. На ПК вам доступно 90Гбайт оперативки, а на часах всего 8Мбайт. А станок ЧПУ ест не более 200Кбайт.
Ваш аналитик будет описывать все алгоритмы под всё железо в мире?
и на часах android
Могу только процитировать статью: «Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.»
Если отвечать конкретно, то в жизни, конечно, все возможно, но скорее всего реализация «того же самого» на часах потребует изменений на системном уровне приложения, а не в алгоритме обработки бизнес-данных. Вот на системном Петя и будет активно работать.
т.е. под алгоритмами вы подразумеваете только обработку бизнес-данных и ни каких других алгоритмов?
Например валидация номеров телефонов на чьи плечи падает?
Не хочу общими фразами задавать вопросы, будем по конкретике.
+380… или 810380...? Тут уже не совсем бизнес логика, это вопросы совместимости оборудования к которому будет привязана ваша CRM. Стоит это описывать в Аналитике или программист по умолчанию сам догадается (и должен ли программист знать ГОСТ по зональности номеров телефонов?)
Или возьмем международный стандарт, но аналоговые линии при принятии на вход "+" просто выдадут исключение (старое оборудование и т.д.)
Например валидация номеров телефонов на чьи плечи падает?
Не хочу общими фразами задавать вопросы, будем по конкретике.
+380… или 810380...? Тут уже не совсем бизнес логика, это вопросы совместимости оборудования к которому будет привязана ваша CRM. Стоит это описывать в Аналитике или программист по умолчанию сам догадается (и должен ли программист знать ГОСТ по зональности номеров телефонов?)
Или возьмем международный стандарт, но аналоговые линии при принятии на вход "+" просто выдадут исключение (старое оборудование и т.д.)
>> Я придерживаюсь той, кот говорит, что программист — не простой кодировщик. Кроме того мой опыт показывает, что лучшие программисты — это не простые кодировщики.
У нас с вами противоречие в том, как понимать термин «простой кодировщик». Я вот считаю, что чтобы выйти за уровень «простого кодировщика», нужно начать принимать технические решения. А вы — что нужно начать принимать бизнес-решения.
>> на плечи аналитика ложатся и задачи описания низкоуровневых проверок
Вы считаете, что поведение системы для определенного и неопределенного текущего пользователя — это низкоуровневая проверка?
>> Требование очень простое — ошибка должна быть сформулирована в бизнес-понятиях и быть понятна пользователю. У нас, кстати, это было записано.
Вот с момента, как оно записано, у меня больше нет вопросов. Я против _неявных_ требований.
И да, для меня признак хорошего программиста — это то, что как только он видит потенциальное неописанное требование — например, поведение системы при ошибке — он не игнорирует его, и не делает тихо, как считает лучше, а идет к постановщику задачи.
У нас с вами противоречие в том, как понимать термин «простой кодировщик». Я вот считаю, что чтобы выйти за уровень «простого кодировщика», нужно начать принимать технические решения. А вы — что нужно начать принимать бизнес-решения.
>> на плечи аналитика ложатся и задачи описания низкоуровневых проверок
Вы считаете, что поведение системы для определенного и неопределенного текущего пользователя — это низкоуровневая проверка?
>> Требование очень простое — ошибка должна быть сформулирована в бизнес-понятиях и быть понятна пользователю. У нас, кстати, это было записано.
Вот с момента, как оно записано, у меня больше нет вопросов. Я против _неявных_ требований.
И да, для меня признак хорошего программиста — это то, что как только он видит потенциальное неописанное требование — например, поведение системы при ошибке — он не игнорирует его, и не делает тихо, как считает лучше, а идет к постановщику задачи.
А вы — что нужно начать принимать бизнес-решения.
Проверка на входные параметры — это не бизнес-решение. Например, пришел тебе указатель на объект — проверь его на NULL.
Вы считаете, что поведение системы для определенного и неопределенного текущего пользователя — это низкоуровневая проверка?
В статье в приведенном алгоритме сказано, что ЗнП.Пользователь надо установить в текущего пользователя. Если текущего пользователя нет, то произошла какая-то системная ошибка. И да, программист должен провести проверку и выбросить наверх ошибку, если текущий пользователь = NULL. Иначе нельзя сказать, что алгоритм реализован верно. Ведь суть этого алгоритма (поднимаемся на уровень выше) не только в том, чтобы поменять статус ЗнП, но и указать, кто конкретно взял его в работу.
Я против _неявных_ требований.
С этим я согласен. Я лишь делаю упор на то, что лучше аналитику облегчить жизнь и оставить ему описание бизнес-требований. А то, что касается, например, таких вещей, как: какие сообщения выдавать, как проверять входные параметры, как комментировать код, — то можно и без него обойтись. У нас это было в разделе Реализации при описании программных подсистем.
он не игнорирует его, и не делает тихо, как считает лучше, а идет к постановщику задачи.
Это хорошо. Я не против (а часто и за -). Я обращаю внимание вот на что: если постановщик описал все без исключения детали алгоритма, то что остается программисту? Все лишь перевести алгоритм на язык программирования. Вот это я и называю простым кодировщиком.
И, возвращаясь к началу: «А вы — что нужно начать принимать бизнес-решения.» — верно. Понятно, что бизнес-решения бизнес-решениям рознь. Но программист должен думать не только о том, как лучше закодировать алгоритм от постановщика, но и как это все отразится на пользователе. Программист не должен думать только о красоте внутренней архитектуры системы, но и о том, как она отвечает требованиям/ожиданиям пользователя.
Вот пример (происходило буквально два дня назад): одна и та же проверка в коде не проходит по двум совершенно разным причинам с т.з. пользователя. Т.е. проверка так низко в коде, что там непонятно, удаляет пользователь объект или его редактирует. Есть два выхода: (1) оставить прекрасную архитектуру, но выдать трехэтажное сообщение пользователю (кот его может повергнуть в шок и трепет), или (2) доработать код так, чтобы в месте проверки можно было понять, что делал пользователь, и выдать два разных простых сообщения.
И таких вещей возникает масса. Могу лишь повторить, что «мой опыт показывает, что лучшие программисты — это не простые кодировщики». Еще раз — я пишу о системах ERP/СRM/DMS, не касаюсь, например, встроенных систем.
Уважаемый @crackpotcrackpot выше привел неплохой пример про Петю и Васю. Петя — ваш «непростой кодировщик», принимающий технические решения, а Вася — мой «непростой кодировщик», принимающий бизнес-решения. А теперь задумаемся вот над чем: какое отношение Петь и Вась надо при разработке ERP? 1 к 5? Ведь системная архитектура занимает значительно меньший объем, чем бизнес-алгоритмы.
Второй положительный эффект от Вась — это синергия. Грубо, постановщик-то тоже может ошибаться, делать что-то не лучшим образом. Безусловно, можно и нужно дать на review алгоритм другому постановщику. Но почему программист (или тестировщик) не может предложить лучшее решение? Часто так и происходит — программисту лучше виден нижний уровень системы — и от него идет подсказка аналитику.
>> Например, пришел тебе указатель на объект — проверь его на NULL.
А эти проверки я и не прошу описывать. Но вот что делать, если пришло незаполненное поле? Оно должно быть заполнено? Если где-то написано, что оно обязательное — то да. А если нигде не написано?
>> Если текущего пользователя нет, то произошла какая-то системная ошибка. И да, программист должен провести проверку и выбросить наверх ошибку, если текущий пользователь = NULL.
… а что должно произойти с этой ошибкой выше?
>> Я обращаю внимание вот на что: если постановщик описал все без исключения детали алгоритма, то что остается программисту? Все лишь перевести алгоритм на язык программирования.
Вы так пишете, как будто это легко.
Во-первых, когда в алгоритме написано "… и сохраняет в базу данных", за этим может быть неделя-другая разработки. Но это еще мелочи.
А во-вторых… требования не ограничиваются алгоритмами. Вот есть задача: сынтегрировать системы А и Б, система А — потребитель данных, система Б — поставщик. В требованиях от аналитика написано «данные нужно получать из системы Б, ограничения по набору данных такие-то, запаздывание данных в штатном режиме не должно превышать суток, в случае превышения этого параметра необходимо информировать...». Это, с моей точки зрения, достаточные требования (само преобразование данных мы сейчас не рассматриваем). Но алгоритм за ним может быть как простой, так и сложный.
>> Т.е. проверка так низко в коде, что там непонятно, удаляет пользователь объект или его редактирует. Есть два выхода: (1) оставить прекрасную архитектуру, но выдать трехэтажное сообщение пользователю (кот его может повергнуть в шок и трепет), или (2) доработать код так, чтобы в месте проверки можно было понять, что делал пользователь, и выдать два разных простых сообщения.
Забыли третий выход, правильный: сделать первичную проверку на том уровне, где действие пользователя очевидно, и дополнительную (защитную) — на нижнем уровне.
>> Но почему программист (или тестировщик) не может предложить лучшее решение?
Предложить — может. Он не может его самостоятельно принять.
А эти проверки я и не прошу описывать. Но вот что делать, если пришло незаполненное поле? Оно должно быть заполнено? Если где-то написано, что оно обязательное — то да. А если нигде не написано?
>> Если текущего пользователя нет, то произошла какая-то системная ошибка. И да, программист должен провести проверку и выбросить наверх ошибку, если текущий пользователь = NULL.
… а что должно произойти с этой ошибкой выше?
>> Я обращаю внимание вот на что: если постановщик описал все без исключения детали алгоритма, то что остается программисту? Все лишь перевести алгоритм на язык программирования.
Вы так пишете, как будто это легко.
Во-первых, когда в алгоритме написано "… и сохраняет в базу данных", за этим может быть неделя-другая разработки. Но это еще мелочи.
А во-вторых… требования не ограничиваются алгоритмами. Вот есть задача: сынтегрировать системы А и Б, система А — потребитель данных, система Б — поставщик. В требованиях от аналитика написано «данные нужно получать из системы Б, ограничения по набору данных такие-то, запаздывание данных в штатном режиме не должно превышать суток, в случае превышения этого параметра необходимо информировать...». Это, с моей точки зрения, достаточные требования (само преобразование данных мы сейчас не рассматриваем). Но алгоритм за ним может быть как простой, так и сложный.
>> Т.е. проверка так низко в коде, что там непонятно, удаляет пользователь объект или его редактирует. Есть два выхода: (1) оставить прекрасную архитектуру, но выдать трехэтажное сообщение пользователю (кот его может повергнуть в шок и трепет), или (2) доработать код так, чтобы в месте проверки можно было понять, что делал пользователь, и выдать два разных простых сообщения.
Забыли третий выход, правильный: сделать первичную проверку на том уровне, где действие пользователя очевидно, и дополнительную (защитную) — на нижнем уровне.
>> Но почему программист (или тестировщик) не может предложить лучшее решение?
Предложить — может. Он не может его самостоятельно принять.
Уважаемый, lair. Я могу ответить, но ответы мои будут всего лишь повторять то, что я уже писал выше. По-большому счету я не вижу больших различий в наших позициях (тем более, раз уж вы признали, что какие-то проверки можно не описывать -). Возможно, отличие в том, что я культивирую в программистах ориентацию на бизнес, а вы — на системную архитектуру. В любом случае — удачи в ваших проектах!
Требования к интеграции описывали низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Здесь мы их рассматривать не будем.
А ведь это самое интересное и сложное.
Любой программист может построить дом рядом с другим домом, но далеко не любой сможет достроить этаж в уже существующем.
Не соглашусь что интересное, но то что сложное и местами мозговыносящее — это точно
Имею в виду интересное с точки зрения менеджмента :)
100% согласен. Интеграция — одна из самых сложный частей в разработке. У нас ее было много разной: и синхронной и асинхронной. Все в одну статью не впихнуть. Тем более, мне кажется, что там интересны именно технологические решения, а не методология описания требований. А технологии пусть программисты, кот непосредственно их реализовывали, описывают.
Странно, что в вашей документации не было ничего про архитектуру и проектирование.
Видимо, дело в том, что вы залезли в чёрный ящик с «системными» требованиями.
Называние требований «системными» очень неудачно, т.к. система — это не только софт, а и остальные немаловажные компоненты — железо, процессы, люди, правила.
Смотрите уровни требований и документов требований по ISO 29148 (если не нравится ГОСТ 34).
Видимо, дело в том, что вы залезли в чёрный ящик с «системными» требованиями.
Называние требований «системными» очень неудачно, т.к. система — это не только софт, а и остальные немаловажные компоненты — железо, процессы, люди, правила.
Смотрите уровни требований и документов требований по ISO 29148 (если не нравится ГОСТ 34).
Странно, что в вашей документации не было ничего про архитектуру и проектирование.
Было. Должно было быть в разделе Реализация, но по факту было чуть выше. Для статьи статьи я несколько идеализировал оглавление документации.
Называние требований «системными» очень неудачно
В действительности этот раздел назывался ТЗ. Но в статье не хотел дразнить любителей ГОСТов -).
Предлагайте свое название!
Спасибо за термин «сценарий»! Я давно предлагаю термин «описание бизнес-процесса» заменить на короткое «сценарий».
Спасибо! Отличная статья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример написания функциональных требований к Enterprise-системе