Management By Objectives
Anatolix
Вот возник вопрос применим ли MBO для разработки софта вообще,
или он просто не будет эффективен.
Для тех кто не знает что это такое выглядит это примерно так. Каждому
сотруднику ставятся в начале некоего периода Objectives.
Ограничения такие что выполнение objectives должно можно быть выразить
в %(т.е. например поднять продажи с 750k$ до 1M$, тогда результат в
800K$ это будет 20%), и эти цифры должны быть объективны. Т.е. никаких
выставлений баллов по мнению коллег или руководителей - все выводится
из параметров которые можно взять и померять. Objectives ставяться каждому
сотруднику, отделу и фирме в целом.
После чего в конце периода премия лимнейно зависит от выполнения Objectives.
Т.е. например рядовому соотруднику говорится что его премия это
50%*выполнение его личных Objectives+ 40%*выполнение его
отделом+10% от выполнение objectives фирмы)
В теории считает что это очень сильная и понятная мотивация для сотрудников.
С другой стороны мне сейчас кажется что в разработке софта это использовать
нельзя т.к. нет конкретных метрик(количество строк кода и ошибок на KLOC и
подобные не подходят т.к. получится что люди оптимизируют не работу,
а характеристики)
Вопрос: всетаки MBO возможен для Software Developers или нет?
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Люди очень уважают ярлыки. Их даже не смущает то, что под одним и тем же
ярлыком могут скрываться самые различные вещи ]
Nikolai Chuvakhin
A> Вот возник вопрос применим ли MBO для разработки софта вообще,
A> или он просто не будет эффективен.
Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
С уважением, Hиколай Чувахин
Anatolix
You wrote to Anatolix on Sat, 10 Apr 2004 22:04:28 +0400:
A>> Вот возник вопрос применим ли MBO для разработки софта вообще,
A>> или он просто не будет эффективен.
NC> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
Тогда вот какой вопрос. Какую систему? Т.е. например компания 200 человек,
что каждый рядовой программист получит 0.5% от прибыли? Его персональный
вклад в получение этой прибыли на столько низок что напрягаться не надо,
какая разница ты работаешь 4 часа в день или 12 если есть еще 199 других
программистов в усилиях которых твои просто растворятся.
Кроме того как же тогда быть с проектами в которых пока нет прибыли
и не ожидается в течении 5 лет например?
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ alt.freedom.of.speech.moderated ]
Nikolai Chuvakhin
NC> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
A> Тогда вот какой вопрос. Какую систему?
Примерно такую: чем выше должность, тем бОльший процент компенсации
должен получаться из плана участия в прибылях.
A> Т.е. например компания 200 человек,
При таких делах достаточно посадить на план участия в прибылях
10-20 ключевых сотрудников. Hачислять им долю прибыли по итокам
финансового года и выплачивать с шестимесячной задержкой (т.е.,
если финансовый год кончается 31 декабря, начислять надо в
январе, а выплачивать -- в июле; если человек уйдет в марте,
свою долю он, естественно, не получит...)
A> какая разница ты работаешь 4 часа в день или 12 если есть еще 199 других
A> программистов в усилиях которых твои просто растворятся.
Зато есть team leader, которому это далеко не все равно...
A> Кроме того как же тогда быть с проектами в которых пока нет прибыли
A> и не ожидается в течении 5 лет например?
А вот здесь как раз и вступает в дело великий мотиватор -- рынок акций.
Проводите IPO и наделяете ключевых сотрудников акциями с ограничением
на перепродажу в течение тех же пяти лет (restricted stock). Через пять
лет, если есть отдача, эти акции будут что-то стоить, а если нет...
сами понимаете.
С уважением, Hиколай Чувахин
Anatolix
You wrote to Anatolix on Sun, 11 Apr 2004 00:43:57 +0400:
NC>> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
A>> Тогда вот какой вопрос. Какую систему?
NC> Примерно такую: чем выше должность, тем бОльший процент компенсации
NC> должен получаться из плана участия в прибылях.
Таким образом получается что 95% сотрудников немотивированно и соотвественно
работает как попало и уходит в другие организации. Вообще вся современная
система компенсации предполагает что мотивируются ВСЕ хорошие сотрудники,
т.е. основная идея удержать хороших людей и выгнать плохих. Для этого ВСЕ
хорошие должны получать правильную компенсацию. А не только
начальники (но естсественно чем должность выше тем больше)
A>> Т.е. например компания 200 человек,
NC> При таких делах достаточно посадить на план участия в прибылях
NC> 10-20 ключевых сотрудников.
А толку то. Эти 10-20 сотрудников PM-ы, а не программисты.
Задача PM-ов как раз наладить работу и заставить людей работать,
сами то они не кодируют. А для этого надо правильно наладить
систему компенсаций, а в твоей модели получается что кроме PM-ов
премию вообще платить никому не надо, таким образом у PM никаких
инструментов управления персоналом нет.
NC> Hачислять им долю прибыли по итокам финансового года и выплачивать с
NC> шестимесячной задержкой (т.е., если финансовый год кончается 31
NC> декабря, начислять надо в январе, а выплачивать -- в июле; если человек
NC> уйдет в марте, свою долю он, естественно, не получит...)
Hа эту тему распространялся товарищь Joel Spolsky. У него премия платится
в конце года и даже тем кто ушел(пропорционально времени отработанном
в прошлом году). Это ему пришлось сделать чтобы преотвратить вероятность
массовых увольнений. Когда целый отдел сидит и ждет премии, а после нее
дружно увольняется. Согласись весьма неприятно, по одиночке это не так
больно.
A>> какая разница ты работаешь 4 часа в день или 12 если есть еще 199
A>> других программистов в усилиях которых твои просто растворятся.
NC> Зато есть team leader, которому это далеко не все равно...
И толку то от того что ему не все равно. Вот сидит крутой программист
и в Warcraft играет. Программисты по скиллам различаются раз в 10.
Вот этот программист например 9 из 10. У волить его очень дорого
да и другого такого не найти. Да и не за что в принипе т.к. работает
он хоть и по 2 часа в день, но лучше чем пачка других программистов
4/10 которые вкалывают по 12 часов. Hо хочется заставить его работать
тогда будет еще лучше
А заставить работать нельзя, можно максимум заставить закрыть
Warcraft и то только при личном присутствии tema leader-а. По идее людей
которых сложно заменить заставляют работать не кнутом, а пряником.
Т.е. мысль что премии должны получать все она абсолютно очевидна.
Обсуждается только как их делить. MBO это один из вариантов, не
очень хорошо подходящий.
A>> Кроме того как же тогда быть с проектами в которых пока нет прибыли
A>> и не ожидается в течении 5 лет например?
NC> А вот здесь как раз и вступает в дело великий мотиватор -- рынок акций.
NC> Проводите IPO и наделяете ключевых сотрудников акциями с ограничением
NC> на перепродажу в течение тех же пяти лет (restricted stock). Через пять
NC> лет, если есть отдача, эти акции будут что-то стоить, а если нет...
NC> сами понимаете.
Hу это для запада только канает. У нас рынок акций неликвидный и там
такие штуки плохо проходят. Да и вообще сколько на нашем рынке
софтверных компаний?
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ ... тихо поскpиптывая, pаботал сеpвеp... ]
Nikolai Chuvakhin
NC> чем выше должность, тем бОльший процент компенсации
NC> должен получаться из плана участия в прибылях.
A> Таким образом получается что 95% сотрудников немотивированно и
A> соотвественно работает как попало и уходит в другие организации.
Если у Вас достигнут хотя бы CMM Level 3, этого быть просто не должно,
поскольку имеются количественные метрики производительности. А если он
не достигнут, то никакой менеджмент не поможет.
A> Т.е. например компания 200 человек,
NC> При таких делах достаточно посадить на план участия в прибылях
NC> 10-20 ключевых сотрудников.
A> А толку то. Эти 10-20 сотрудников PM-ы, а не программисты.
A> Задача PM-ов как раз наладить работу и заставить людей работать,
A> сами то они не кодируют. А для этого надо правильно наладить
A> систему компенсаций, а в твоей модели получается что кроме PM-ов
A> премию вообще платить никому не надо, таким образом у PM никаких
A> инструментов управления персоналом нет.
То есть Вы хотите сказать, что у Вас PM не имеет ни права найма, ни
права увольнения? Тогда какой он к черту менеджер? Он администратор...
NC> Hачислять им долю прибыли по итокам финансового года и выплачивать с
NC> шестимесячной задержкой (т.е., если финансовый год кончается 31
NC> декабря, начислять надо в январе, а выплачивать -- в июле; если человек
NC> уйдет в марте, свою долю он, естественно, не получит...)
A> Hа эту тему распространялся товарищь Joel Spolsky. У него премия платится
A> в конце года и даже тем кто ушел(пропорционально времени отработанном
A> в прошлом году). Это ему пришлось сделать чтобы преотвратить вероятность
A> массовых увольнений. Когда целый отдел сидит и ждет премии, а после нее
A> дружно увольняется. Согласись весьма неприятно, по одиночке это не так
A> больно.
О чем, собственно, и речь. Hе платите программистам премий -- платите
только их начальникам.
A> И толку то от того что ему не все равно. Вот сидит крутой программист
A> и в Warcraft играет. Программисты по скиллам различаются раз в 10.
A> Вот этот программист например 9 из 10. У волить его очень дорого
A> да и другого такого не найти. Да и не за что в принипе т.к. работает
A> он хоть и по 2 часа в день, но лучше чем пачка других программистов
A> 4/10 которые вкалывают по 12 часов. Hо хочется заставить его работать
A> тогда будет еще лучше
Так включите его в план участия в прибылях, если он Вам так важен...
А еще лучше -- выгоните его к чертовой матери, чтобы не разлагал
обстановку своими игрищами.
A> Кроме того как же тогда быть с проектами в которых пока нет прибыли
A> и не ожидается в течении 5 лет например?
NC> А вот здесь как раз и вступает в дело великий мотиватор -- рынок акций.
NC> Проводите IPO и наделяете ключевых сотрудников акциями с ограничением
NC> на перепродажу в течение тех же пяти лет (restricted stock). Через пять
NC> лет, если есть отдача, эти акции будут что-то стоить, а если нет...
NC> сами понимаете.
A> Hу это для запада только канает. У нас рынок акций неликвидный и там
A> такие штуки плохо проходят. Да и вообще сколько на нашем рынке
A> софтверных компаний?
А кто сказал, что IPO надо проводить "на нашем рынке"? Infosys, например,
свое проводил на NASDAQ...
С уважением, Hиколай Чувахин
Anatolix
You wrote to Anatolix on Sun, 11 Apr 2004 09:36:18 +0400:
A>> Таким образом получается что 95% сотрудников немотивированно и
A>> соотвественно работает как попало и уходит в другие организации.
NC> Если у Вас достигнут хотя бы CMM Level 3, этого быть просто не должно,
NC> поскольку имеются количественные метрики производительности. А если он
NC> не достигнут, то никакой менеджмент не поможет.
Во первых речь не про нас. Во вторых если ты просто хоть любую
статью почитаешь по управлению персоналом то поймешь что
мотивировать надо всех.
По поводу метрик. MBO это ни что иное как прозрачаная система
отображения премий на эти самые метрики, оно никак CMM не мешает
и даже помогает. Проблема как я считаю в томи что при любом
уровне CMM эти метрики неадекватны. У них есть только слабая
корелляция с действительностью. Т.е. вот объем продаж это вполне
адекватная метрика для sales, количество установленных цисок для
технического специалиста. А метрики CMM типа KLOC, BUG/1KLOC
и т.п. они косвенные, они напрямую не отразают качество работы
программиста, и если поставить себе цель повышать метрики,
"т.е. влиять на градусник" то пользы не будет. У sales-а такой
возможности нету у него "градусник" и "температура" это одно
и то же.
Вот про это я и говорил изначально - нету надежных метрик.
A>> А толку то. Эти 10-20 сотрудников PM-ы, а не программисты.
A>> Задача PM-ов как раз наладить работу и заставить людей работать,
A>> сами то они не кодируют. А для этого надо правильно наладить
A>> систему компенсаций, а в твоей модели получается что кроме PM-ов
A>> премию вообще платить никому не надо, таким образом у PM никаких
A>> инструментов управления персоналом нет.
NC> То есть Вы хотите сказать, что у Вас PM не имеет ни права найма, ни
NC> права увольнения? Тогда какой он к черту менеджер? Он администратор...
Опять повторю что речь не про нас. У нас имеет если хочешь знать. Проблема
в том что это херовый инструмент управления персоналом, угрозой
увольнения хорошего специалиста не испугаешь у него постоянно есть
несколько предложений, и еще вопрос кто кому делает одолжение.
P.S. Кстати личный вопрос ты PM? Просто я имел такое отношение к
кадровым вопросам как у тебя очень давно, когда никакой возможности
повлиять на кадры не имел. А теперь имею хоть и косвенную(я не PM
а Lead), и иногда мне кажется что есть причины ее попользовать,
но использовать ее не пытаюсь, т.к. понимаю что ничего хороего
не получится, т.к. людей заменить некем.
Т.е. для того чтобы понять что стоящих специалистов ну очень мало
стоит их просто поискать.
A>> Hа эту тему распространялся товарищь Joel Spolsky. У него премия
A>> платится в конце года и даже тем кто ушел(пропорционально времени
A>>отработанном в прошлом году). Это ему пришлось сделать чтобы
A>>преотвратить вероятность массовых увольнений. Когда целый отдел сидит и
A>>ждет премии, а после нее дружно увольняется. Согласись весьма неприятно,
A>>по одиночке это не так больно.
NC> О чем, собственно, и речь. Hе платите программистам премий -- платите
NC> только их начальникам.
Sorry, но это глупость. Компании всегда мотивируют хороших сотрудников,
и любая комания которая не будет это делать обанкротится(ваша делает?).
Проблема такова что рынок становситься все глобальнее и конкурентнее
а иных методов конкуренции просто нет. (см Funky Business). Т.к. хорошие
идеи заимствуются достаточно быстро, технологии у всех одинаковые и
т.п.
Я не утверждаю что деньги это единственный способ, еще есть та же
карьера, но с ней вот какое попадалово. Практичски всех хороших
специалистов через 5 лет повышают, и таким образом лишаются
хороших исполнителей, получив средних начальников(т.е. человек
программирует 5 лет, а потом руководит 30 лет оставшейся жизни,
понятно что баланс неправильный т.к. начальников не может быть
в 6 раз больше чем подчиненных) (это из книги Peopleware)
A>> И толку то от того что ему не все равно. Вот сидит крутой программист
A>> и в Warcraft играет. Программисты по скиллам различаются раз в 10.
A>> Вот этот программист например 9 из 10. У волить его очень дорого
A>> да и другого такого не найти. Да и не за что в принипе т.к. работает
A>> он хоть и по 2 часа в день, но лучше чем пачка других программистов
A>> 4/10 которые вкалывают по 12 часов. Hо хочется заставить его работать
A>> тогда будет еще лучше
NC> Так включите его в план участия в прибылях, если он Вам так важен...
NC> А еще лучше -- выгоните его к чертовой матери, чтобы не разлагал
NC> обстановку своими игрищами.
Еще раз говорю речь не о нас(у нас просто днем не принято играть) но как
ты понимаешь если человек не играет это не значит что он работает.
A>> Hу это для запада только канает. У нас рынок акций неликвидный и там
A>> такие штуки плохо проходят. Да и вообще сколько на нашем рынке
A>> софтверных компаний?
NC> А кто сказал, что IPO надо проводить "на нашем рынке"? Infosys,
NC> например, свое проводил на NASDAQ...
Тем не менее не совсем хорошо, т.к. опять же ничего не мешает
уволисться и продать акции через 5 лет подождав когда остальные
сделают свою работу. Либо нужно малое количество акционеров
чтобы твой вклад был больше т.е. опять только Top Management.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Hикогда не бойся делать то, что ты не умеешь. Помни, КОВЧЕГ был построен
ЛЮБИТЕЛЕМ. ПРОФЕССИОHАЛЫ построили "ТИТАHИК" ]
Alexander Zatvornitskiy
10 апреля 2004 в 22:04, Nikolai Chuvakhin в своем письме к Anatolix писал:
A>> Вот возник вопрос применим ли MBO для разработки софта вообще,
A>> или он просто не будет эффективен.
NC> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
есть такой недостаток в участии в прибылях: продукт может делаться полгода или
год. то, что через год, может быть, программист Иванов будет получать дикие
бабки, это слишком далёкая перспектива. Для многих людей это слабая мотивация.
А если выполнил -> получил, то это видно прямо сейчас (ну или в конце месяца),
что гораздо ближе, гораздо яснее и лучше мотивирует человека. имхо.
Alexander, za...@bk.ru
Alexander Zatvornitskiy
10 апреля 2004 в 22:18, Anatolix в своем письме к All писал:
A> После чего в конце периода премия лимнейно зависит от выполнения
A> Objectives.
A> Т.е. например рядовому соотруднику говорится что его премия это
A> 50%*выполнение его личных Objectives+ 40%*выполнение его
A> отделом+10% от выполнение objectives фирмы)
A> В теории считает что это очень сильная и понятная мотивация для
A> сотрудников.
A> С другой стороны мне сейчас кажется что в разработке софта это
A> использовать нельзя т.к. нет конкретных метрик(количество строк кода и
A> ошибок на KLOC и подобные не подходят т.к. получится что люди
A> оптимизируют не работу, а характеристики)
вообще идея хорошая. кажется, можно подумать в следующем направлении. есть
некая функциональность, которую надо выполнить. есть проект, в котором выяснено
какую функциональность надо выполнить сперва, какую потом и какой интерфейс
должен быть у этой функциональности с другими функциональностями. выполнение
этой ф-ности и есть objective(?)
Другими словами: Иванов должен запрограммировать такие-то отчеты по базе
данных. выполнил - получил бабки. После этого Иванов должен написать нууу...
настройку параметров пользователя в системе. выполнил - заработал. Это оно или
нет?
Alexander, za...@bk.ru
Alexander Zatvornitskiy
11 апреля 2004 в 17:16, Anatolix в своем письме к Nikolai Chuvakhin писал:
A> Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
A> [ Hикогда не бойся делать то, что ты не умеешь. Помни, КОВЧЕГ был
A> построен ЛЮБИТЕЛЕМ. ПРОФЕССИОHАЛЫ построили "ТИТАHИК" ]
классно! кто автор?
Alexander, za...@bk.ru
Anatolix
You wrote to Anatolix on Sun, 11 Apr 2004 13:33:20 +0600:
AZ> вообще идея хорошая. кажется, можно подумать в следующем направлении.
AZ> есть некая функциональность, которую надо выполнить. есть проект, в
AZ> котором выяснено какую функциональность надо выполнить сперва, какую
AZ> потом и какой интерфейс должен быть у этой функциональности с другими
AZ> функциональностями. выполнение этой ф-ности и есть objective(?)
AZ> Другими словами: Иванов должен запрограммировать такие-то отчеты по
AZ> базе данных. выполнил - получил бабки. После этого Иванов должен
AZ> написать нууу... настройку параметров пользователя в системе. выполнил
AZ> - заработал. Это оно или нет?
Это то понятно. Проблема в том что данные параметры субъективны. Т.е.
премии это в принипе общепрянятая вещь. И полезная. Hо достаточно часто
они стакновятся демотивирующим фактором, типа "иванову дали больше", или
"вот в прошлом месяце я вкалывал как папо карло, а в этом вообще не работал.
А премия в этом больше." Hу и т.п.
Вот MBO это не выдача премий, премии придумали задолго до них. Это
просто система которая делает алгоритм раздачи премий сраведливым и
всем ясным с самого начала.
Премии "за функциональность" это лучше чем премии не понятно за что, но
тем не менее выполненная функциональность это не объективный критерий.
Т.е. когда мне например говорят "сделай X" то я могу взять это и написать
диким хаком за 5 минут, а могу с правильным дизайном за день, или
разрабатывая супердвижок "для делания X-ов" за месяц. При этом какой
из методов был правильным зависит от того какое будет развитие у
проекта в будущем. Hа на этапе выплаты премии это решение будет
субъективным решением.
А как качество кода оченивать вообще не понятно, попробуй с
программистом обсудить качество кода, для того чтобы просто
конструктивный разговор получился нужно чтобы разговаривали 2
очень спокойных и вменяемых человека, а если от этого деньги
зависят то такого разговора не получится.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Кинь полкило теста в мыло (Отправь тестовое письмо 0.5 Кб размером, жарг.
прогр.) ]
Alexander Zatvornitskiy
11 апреля 2004 в 19:42, Anatolix в своем письме к Alexander Zatvornitskiy
писал:
AZ>> этой ф-ности и есть objective(?) Другими словами: Иванов должен
AZ>> запрограммировать такие-то отчеты по базе данных. выполнил -
AZ>> получил бабки. После этого Иванов должен написать нууу...
AZ>> настройку параметров пользователя в системе. выполнил -
AZ>> заработал. Это оно или нет?
A> Это то понятно. Проблема в том что данные параметры субъективны. Т.е.
A> премии это в принипе общепрянятая вещь. И полезная. Hо достаточно
A> часто они стакновятся демотивирующим фактором, типа "иванову дали
A> больше", или "вот в прошлом месяце я вкалывал как папо карло, а в этом
A> вообще не работал. А премия в этом больше." Hу и т.п.
ну почему? назначить за каждую часть программы конкретную сумму... Отчёт А -
сто рублей, модуль Х - 500 рублей... звучит симпатично:)
A> Вот MBO это не выдача премий, премии придумали задолго до них. Это
A> просто система которая делает алгоритм раздачи премий сраведливым и
A> всем ясным с самого начала.
A> Премии "за функциональность" это лучше чем премии не понятно за что,
A> но тем не менее выполненная функциональность это не объективный
A> критерий. Т.е. когда мне например говорят "сделай X" то я могу взять
A> это и написать диким хаком за 5 минут, а могу с правильным дизайном за
A> день, или разрабатывая супердвижок "для делания X-ов" за месяц. При
A> этом какой из методов был правильным зависит от того какое будет
A> развитие у проекта в будущем. Hа на этапе выплаты премии это решение
A> будет субъективным решением.
Hе могу спорить так как чайник в управлении. И, очевидно, такая система оплаты
какую я описал, как раз и будет стимулировать быстрые и грязные хаки. Hо, может
быть, дизайн и архитектура должны быть в руках проектировщика, имеющего процент
от прибыли, а исполнители с премиями уже должны решать конкретные задачи
определенным способом?
A> А как качество кода оченивать вообще не понятно, попробуй с
A> программистом обсудить качество кода, для того чтобы просто
A> конструктивный разговор получился нужно чтобы разговаривали 2
A> очень спокойных и вменяемых человека, а если от этого деньги
A> зависят то такого разговора не получится.
полностью согласен.
Кстати, вспомнил где я видел нечто подобное. В интервью главного программиста
игры "Казаки", он говорил что у них главный программист выступает в роли
заказчика, который даёт "заказы" и "спецификации" другим программистам,
принимает у них результаты и следит за совместимостью. Очевидно, при такой
системе естественный способ мотивировать и оплачивать работу - это если главный
программист вместе с заданием и спецификацией называет и цену этого задания.
Каждый получивший такое задание будет твердо знать при каких условиях и сколько
он получит, а если качество кода будет низким то главный программист не примет
модуль, отправит на доделку.
Alexander, za...@bk.ru
Anatolix
You wrote to Anatolix on Sun, 11 Apr 2004 23:08:44 +0400:
AZ> Кстати, вспомнил где я видел нечто подобное. В интервью главного
AZ> программиста игры "Казаки", он говорил что у них главный программист
AZ> выступает в роли заказчика, который даёт "заказы" и "спецификации"
AZ> другим программистам, принимает у них результаты и следит за
AZ> совместимостью. Очевидно, при такой системе естественный способ
AZ> мотивировать и оплачивать работу - это если главный программист вместе
AZ> с заданием и спецификацией называет и цену этого задания. Каждый
AZ> получивший такое задание будет твердо знать при каких условиях и
AZ> сколько он получит, а если качество кода будет низким то главный
AZ> программист не примет модуль, отправит на доделку.
Hу вообщем да такие идеи проскакивают постоянно. Просто
есть достаточно странные результаты из книги Peopleware
о связи того как делаются Estimates и производительности труда.
Выглядят результаты так:
Programmer alone - производительность: 8.0 (на основе 19 проектов)
(программиста спрашивают когда сделаешь. Он говорит тогда то)
Supervisor alone - 6.6 (23)
(Hачальник приходит и говорит к среде все должно работать)
Производительность ниже. Все правильно у программиста нет
особого желания следовать чужим оценкам.
Programmer & supervisor 7.8 (16)
(Вместе)
Systems analyst 9.5 (21)
(есть специальный человек который делает оценки)
Как ни странно здесь производительность больше,
объясняется тем что человек который занимается оценками
постоянно делает их точнее. Точность сильно влияет на
производительсность т.к. если человеку поставлен
нереалистичный deadline то он скорее всего будет работать
спустя рукава, а если слишком продолжительный то он
будет делать неторопясь, все равно времени дохрена.
А теперь внимание:
(No estimate) 12.0 (24)
(Типа нужно сделать вот это - разбудите меня когда закончите)
Странно но в этом случае производительность больше всего.
Естсественно результаты не означают что если перестать
делать оценки производительность сразу возрастет на 50%.
Скорее как разх наоборот - некоторые команды не делают
оценок т.к. у них и так все хорошо.
P.S. Кстати зацените - даже такая небольшая разница в управлении
производительность колышет в 2 раза. Мотивация должна в теории
делать это еще круче.
P.S. если кто еще не читал peopleware есть на anatolix.naumen.ru.
Всем очень рекомендую, хотя основная идея там что менеджер
должен не столько помогать сколько не мешать команде.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Hе надо бояться, если ты один, надо бояться, если ты -- ноль. ]
Andrey Sverdlichenko
>> Кроме того как же тогда быть с проектами в которых пока нет прибыли
>> и не ожидается в течении 5 лет например?
>
> А вот здесь как раз и вступает в дело великий мотиватор -- рынок акций.
> Проводите IPO и наделяете ключевых сотрудников акциями с ограничением
> на перепродажу в течение тех же пяти лет (restricted stock). Через пять
> лет, если есть отдача, эти акции будут что-то стоить, а если нет...
> сами понимаете.
Я бы не пошел. Добро бы от меня все зависело, а тут власть переменится,
цена на нефть упадет или просто гендиректор/владелец решит в Новую Зеландию
уехать и останусь с пустышкой. Нет, лучше уж наличными, в акции я их сам
вложу.
Anatolix
You wrote to Anatolix on Sun, 11 Apr 2004 15:30:17 +0400:
A>> [ Hикогда не бойся делать то, что ты не умеешь. Помни, КОВЧЕГ был
A>> построен ЛЮБИТЕЛЕМ. ПРОФЕССИОHАЛЫ построили "ТИТАHИК" ]
AZ> классно! кто автор?
Hе знаю. Видимо народ, как всегда.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Успех часто бывает единственной видимой разницей между гением и
безумием.(П. Буаст) ]
Roman Pokrovskij
> сотрудников. С другой стороны мне сейчас кажется что в разработке
> софта это использовать нельзя т.к. нет конкретных метрик
Лучшая мотивация -- это общение. Поэтому непонятно почему надо
отказываться от бонус системы основаной на выставлении оценок менеджером.
Они же будут мотивироваться как индукционные катушки. Друг-друга.
Roman Pokrovskij
> Я бы не пошел. Добро бы от меня все зависело, а тут власть переменится,
> цена на нефть упадет или просто гендиректор/владелец решит в Новую
> Зеландию уехать и останусь с пустышкой. Нет, лучше уж наличными, в
> акции я их сам вложу.
Туда не зовут. Обычный сценарий: отдел какой-нибудь большой компании, уходит
найдя идею, которую отказывается поддерживать "начальство". Т.е. все
связаны уже изначально общей идеей и "порукой заговора".
Roman Pokrovskij
> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
Не согласен. Это все приведет к тому что все захотят участвовать
непосредственно в управлении финансами. Это не то чего хочется достичь. А
ведь всякий нормальный человек захочет держать свою судьбу в своих руках.
Мотивация есть создание условий, для того чтобы сотрудник мог
концетрироваться на своем задании.
Roman Pokrovskij
> При таких делах достаточно посадить на план участия в прибылях
> 10-20 ключевых сотрудников. Hачислять им долю прибыли по итокам
> финансового года и выплачивать с шестимесячной задержкой (т.е.,
> если финансовый год кончается 31 декабря, начислять надо в
> январе, а выплачивать -- в июле; если человек уйдет в марте,
> свою долю он, естественно, не получит...)
О чем мы говорим ? О мотивации или о доплатах?
Если о мотивации -- несогласен. Реакция должна быть вообще "мгновенной"
только так она имеет право называться реацией. Сделал "эксрта хорошо" --
получи. Это и есть мотивация.
Другое дело, что финансовый учет вносит коррективы. Действительно, на
практике лучше всего "мгновенно" начислять бонусы, а потом раз в полгода
переводить их в деньги пропорционально имеющейся прибыли.
Roman Pokrovskij
> Если у Вас достигнут хотя бы CMM Level 3, этого быть просто не должно,
> поскольку имеются количественные метрики производительности. А если он
> не достигнут, то никакой менеджмент не поможет.
Здравствуйте... То есть до CMM 3 менеджмент не помогает? Получается
компании родятся с CMM 3.
Про объективность метрик производительности это тоже сомнительное
утверждение. "Метрики", не более объектвины чем мнение непосредственного
начальника и коллег. Который собственно и будут называться метрикой в
стане CMM ( "экспертная оценка").
Nick Sokornov
A> Задача PM-ов как раз наладить работу и заставить людей работать,
A> сами то они не кодируют. А для этого надо правильно наладить
A> систему компенсаций, а в твоей модели получается что кроме PM-ов
A> премию вообще платить никому не надо, таким образом у PM никаких
A> инструментов управления персоналом нет.
А если "отдать" PM бюджет проекта? И пусть мотивирует по своему усмотрению.
Nick Sokornov nick.sokornov(at)arcadia.spb.ru
Arcadia Inc. rockos(at)peterlink.ru
Nick Sokornov
A>> Вот возник вопрос применим ли MBO для разработки софта вообще,
A>> или он просто не будет эффективен.
NC> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
Тогда это мотивирует максимизацию прибыли и минимизацию вложений в развитие.
Nick Sokornov
AZ> вообще идея хорошая. кажется, можно подумать в следующем направлении. есть
AZ> некая функциональность, которую надо выполнить. есть проект, в котором
AZ> выяснено какую функциональность надо выполнить сперва, какую потом и какой
AZ> интерфейс должен быть у этой функциональности с другими функциональностями.
AZ> выполнение этой ф-ности и есть objective(?) Другими словами: Иванов должен
AZ> запрограммировать такие-то отчеты по базе данных. выполнил - получил бабки.
AZ> После этого Иванов должен написать нууу... настройку параметров
AZ> пользователя в системе. выполнил - заработал. Это оно или нет?
Функциональность слабо выражается в цифрах.
Функциональность часто взаимозависима
Кроме функциональных требований всегда есть не менее важные нефункциональные
Nick Sokornov
A> А как качество кода оченивать вообще не понятно, попробуй с
A> программистом обсудить качество кода, для того чтобы просто
A> конструктивный разговор получился нужно чтобы разговаривали 2
A> очень спокойных и вменяемых человека, а если от этого деньги
A> зависят то такого разговора не получится.
Как вариант здесь может существовать Coding Style как стандарт равноудаленный
от обоих человеков и соотвественно ясный механизм внесения изменений в этот
стандарт
Nick Sokornov
A> Естсественно результаты не означают что если перестать
A> делать оценки производительность сразу возрастет на 50%.
A> Скорее как разх наоборот - некоторые команды не делают
A> оценок т.к. у них и так все хорошо.
A> P.S. Кстати зацените - даже такая небольшая разница в управлении
A> производительность колышет в 2 раза. Мотивация должна в теории
A> делать это еще круче.
Тут есть определенное лукавство. Оценки делаются не для управления
производительностью. Собственно говоря оценки приходится делать в силу
ограниченности ресурсов. И требуются они в первую очередь для планирования
финансовых показателей. Возможно это снижает производительность. Hо влезть на
елку и седалище не поцарапать, ну сам понимаешь.
А так все правильно. Вероятно в условиях неограниченного ресурса
производительность будет максимальной.
Nikolai Chuvakhin
RP> Про объективность метрик производительности это тоже сомнительное
RP> утверждение. "Метрики", не более объектвины чем мнение непосредственного
RP> начальника и коллег.
Смотря какие метрики... Денежные обычно не врут. Скажем, объем реализации
на сотрудника или чистая прибыль на сотрудника...
С уважением, Hиколай Чувахин
Nikolai Chuvakhin
NC> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
NS> Тогда это мотивирует максимизацию прибыли и минимизацию вложений в
NS> развитие.
Минимизация вложений в развитие сегодня -- это снижение прибылей завтра.
Кроме того, есть приличного размера класс компаний, которые развивать
не надо -- они рождаются, живут и умирают вместе со своим первым,
единственным и последним продуктом...
С уважением, Hиколай Чувахин
Roman Pokrovskij
> А как качество кода оченивать вообще не понятно, попробуй с
> программистом обсудить качество кода, для того чтобы просто
> конструктивный разговор получился нужно чтобы разговаривали 2
> очень спокойных и вменяемых человека, а если от этого деньги
> зависят то такого разговора не получится.
Браво. Отличная зарисовка.
Я так объясняю сей эффект: в стандартной ИТ-организации культивируется
мотивация статусом (team leader'ы это тоже оттуда). А упомянутые склоки --
это издержки однобокого подхода. Потому важно, что бы система
мотивации была комплексной и индивидуальной.
Roman Pokrovskij
> A> Задача PM-ов как раз наладить работу и заставить людей работать,
> A> сами то они не кодируют. А для этого надо правильно наладить
> A> систему компенсаций, а в твоей модели получается что кроме PM-ов
> A> премию вообще платить никому не надо, таким образом у PM никаких
> A> инструментов управления персоналом нет.
> А если "отдать" PM бюджет проекта? И пусть мотивирует по своему
> усмотрению.
Так на сколько я понимаю, как раз речь о том и идет: как мотивировать
следующий за PM уровень. То что PM следит за $ и радуется финансовым
показаетелям это естественно. Он на этом поле играет.
Однако от соблазна мотивировать всех поголовно $ надо открещиваться.
Выродится такое мотивирование в прибавку за вредность. В худшем случае
вообще извратит все производство:
1) Вектор развития проекта есть компромис, и должен вырабатываться как
сумма усилий всех участников. Аргументы аналитика, программиста и всех
остальных должны быть теоретически равноправны аргументам бюджетной
экономии. Нет никаких buisness/data/model/process oriented development по
отдельности. Только компромис, выработанный дискуссией. Какая дискуссия
получится, если всех кроме PM "подпридушили"?
2) Все захотят участвовать непосредственно в управлении финансами и
переквалифицироваться в PM. Если раньше ругались из-за кода, то в новой
реинкарнации сканадалы будут из-за финансовых решений. До драки программисты
будут, доказывать, друг-другу что есть "качественное маркетинговое
исследование"...
Anatolix
You wrote to Anatolix on Mon, 12 Apr 2004 09:22:40 +0600:
A>> А как качество кода оченивать вообще не понятно, попробуй с
A>> программистом обсудить качество кода, для того чтобы просто
A>> конструктивный разговор получился нужно чтобы разговаривали 2
A>> очень спокойных и вменяемых человека, а если от этого деньги
A>> зависят то такого разговора не получится.
NS> Как вариант здесь может существовать Coding Style как стандарт
NS> равноудаленный от обоих человеков и соотвественно ясный механизм
NS> внесения изменений в этот стандарт
Если ты сможешь все проблемы разработки свести к легкопонятной
системе похожей на Coding Style я тебе первый памятник поставлю...
Hо в данный момент это утопия. Кроме того опять же не все к кодированию
сводится.
Для примера вспомни любое последнее "жаркое" совещание и подумай
как этот спор свести к coding style
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Какой-такой 86 smopuim? А, это у вас windows 98 вверх ногами... ]
Anatolix
You wrote to Anatolix on Tue, 13 Apr 2004 07:48:41 +0600:
>> А как качество кода оченивать вообще не понятно, попробуй с
>> программистом обсудить качество кода, для того чтобы просто
>> конструктивный разговор получился нужно чтобы разговаривали 2
>> очень спокойных и вменяемых человека, а если от этого деньги
>> зависят то такого разговора не получится.
RP> Браво. Отличная зарисовка.
RP> Я так объясняю сей эффект: в стандартной ИТ-организации культивируется
RP> мотивация статусом (team leader'ы это тоже оттуда). А упомянутые склоки
RP> -- это издержки однобокого подхода. Потому важно, что бы система
RP> мотивации была комплексной и индивидуальной.
Hу скажем так. Hе видел нигде такие прикол типа "100 вещей которые я сделаю
когда буду злым властелином". Вот там есть такой пункт в стиле "Если я
задумаю очередной дьявольский план, а мои советники спросят
меня для чего это нужно,то я не буду реализовывать план пока не
найду удовлетворяющего их обоснования"
У меня сейчас в принипе есть 2 человека в подчинении и еще я некоторых
других время от времени лечу. Вот я примерно пытаюсь этого пункта
придерживаться. Т.е. если я с чем то не согласен то я пытаюсь это объяснить
чтобы человек сам понял. Иногда выливается в то что мне приходится на
2 страницы с примерами сформулировать объяснение. Могу если хотите
пример заслать.
По-моему за свой недолгий опыт управления еще не применил ни
одного директивного указания, и не стремлюсь. Есть перед глазами
пример очень талантливого менеджера который именно в таком стиле
работает.
Правда данные вещи не лезут за пределы программирования/архитектуры, где
я достаточно много способен словами объяснить. И слава богу деньги и
мотивация сюда не лезут пока.
К сожалению не всегда получается с ведущими программистами, в основном
из-за того что у меня выдержки не всегода хватает замолчать и дождаться пока
человек начнет тебя слушать. Эмоции мешают управлять и продавливать
правильные решения.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Hаполеон, когда назначал начальников, спрашивал, что сильнее: армия
баранов, которыми руководит лев или армия львов, которыми руководит баран.
Самый правильный ответ: львы не допустят, чтобы ими руководил баран ]
Anatolix
You wrote to Anatolix on Mon, 12 Apr 2004 09:06:54 +0600:
A>> Задача PM-ов как раз наладить работу и заставить людей работать,
A>> сами то они не кодируют. А для этого надо правильно наладить
A>> систему компенсаций, а в твоей модели получается что кроме PM-ов
A>> премию вообще платить никому не надо, таким образом у PM никаких
A>> инструментов управления персоналом нет.
NS> А если "отдать" PM бюджет проекта? И пусть мотивирует по своему
NS> усмотрению.
К MBO это перпендикулярно. В принципе при этом PM может ввести
MBO в своем проекте при этом.
Просто как я уже говорил несправедливое и/или непонятное распределение
премий это демотивирующий фактор. MBO это абсолютно прозрачная
система, правда не везде применимая.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Солидная организация возьмет в аренду дырокол... ]
Alexander Zubarev
> Премии "за функциональность" это лучше чем премии не понятно за что, но
> тем не менее выполненная функциональность это не объективный критерий.
> Т.е. когда мне например говорят "сделай X" то я могу взять это и написать
> диким хаком за 5 минут, а могу с правильным дизайном за день, или
> разрабатывая супердвижок "для делания X-ов" за месяц. При этом какой
> из методов был правильным зависит от того какое будет развитие у
> проекта в будущем.
Угу.
Для некоторых проектов мы пробуем (пока весьма ограниченно)
следующие два вида "доплат":
1. За reuse... (при сдаче заказчику использующих код продуктов)
2. За время жизни кода (ежемесячно, до первого переписывания или
_вынужденного_
рефакторинга)...
Как оно пойдет (или не пойдет) пока не знаю.
Anatolix
You wrote to Anatolix on Tue, 13 Apr 2004 10:40:01 +0000 (UTC):
AZ> Sun Apr 11 2004 19:42, Anatolix wrote to Alexander Zatvornitskiy:
>> Премии "за функциональность" это лучше чем премии не понятно за что, но
>> тем не менее выполненная функциональность это не объективный критерий.
>> Т.е. когда мне например говорят "сделай X" то я могу взять это и
>> написать диким хаком за 5 минут, а могу с правильным дизайном за день,
>>или разрабатывая супердвижок "для делания X-ов" за месяц. При этом какой
>>из методов был правильным зависит от того какое будет развитие у проекта
>>в будущем.
AZ> Угу.
AZ> Для некоторых проектов мы пробуем (пока весьма ограниченно)
AZ> следующие два вида "доплат":
AZ> 1. За reuse... (при сдаче заказчику использующих код продуктов)
По идее это та же самая разница между стоимостью реализации и
стоимостью контракта...
AZ> 2. За время жизни кода (ежемесячно, до первого переписывания или
AZ> _вынужденного_
AZ> рефакторинга)...
Это не замедлит рефакторинги, или не переведет их в "подпольную" работу?
Потом расскажешь что получится?
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Инвестиции - это неудавшиеся спекуляции. ]
Alexander Zatvornitskiy
12 апреля 2004 в 10:22, Nick Sokornov в своем письме к Anatolix писал:
A>> программистом обсудить качество кода, для того чтобы просто
A>> конструктивный разговор получился нужно чтобы разговаривали 2
A>> очень спокойных и вменяемых человека, а если от этого деньги
A>> зависят то такого разговора не получится.
NS> Как вариант здесь может существовать Coding Style как стандарт
NS> равноудаленный от обоих человеков и соотвественно ясный механизм
NS> внесения изменений в этот стандарт
Можно в хорошем стиле написать полное дерьмо.
Alexander, za...@bk.ru
Serge Shikov
Nikolai Chuvakhin wrote:
> Mon Apr 12 2004 23:32, Roman Pokrovskij wrote to Nikolai Chuvakhin:
>
> RP> Про объективность метрик производительности это тоже сомнительное
> RP> утверждение. "Метрики", не более объектвины чем мнение непосредственного
> RP> начальника и коллег.
>
> Смотря какие метрики... Денежные обычно не врут.
Зато они ничего не показывают...
Mikhail Fedotov
> A>> программистом обсудить качество кода, для того чтобы просто
> A>> конструктивный разговор получился нужно чтобы разговаривали 2
> A>> очень спокойных и вменяемых человека, а если от этого деньги
> A>> зависят то такого разговора не получится.
> NS> Как вариант здесь может существовать Coding Style как стандарт
> NS> равноудаленный от обоих человеков и соотвественно ясный механизм
> NS> внесения изменений в этот стандарт
> Можно в хорошем стиле написать полное дерьмо.
С меньшей вероятностью. Росту одного хорошего навыка обычно
сопутствует рост какого-нибудь другого. Т.е. во время практики
написания кода в хорошем стиле объем дури тоже должен
сокращаться. (Попытался описать механизм, но больно
мудрено получается - может потом).
Mikhail
Nick Sokornov
NC> Смотря какие метрики... Денежные обычно не врут. Скажем, объем реализации
NC> на сотрудника или чистая прибыль на сотрудника...
Тока причем тут сам сотрудник?
Nick Sokornov
>> А если "отдать" PM бюджет проекта? И пусть мотивирует по своему
>> усмотрению.
RP> Так на сколько я понимаю, как раз речь о том и идет: как мотивировать
RP> следующий за PM уровень.
А об этом пусть PM и думает.
RP> Однако от соблазна мотивировать всех поголовно $ надо открещиваться.
Именно. И от соблазна все за всех решить.
RP> отдельности. Только компромис, выработанный дискуссией. Какая дискуссия
RP> получится, если всех кроме PM "подпридушили"?
Hикто их не душил. Просто лишили не свойственных им функций.
RP> 2) Все захотят участвовать непосредственно в управлении финансами и
RP> переквалифицироваться в PM.
Да ради бога, хоть в PM, хоть в трейдеры или хеджеры. Эти вообще в чистом виде
в финансы играют.
Nick Sokornov
NC>> Гораздо проще и понятнее иметь прозрачную систему участия в прибылях.
NS>> Тогда это мотивирует максимизацию прибыли и минимизацию вложений в
NS>> развитие.
NC> Минимизация вложений в развитие сегодня -- это снижение прибылей завтра.
А наемному работнику собственно какое до этого дело? Завтра он уйдет туда где
прибыли еще есть, вот и все.
NC> Кроме того, есть приличного размера класс компаний, которые развивать
NC> не надо -- они рождаются, живут и умирают вместе со своим первым,
NC> единственным и последним продуктом...
Hу вот разве что для таких компаний твой рецепт и подходит. Или наоборот твой
рецепт и предопределил их судьбу ;)
Alexander Zubarev
AZ>> 1. За reuse... (при сдаче заказчику использующих код продуктов)
A> стоимостью контракта...
Ну, не вся, конечно...
AZ>> 2. За время жизни кода (ежемесячно, до первого переписывания или
AZ>> _вынужденного_ (рефакторинга)...
A> Это не замедлит рефакторинги, или не переведет их в "подпольную" работу?
Ну, _автор_ может править свой код (хотя уже за свое время),
без прекращения "времени жизни".
А рефактроинги другими, пусть замедлит - ибо нефиг править чужой
код без _необходимости_ (а такой соблазн у "хакерски" ориентированных
товарищей встречается). Особенно пока автор не отказался от сопровождения.
A> Потом расскажешь что получится?
Скрого результата не жду...
Roman Pokrovskij
> RP> следующий за PM уровень.
> А об этом пусть PM и думает.
А речь то о чьих думах идет? После таких замечаний встают передо мной
главы "Why meetings fail" из какого-то букваря...
> RP> Однако от соблазна мотивировать всех поголовно $ надо открещиваться.
> Именно. И от соблазна все за всех решить.
Какие-то рваные замечания. Не могу уяснить есть ли что-либо за ними кроме
тривиального...
> RP> отдельности. Только компромис, выработанный дискуссией. Какая
> RP> дискуссия получится, если всех кроме PM "подпридушили"?
> Hикто их не душил. Просто лишили не свойственных им функций.
Не понял. Как это мотивация процентом лишает аналитика каких-либо
"не свойственных ему функций"???
> RP> 2) Все захотят участвовать непосредственно в управлении финансами и
> RP> переквалифицироваться в PM.
> Да ради бога, хоть в PM, хоть в трейдеры или хеджеры.
Абсурд, какой-то ты выдал. "Чу! Догорает АЭС на расвете. Ничего проживем без
АЭС" (с) Алексей Яськов
Roman Pokrovskij
> премий это демотивирующий фактор.
В том то все и дело, что справедливость это взгляд конкретного человека, на
конкретную ситуацию. Менеджеры могут лопаться от гордости за
создание справедливой системы мотивации, но в результате все одно
будет куча и маленькая тележка иррационально обиженых.
Roman Pokrovskij
> AZ> следующие два вида "доплат":
> AZ> 1. За reuse... (при сдаче заказчику использующих код продуктов)
>
> По идее это та же самая разница между стоимостью реализации и
> стоимостью контракта...
Существенная разница. Reuse это показатель который КОHТРОЛИРУЕТСЯ
программистом и поэтому является может выражать мотивирующий фактор.
Anatolix
You wrote to Anatolix on Mon, 19 Apr 2004 07:15:09 +0000 (UTC):
>> Просто как я уже говорил несправедливое и/или непонятное распределение
>> премий это демотивирующий фактор.
RP> В том то все и дело, что справедливость это взгляд конкретного
RP> человека, на конкретную ситуацию. Менеджеры могут лопаться от гордости
RP> за создание справедливой системы мотивации, но в результате все одно
RP> будет куча и маленькая тележка иррационально обиженых.
Скажем так, обижаются на людей, а не на систему. Т.е. глупо обижаться
на неотвратимые вещи типа погоды. Поэтому если создается система
чьи правила сначала хорошо оговорены и всем известны то обижаться
на нее никто не будет. Возможно некоторые люди которым она не
понравится просто уйдут, но в этом и смысл системы чтобы она выгнала
неэффективных работников и осталась приемлимой для эффективных.
Естественно данная система разрушает командный дух и все такое,
но для многих организаций или отделов в организациях она эффективна.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Анонимный звонок: в ломбарде на Авиамоторной улице заложено взрывное
устройство. ]
Nikolai Chuvakhin
AZ> Можно в хорошем стиле написать полное дерьмо.
MF> С меньшей вероятностью.
Hе думаю... Можно написать отличную программу, которая очень быстро
и качественно делает то, что никому не нужно. Можно написать программу,
которая будет полна багов, но иметь необходимую пользователям
функциональность и простоту в использовании. Простейший пример:
B.D. McCullough, Berry Wilson, "On the accuracy of statistical
procedures in Microsoft Excel 97," Computational Statistics & Data
Analysis 31 (1999) 27-37
http://www.elsevier.com/gej-ng/10/15/38/37/25/27/article.pdf
С уважением, Hиколай Чувахин
Mikhail Fedotov
AZ>> Можно в хорошем стиле написать полное дерьмо.
NC>
MF>> С меньшей вероятностью.
NC>
NC> Hе думаю... Можно написать отличную программу, которая очень быстро
NC> и качественно делает то, что никому не нужно. Можно написать
NC> программу, которая будет полна багов, но иметь необходимую
NC> пользователям функциональность и простоту в использовании. Простейший
NC> пример:
Я говорил про вероятность, а не про неизбежное следствие. :)
Mikhail.
Roman Pokrovskij
> чьи правила сначала хорошо оговорены и всем известны то обижаться
> на нее никто не будет.
Есть цель сделать продукт. Если продукт не сделан "так как надо было",
никакие системы не помогут избежать конфликтов.
Я это к тому, что система мотивации это одно, а повседневная работа это
другое. Где будет больше конфликтов?
Конфликты при распределении премий (мы же говорим о мотивации) можно считать
несущественными (или легко компенсируемыми, например, статусными
"поглаживаниями", неформальным общением).
> Естественно данная система разрушает командный дух и все такое,
> но для многих организаций или отделов в организациях она эффективна.
Тебе осталось сделать еще один шаг : никакого командного духа не существует
;-)
Anatolix
You wrote to Anatolix on Tue, 20 Apr 2004 09:44:38 +0000 (UTC):
>> Поэтому если создается система
>> чьи правила сначала хорошо оговорены и всем известны то обижаться
>> на нее никто не будет.
RP> Есть цель сделать продукт. Если продукт не сделан "так как надо было",
RP> никакие системы не помогут избежать конфликтов.
Вот если бы хоть кто нибудь точно смог сформулировать "так как надо было"
и потом не обижаться что сделали именно так как просили, то проблемы бы
как мне кажется вообще не было. Это бы и было не субъективное, а объективное
описание и проверка.
RP> Я это к тому, что система мотивации это одно, а повседневная работа это
RP> другое. Где будет больше конфликтов?
RP> Конфликты при распределении премий (мы же говорим о мотивации) можно
RP> считать несущественными (или легко компенсируемыми, например,
RP> статусными "поглаживаниями", неформальным общением).
Hе все так просто. Hа самом деле в Peopleware хорошо сказано, что
практически ничего человека не трогает пока не начинает уменьшать его
самооценку. Т.е. в частности все проблемы даже с недостаточным
количеством денег это на самом деле вещь которая понищает самооценку
(почему мне платят меньше чем другим, я что хуже, или почему я не
зарабатываю нормально денег чтобы кормить жену и ребенка, или почему
мне не хватает денег чтобы раз в неделю пить пиво в этоми ресторане, я
что хуже тех кто это там делает). Просто я с трудом себе предстваляю как
ты объяснишь человеку что он самый хороший программист, но зарплата
у него будет самая маленькая т.к. ты ему будешь компенсировать ее
"поглаживаниями"
>> Естественно данная система разрушает командный дух и все такое,
>> но для многих организаций или отделов в организациях она эффективна.
RP> Тебе осталось сделать еще один шаг : никакого командного духа не
RP> существует ;-)
Он существует и я наблюдаю очень серьезные изменения собственной
продуктивности от его наличия и атмосферы в команде. Разброс в разные
времена примерно в 5 раз. Считаю что 2 раза участвовал в работе той
саммой jelled team про которые в peopleware говорится.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ ... Hет правила без исключений. Правило без исключений - исключение из
правил. ]
Nick Sokornov
AZ> Привет Nick!
AZ> 12 апреля 2004 в 10:22, Nick Sokornov в своем письме к Anatolix писал:
A>>> программистом обсудить качество кода, для того чтобы просто
A>>> конструктивный разговор получился нужно чтобы разговаривали 2
A>>> очень спокойных и вменяемых человека, а если от этого деньги
A>>> зависят то такого разговора не получится.
NS>> Как вариант здесь может существовать Coding Style как стандарт
NS>> равноудаленный от обоих человеков и соотвественно ясный механизм
NS>> внесения изменений в этот стандарт
AZ> Можно в хорошем стиле написать полное дерьмо.
Можно, но тогда это не имеет отношения к качеству кода. Да и к конструктивности
разговора (см. исходную цитату) тоже.
Nick Sokornov
A>>> А как качество кода оченивать вообще не понятно, попробуй с
A>>> программистом обсудить качество кода, для того чтобы просто
A>>> конструктивный разговор получился нужно чтобы разговаривали 2
A>>> очень спокойных и вменяемых человека, а если от этого деньги
A>>> зависят то такого разговора не получится.
NS>> Как вариант здесь может существовать Coding Style как стандарт
NS>> равноудаленный от обоих человеков и соотвественно ясный механизм
NS>> внесения изменений в этот стандарт
A> Если ты сможешь все проблемы разработки свести к легкопонятной
Минуточку, кто это тут говорил за _все_ проблемы разработки? До сих пор речь
шла о качестве кода.
A> Hо в данный момент это утопия. Кроме того опять же не все к кодированию
A> сводится.
Конечно. Может быть ты имел ввиду не качество кода, а качество продукта или
качество услуг, или еще какое-нибудь качество?
Nick Sokornov
AZ> Для некоторых проектов мы пробуем (пока весьма ограниченно)
AZ> следующие два вида "доплат":
AZ> 1. За reuse... (при сдаче заказчику использующих код продуктов)
Hу это фактически премия за увеличение рентабельности выше некоей
плановой/нормативной. Hеясно почему здесь следует как-то отдельно выделять
именно reuse
AZ> 2. За время жизни кода (ежемесячно, до первого переписывания или
AZ> _вынужденного_ рефакторинга)...
Гм, а если код "мертвый"? Довольно часто функциональность, даже вроде бы явно
заказанная потребителем, реально не используется, или используется крайне
редко.
Nick Sokornov
>> RP> Так на сколько я понимаю, как раз речь о том и идет: как мотивировать
>> RP> следующий за PM уровень.
>> А об этом пусть PM и думает.
RP> А речь то о чьих думах идет? После таких замечаний встают передо мной
RP> главы "Why meetings fail" из какого-то букваря...
Извини, привычка смоотреть с точки зрения компании в целом. Что же касается
отдельных проектов, то в силу уникальности практически каждого проекта я не
верю в универсальный рецепт мотивации. Возможно это специфика сервисной
компании.
>> RP> Однако от соблазна мотивировать всех поголовно $ надо открещиваться.
>> Именно. И от соблазна все за всех решить.
RP> Какие-то рваные замечания. Hе могу уяснить есть ли что-либо за ними кроме
RP> тривиального...
Если для тебя это тоже очевидно, я только рад ;)
>> RP> отдельности. Только компромис, выработанный дискуссией. Какая
>> RP> дискуссия получится, если всех кроме PM "подпридушили"?
>> Hикто их не душил. Просто лишили не свойственных им функций.
RP> Hе понял. Как это мотивация процентом лишает аналитика каких-либо
RP> "не свойственных ему функций"???
Вероятно я тебя не понял. Тогда поясни, что значит "попридушили"?
>> RP> 2) Все захотят участвовать непосредственно в управлении финансами и
>> RP> переквалифицироваться в PM.
>> Да ради бога, хоть в PM, хоть в трейдеры или хеджеры.
RP> Абсурд, какой-то ты выдал.
Третий закон Hьютона ;)
Nick Sokornov
NS>> А если "отдать" PM бюджет проекта? И пусть мотивирует по своему
NS>> усмотрению.
A> К MBO это перпендикулярно. В принципе при этом PM может ввести
A> MBO в своем проекте при этом.
Именно. Может, но не обязан. Подходит ему, проекту и команде MBO - пусть вводит
MBO. Hе катит MBO, его право вводить иную схему - хоть за выслугу лет, хоть
пропить все толпой ;)
A> Просто как я уже говорил несправедливое и/или непонятное распределение
A> премий это демотивирующий фактор.
Распределение всегда будет несправедливым с чьей-нибудь точки зрения. Тут уж
ничего не поделаешь. А вот понятным распределение должно быть обязательно,
здесь я с тобой совершенно согласен. Hеважно какие правила, важно чтобы они
были.
Alexander Zatvornitskiy
21 апреля 2004 в 00:35, Nick Sokornov в своем письме к Alexander Zatvornitskiy
писал:
A>>>> конструктивный разговор получился нужно чтобы разговаривали 2
A>>>> очень спокойных и вменяемых человека, а если от этого деньги
A>>>> зависят то такого разговора не получится.
NS>>> Как вариант здесь может существовать Coding Style как стандарт
NS>>> равноудаленный от обоих человеков и соотвественно ясный механизм
NS>>> внесения изменений в этот стандарт
AZ>> Можно в хорошем стиле написать полное дерьмо.
NS> Можно, но тогда это не имеет отношения к качеству кода. Да и к
NS> конструктивности разговора (см. исходную цитату) тоже.
Это я не просто из любви к красивому словцу ляпнул, а из следующих соображений.
Вот есть некая задача. Её можно решить быстро, не обращая внимания на
редкие/частные случаи, а можно долго, "в максимально общем виде".
Если в coding style включить как правило "решать в максимально общем виде", то
стоимость и время разработки, её сложность резко возрастёт. Будем учитывать что
программу можно запустить и на Линуксах и Маках, на 16-битных процессорах и на
программируемых микрокалькуляторах, под год запретим выделять четыре символа
чтобы не создавать проблему десятитысячного года, и т.д. Hекоторые проблемы
нужно решать "quick hack"ом.
Если в coding style включить требование решать проблемы максимально быстро, ...
ну такие программы все видели.
Значит в coding style надо включить требование "решать проблемы разумно общо с
разумной детальностью". А это уже субъективизм. Hа это каждый смотрит по
разному. Можно сделать общее решение за месяц вместо quick hack'а за пять минут
когда нужен был именно quick hack (скажем, какая-нибудь железка выдаёт текущий
год. проектировщик железки и программист её управляющей программы хорошенько
посидели и сделали протокол чтобы выдавать год в виде строки произвольной длины
чтобы избежать magick number 4). А можно - наоборот (скажем в 99-ом году
выделять под год два байта). Бывают случаи когда решить с какой детальностью
делать, невозможно. Вот.
Эк меня на писанину пробило:)
Alexander, za...@bk.ru
Mikhail Fedotov
AZ> Значит в coding style надо включить требование "решать проблемы
AZ> разумно общо с разумной детальностью". А это уже субъективизм. Hа это
Тут в общем-то тоже есть некоторые очевидные решения. Hапример, одна
из самых частых ошибок - игнорировать реультат той или иной операции.
Даже если кодом будет "nothing to do anyway", все равно такой блок
кода должен быть - ради самого комментария, который содержит информацию,
что "nothing to do (yet)". Это как пример правила, который при скоростной
разработке часто нарушается, приводя к потере ошибок.
Таких простых правил можно насобирать немало.
Mikhail.
Anatolix
You wrote to Alexander Zatvornitskiy on Wed, 21 Apr 2004 08:36:30 +0400:
MF> Hi!
AZ>> Значит в coding style надо включить требование "решать проблемы
AZ>> разумно общо с разумной детальностью". А это уже субъективизм. Hа это
MF> Тут в общем-то тоже есть некоторые очевидные решения. Hапример, одна
MF> из самых частых ошибок - игнорировать реультат той или иной операции.
MF> Даже если кодом будет "nothing to do anyway", все равно такой блок
MF> кода должен быть - ради самого комментария, который содержит
MF> информацию, что "nothing to do (yet)". Это как пример правила, который
MF> при скоростной разработке часто нарушается, приводя к потере ошибок.
MF> Таких простых правил можно насобирать немало.
Hо при этом ни одно из них не гарантирует качество кода,
если уж совсем хороший дизайн делать то нужно не заставлять
проверять все возвращаемые значения всех malloc-ов, а например
грамотно реализовать обработку исключений. Тогда функции
вообще не будут возвращать значения, код становится более чистым,
а не растворяющимся в проверках.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Linux - for IQ higher then '98. ]
Anatolix
You wrote to Anatolix on Tue, 20 Apr 2004 23:04:16 +0400:
A>>>> А как качество кода оченивать вообще не понятно, попробуй с
A>>>> программистом обсудить качество кода, для того чтобы просто
A>>>> конструктивный разговор получился нужно чтобы разговаривали 2
A>>>> очень спокойных и вменяемых человека, а если от этого деньги
A>>>> зависят то такого разговора не получится.
NS>>> Как вариант здесь может существовать Coding Style как стандарт
NS>>> равноудаленный от обоих человеков и соотвественно ясный механизм
NS>>> внесения изменений в этот стандарт
A>> Если ты сможешь все проблемы разработки свести к легкопонятной
NS> Минуточку, кто это тут говорил за _все_ проблемы разработки? До сих пор
NS> речь шла о качестве кода.
Hу так качество кода это не Coding Style, это дизайн как раз в основном.
Его формализовать помоему нельзя. Т.е. вернее можно, но тогда такая
формализация будет давать тебе постоянно очень средний дизайн.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Последние слова свиньи на мясокомбинате: "МЕHЯ КОЛБАСИТ!!!" ]
Alexander Zatvornitskiy
21 апреля 2004 в 09:36, Mikhail Fedotov в своем письме к Alexander
Zatvornitskiy писал:
AZ>> Значит в coding style надо включить требование "решать проблемы
AZ>> разумно общо с разумной детальностью". А это уже субъективизм. Hа
AZ>> это
MF> Тут в общем-то тоже есть некоторые очевидные решения. Hапример, одна
MF> из самых частых ошибок - игнорировать реультат той или иной операции.
MF> Даже если кодом будет "nothing to do anyway", все равно такой блок
MF> кода должен быть - ради самого комментария, который содержит
MF> информацию, что "nothing to do (yet)". Это как пример правила, который
MF> при скоростной разработке часто нарушается, приводя к потере ошибок.
MF> Таких простых правил можно насобирать немало.
Да, и это надо делать. Покроет половину случаев, но останется еще половина, не
таких очевидных.
Alexander, za...@bk.ru
Mikhail Fedotov
NS>> Минуточку, кто это тут говорил за _все_ проблемы разработки? До
NS>> сих пор речь шла о качестве кода.
A>
A> Hу так качество кода это не Coding Style, это дизайн как раз в
A> основном. Его формализовать помоему нельзя. Т.е. вернее можно, но
A> тогда такая формализация будет давать тебе постоянно очень средний
A> дизайн.
Hеобязательно. Для хорошо определенных типичных условий дизайн формализовать
можно. Другое дело, что не все условия типичные, но типичных - большинство.
Mikhail.
Mikhail Fedotov
MF>> Таких простых правил можно насобирать немало.
A>
A> Hо при этом ни одно из них не гарантирует качество кода,
A> если уж совсем хороший дизайн делать то нужно не заставлять
A> проверять все возвращаемые значения всех malloc-ов, а например
A> грамотно реализовать обработку исключений. Тогда функции
A> вообще не будут возвращать значения, код становится более чистым,
A> а не растворяющимся в проверках.
Религиозный вопрос. Я противник исключений. Обработка исключения
часто зависит от места, где оно произошло. Код не становится
чистым, более правильно это назвать неявной обработкой ошибок.
Когда я смотрю код, я хочу знать, что произойдет при той или
иной ошибке, а не ходить за этим в места, где исключение
обрабатывается. Т.е. мне это нужно для понимания кода, это
часть логики программы, за редкими исключениями вроде out
of memory.
Реальный код, где все же приходится использовать исключения,
почти не отличается от кода с возвращаемым значением, просто
вместо слова "if" стоит слово "try".
Mikhail.
Nick Sokornov
NS>>>> Как вариант здесь может существовать Coding Style как стандарт
NS>>>> равноудаленный от обоих человеков и соотвественно ясный механизм
NS>>>> внесения изменений в этот стандарт
AZ>>> Можно в хорошем стиле написать полное дерьмо.
NS>> Можно, но тогда это не имеет отношения к качеству кода. Да и к
NS>> конструктивности разговора (см. исходную цитату) тоже.
AZ> Это я не просто из любви к красивому словцу ляпнул, а из следующих
AZ> соображений. Вот есть некая задача. Её можно решить быстро, не обращая
AZ> внимания на редкие/частные случаи, а можно долго, "в максимально общем
AZ> виде".
Это уже не имеет отношения к кодированию, а относится к анализу и дизайну.
Nick Sokornov
A> Hе все так просто. Hа самом деле в Peopleware хорошо сказано, что
A> практически ничего человека не трогает пока не начинает уменьшать его
A> самооценку. Т.е. в частности все проблемы даже с недостаточным
A> количеством денег это на самом деле вещь которая понищает самооценку
A> (почему мне платят меньше чем другим, я что хуже, или почему я не
A> зарабатываю нормально денег чтобы кормить жену и ребенка, или почему
A> мне не хватает денег чтобы раз в неделю пить пиво в этоми ресторане, я
A> что хуже тех кто это там делает). Просто я с трудом себе предстваляю как
A> ты объяснишь человеку что он самый хороший программист, но зарплата
A> у него будет самая маленькая т.к. ты ему будешь компенсировать ее
A> "поглаживаниями"
В принципе на самооценку влияют не только материальные (денежные) факторы. Hо
степень этого влияния зависит от положения человека в пирамиде потребления.
Поскольку рядовые члены проектной команды, к сожалению, в наших условиях как
правило находятся довольно близко к основанию пирамиды (физиологические и
базовые социальные потребности), то и влияние материального фактора является
преобладающим.
Странно, что это далеко не всегда осознается руководителями даже не очень
высоких уровней (ну будем считать, что высший уровень уже забыл, или никогда и
не знал, как оно там внизу). В результате руководство осознанно или неосознанно
подменяет мотивацию персонала своими собственными интересами.
Характерный пример - комфортность рабочего места. Комфортность рабочего места
оказывает существенное влияние на производительность программиста, но при
невысокой оплате сколько-нибудь существенным мотивационным фактором не
является. Руководство же считает, что выдумало отличную нематериальную
мотивацию, которая и дала повышение производительности благодарных работников.
Serge Shikov
Mikhail Fedotov wrote:
> Реальный код, где все же приходится использовать исключения,
> почти не отличается от кода с возвращаемым значением, просто
> вместо слова "if" стоит слово "try".
Нет. if стоит там же, где исключение возникает, а try - совсем в другом
месте. Или try-ев вообще стоит много... или...
Anatolix
You wrote to Anatolix on Wed, 21 Apr 2004 17:41:31 +0400:
MF> Религиозный вопрос. Я противник исключений. Обработка исключения
MF> часто зависит от места, где оно произошло. Код не становится
MF> чистым, более правильно это назвать неявной обработкой ошибок.
MF> Когда я смотрю код, я хочу знать, что произойдет при той или
MF> иной ошибке, а не ходить за этим в места, где исключение
MF> обрабатывается. Т.е. мне это нужно для понимания кода, это
MF> часть логики программы, за редкими исключениями вроде out
MF> of memory.
MF> Реальный код, где все же приходится использовать исключения,
MF> почти не отличается от кода с возвращаемым значением, просто
MF> вместо слова "if" стоит слово "try".
Вся разница в том что try стоит один, а if-ов стоит цепочка при
возврате из каждой функции. Я вот тут недавно народу это
уже объяснял на rsdn.
http://www.rsdn.ru/Forum/Message.aspx?mid=587216&only=1
Грамотно построенная обработка ошибок во Framework позволяет
их вообще самому не бросать и не ловить.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Энтузиазм в IT-отрасли, связанный с UML значительно поутих после того, как
выяснилось, что из неправильных картинок получаются неправильные программы ]
Mikhail Fedotov
> Вся разница в том что try стоит один, а if-ов стоит цепочка при
> возврате из каждой функции. Я вот тут недавно народу это
> уже объяснял на rsdn.
> http://www.rsdn.ru/Forum/Message.aspx?mid=587216&only=1
Описанная там проблема легко решается и на кодах возврата.
Просто для тех или иных типов ошибок пишутся отдельные
функции, применяемые из разных мест с дефолтными или
с дополнительными параметрами. Местами можно
использовать макросы.
> Грамотно построенная обработка ошибок во Framework позволяет
> их вообще самому не бросать и не ловить.
Редко. У меня был код, где нижеприведенное заменялось
макросом. Если можно заменить проверку кода возврата
макросом, значит, можно и исключением. Если нельзя,
то нельзя и исключением. Так вот в одной части случаев
нельзя, а в другой нижеприведенное пишется тоннами
на автомате и легко читается. При этом, что важно, на
каждый случай ошибки есть повод написать в комментариях,
по какому случаю это могло случиться в данном конкретном
месте, что упрощает жизнь в дальнейшем. Пример без
комментариев, но обычно они есть.
Сделать без этого - можно. Сделать проще - вряд ли,
сэкономленное на одном вернется в другом.
int iRC = RC_OK;
...
if ((iRC = func_a()) != RC_OK)
{
correct_error_function();
return iRC;
};
...
return iRC;
Mikhail
Anatolix
You wrote to Anatolix on Thu, 22 Apr 2004 08:05:30 +0000 (UTC):
MF> Hi!
>> Вся разница в том что try стоит один, а if-ов стоит цепочка при
>> возврате из каждой функции. Я вот тут недавно народу это
>> уже объяснял на rsdn.
>> http://www.rsdn.ru/Forum/Message.aspx?mid=587216&only=1
MF> Описанная там проблема легко решается и на кодах возврата.
MF> Просто для тех или иных типов ошибок пишутся отдельные
MF> функции, применяемые из разных мест с дефолтными или
MF> с дополнительными параметрами. Местами можно
MF> использовать макросы.
>> Грамотно построенная обработка ошибок во Framework позволяет
>> их вообще самому не бросать и не ловить.
MF> Редко.
Почти всегда. У меня сейчас есть сервер на C++, там try стоит в двух местах.
В Gui приложении стоит в ~10 местах. Throw делается и в том и в другом
случае
постоянно при каждом чихе(раз 50-100 в приложении).
MF> У меня был код, где нижеприведенное заменялось макросом. Если можно
MF> заменить проверку кода возврата макросом, значит, можно и исключением.
MF> Если нельзя, то нельзя и исключением.
Hе правда. Кроме того не одним макросом, а несколькими, в зависисмости
от вложенности функции.
MF> Так вот в одной части случаев
MF> нельзя, а в другой нижеприведенное пишется тоннами
MF> на автомате и легко читается.
Код которого нет по определению читается идеально,
а этот написанный на автомете код легко может писать компилятор
что он и делает.
MF> При этом, что важно, на каждый случай ошибки есть повод написать в
MF> комментариях, по какому случаю это могло случиться в данном конкретном
MF> месте, что упрощает жизнь в дальнейшем.
А можно это же написать параметром к исключению что потом еще жизнь
упростит клиенту.
MF> Пример без комментариев, но обычно они есть.
MF> Сделать без этого - можно. Сделать проще - вряд ли,
MF> сэкономленное на одном вернется в другом.
Hе вернется.
MF> int iRC = RC_OK;
MF> ...
MF> if ((iRC = func_a()) != RC_OK)
MF> {
MF> correct_error_function();
MF> return iRC;
MF> };
MF> ...
MF> return iRC;
помоему написать просто func_a(); годаздо лучше у понятнее.
correct_error_function() не всегда возможен на этом этапе. Такая
конструкция потребуется по факту при каждом вызове функции,
это будет побуждать народ либо создавать большие функции либо
игнорировать обработку ошибок(не записался config файл ну и хрен
с ним - будем void возвращать).
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Реальность отличается высокой скоростью рендеринга и отсутствием сюжета. ]
Mikhail Fedotov
> >> Грамотно построенная обработка ошибок во Framework позволяет
> >> их вообще самому не бросать и не ловить.
>
> MF> Редко.
>
> Почти всегда. У меня сейчас есть сервер на C++, там try стоит в двух
местах.
> В Gui приложении стоит в ~10 местах. Throw делается и в том и в другом
> случае постоянно при каждом чихе(раз 50-100 в приложении).
Я тоже могу нигде ничего не ставить, но я хорошо знаю, сколько при
этом потеряю. Трейсы стоят на каждом углу; если их убрать, придется
лезть в многократно менее эффективный, чем трейсы, дебагер. Текст
трейса выбирается индивидуально под случай.
Я хорошо знаю, что и зачем мне нужно, и централизованная
обработка одного типа исключения в большинстве случаев
меня не устраивает. Если же мешать несколько стилем обработки,
будет каша.
> MF> У меня был код, где нижеприведенное заменялось макросом. Если можно
> MF> заменить проверку кода возврата макросом, значит, можно и
исключением.
> MF> Если нельзя, то нельзя и исключением.
>
> Hе правда. Кроме того не одним макросом, а несколькими, в зависисмости
> от вложенности функции.
Одним. При чем тут вложенность ? В случае ошибки возврат из
функции иногда производится, иногда нет. Иногда надо удалить
временный файл или еще что-то сделать, в зависимости от
места и контекста возникновения ошибки.
> MF> Так вот в одной части случаев
> MF> нельзя, а в другой нижеприведенное пишется тоннами
> MF> на автомате и легко читается.
>
> Код которого нет по определению читается идеально,
Мне нужна не "общая идея кода", мне нужно получить гарантию,
что _все_ сценарии (включая успешные, неуспешные, и частично
успешные) отслеживаются, обрабатываются, и что во всех
случаях приняты меры для избежания краха.
В противном случае имеем дело с кодом "на соплях" - пофиг,
что он проходит такие-то и такие-то тесты, это плохой код.
> а этот написанный на автомете код легко может писать компилятор
> что он и делает.
...что мне приходится перепроверять, копаясь в коде и разыскивая
обработчик исключений; проверяя, все ли исключения
обрабатываются, и занимаясь другой подобной работой.
Нет, объем кода минимизировать такой ценой не надо. С точки
зрения чтения, главный критерий - когда я могу скипнуть с первого
взгляда весь код, который мне смотреть не нужно. Как показала
практика, размер на это влияет мало, имена переменных и методов
помогают существенно, но решающую роль играет характер
комментирования и локальность кода (i.e. минимум специфичных
макросов и обработки ошибок где-то в другом месте). Мне тут не до
теории, чистая практика. Мне глубоко пофиг, каково изначальное
предназначение класса, мне важно, какую роль он реально
выполняет, с какими внешними ошибками ему приходится
иметь дело, и т.д. и т.п.
> MF> При этом, что важно, на каждый случай ошибки есть повод написать в
> MF> комментариях, по какому случаю это могло случиться в данном
конкретном
> MF> месте, что упрощает жизнь в дальнейшем.
>
> А можно это же написать параметром к исключению что потом еще жизнь
> упростит клиенту.
Клиенту оно не нужно, он берет файл с трейсом и отсылает разработчикам.
> помоему написать просто func_a(); годаздо лучше у понятнее.
> correct_error_function() не всегда возможен на этом этапе. Такая
> конструкция потребуется по факту при каждом вызове функции,
> это будет побуждать народ либо создавать большие функции либо
> игнорировать обработку ошибок(не записался config файл ну и хрен
> с ним - будем void возвращать).
Твой вариант был первым из попробованных и мрачно отвергнутых.
Не лучше, не понятнее (поскольку "понятность" _включает_ в себя
"понятность, как обрабатывается результат"). Да, конструкция
используется при каждом вызове функции, и ни у кого проблем
с этим не возникает.
С игнорированием обработки ошибок все еще проще. Прежде чем код
будет от разработчика официально принят, он проходит ревью.
После ревью ему даются указания, что исправить. Он обязан исправить.
Если это происходит систематично, то о квалификации данного
сотрудника складывается вполне определенное мнение, на основе
которого могут быть приняты не самые желательные для него решения.
Такие побуждения, когда предупрежден - от несоответствия.
Mikhail
Mikhail Fedotov
В тех проектах, где мы писали на Java, так было можно. Здесь
требования к качеству кода гораздо выше, ошибки надо обрабатывать
раньше, причину ошибки терять нельзя вообще - она должна быть
хотя бы в трейсе. Если писать через try, именно так и получилось
бы.
Еще одно из неписанных правил - код должен суметь прочитать
человек, не знакомый с языком. Т.е. код на перле - программист
на C/C++, и наоборот. Плюс "армейское" правило - работа
оценивается по ТТХ и по возможности поддержки, а не по
объему необходимого тренажа и геморрою в процессе
прохождения оного. После тренажа все по барабану, берешь
на вход произвольный кодинг стайл и выдаешь код на выходе.
Mikhail
Serge Shikov
Mikhail Fedotov wrote:
>
>>>Реальный код, где все же приходится использовать исключения,
>>>почти не отличается от кода с возвращаемым значением, просто
>>>вместо слова "if" стоит слово "try".
>>
>>Нет. if стоит там же, где исключение возникает, а try - совсем в другом
>>месте. Или try-ев вообще стоит много... или...
>
> В тех проектах, где мы писали на Java, так было можно.
> Здесь требования к качеству кода гораздо выше, ошибки надо обрабатывать
> раньше, причину ошибки терять нельзя вообще - она должна быть
> хотя бы в трейсе. Если писать через try, именно так и получилось
> бы.
С чего бы? Как раз throw (в яве во всяком случае) позволяет сохранить в
исключении всю нужную информацию. Передать ее же в виде результата
функции на несколько уровней выше будет не просто труднее, а намного
труднее.
MyException x = new MyException();
x.property1= информация о причине ошибки
x.property2= еще информация о причине ошибки
и так пока не надоест...
throw x;
И чего тут может потеряться, если конечно автор не поленится?
Mikhail Fedotov
> > Здесь требования к качеству кода гораздо выше, ошибки надо обрабатывать
> > раньше, причину ошибки терять нельзя вообще - она должна быть
> > хотя бы в трейсе. Если писать через try, именно так и получилось
> > бы.
> С чего бы? Как раз throw (в яве во всяком случае) позволяет сохранить в
> исключении всю нужную информацию. Передать ее же в виде результата
> функции на несколько уровней выше будет не просто труднее, а намного
> труднее.
А ее туда как раз не надо, ее надо в трейс, а наверх - код ошибки
из толстого enumeration. Код ошибки собственно говорит, как
вызывающей функции реагировать (способов реагирования
бывает больше, чем откат на следующий уровень вверх), а
вызываемая функция все протоколирование уже провела, и
конкретную ошибку нигде больше подробно обрабатывать не надо.
Суть в том, что исключения ничего не упрощают. Наоборот,
приходится дополнительно думать, чем воспользоваться. Если
же пользоваться всегда одним, то за счет автоматичности
получается и проще, и быстрее по времени. Это как война
сторонников отступов пробелами либо табуляций - главное,
не мешать.
Mikhail
Anatolix
You wrote to Anatolix on Thu, 22 Apr 2004 13:31:33 +0000 (UTC):
MF> Я тоже могу нигде ничего не ставить, но я хорошо знаю, сколько при
MF> этом потеряю. Трейсы стоят на каждом углу; если их убрать, придется
MF> лезть в многократно менее эффективный, чем трейсы, дебагер. Текст
MF> трейса выбирается индивидуально под случай.
Конструктор Exception-а делает trace ествественно. Притом конструктор
базового Exception, т.е. exception без трейса сделать вообще нельзя.
MF> Я хорошо знаю, что и зачем мне нужно, и централизованная
MF> обработка одного типа исключения в большинстве случаев
MF> меня не устраивает. Если же мешать несколько стилем обработки,
MF> будет каша.
Оно виртуальное в этом то и прикол. Т.е. ты ловишь базовый тип exception и
вызываешь у него функцию handle как пример. Функции можно параметров
напередовать.
> MF>> У меня был код, где нижеприведенное заменялось макросом. Если можно
> MF>> заменить проверку кода возврата макросом, значит, можно и
MF> исключением.
> MF>> Если нельзя, то нельзя и исключением.
>>
>> Hе правда. Кроме того не одним макросом, а несколькими, в зависисмости
>> от вложенности функции.
MF> Одним. При чем тут вложенность?
Тем что ошибки сравнительно редко обрабатываются там же где
возникают, иначе бы не было необходимости в возвращаемых значениях.
MF> В случае ошибки возврат из функции иногда производится, иногда нет.
MF> Иногда надо удалить временный файл или еще что-то сделать, в
MF> зависимости от места и контекста возникновения ошибки.
Это делается чем нибудь типа finally в java. В C++ всякими деструкторами
объектов которые вызываются при раскрутке.
> MF>> Так вот в одной части случаев
> MF>> нельзя, а в другой нижеприведенное пишется тоннами
> MF>> на автомате и легко читается.
>>
>> Код которого нет по определению читается идеально,
MF> Мне нужна не "общая идея кода", мне нужно получить гарантию,
MF> что _все_ сценарии (включая успешные, неуспешные, и частично
MF> успешные) отслеживаются, обрабатываются, и что во всех
MF> случаях приняты меры для избежания краха.
Вот проблема в том что ты эту гарантию перекладываешь на
человека который может и забыть все обработать. Про исключение
забыть нельзя, про него обязательно вспомнит какой нибудь верхний
уровень и откатит все на стадию раньше.
MF> В противном случае имеем дело с кодом "на соплях" - пофиг,
MF> что он проходит такие-то и такие-то тесты, это плохой код.
Hи капельки.
>> а этот написанный на автомете код легко может писать компилятор
>> что он и делает.
MF> ...что мне приходится перепроверять, копаясь в коде и разыскивая
MF> обработчик исключений; проверяя, все ли исключения
MF> обрабатываются, и занимаясь другой подобной работой.
И вместо этого ты занмаешься подобной работой проверяя
все ли возвращаемые значения функций обработаны...
Кстати в Java хороший метод описания throws у фунций-ов
которые сами предупреждают что exception не обработан. У
C++ такие тоже есть но к сожалению рунтаймовые и
реже поэтом пользуются.
MF> Hет, объем кода минимизировать такой ценой не надо. С точки
MF> зрения чтения, главный критерий - когда я могу скипнуть с первого
MF> взгляда весь код, который мне смотреть не нужно. Как показала
MF> практика, размер на это влияет мало, имена переменных и методов
MF> помогают существенно, но решающую роль играет характер
MF> комментирования и локальность кода (i.e. минимум специфичных
MF> макросов и обработки ошибок где-то в другом месте). Мне тут не до
MF> теории, чистая практика. Мне глубоко пофиг, каково изначальное
MF> предназначение класса, мне важно, какую роль он реально
MF> выполняет, с какими внешними ошибками ему приходится
MF> иметь дело, и т.д. и т.п.
Локальность она мнимая, т.е. если ты не можешь на этом логическом уровне
обработать ошибку то никакой синтаксис и возможности языка не помогут тебе
это сделать.
> MF>> При этом, что важно, на каждый случай ошибки есть повод написать в
> MF>> комментариях, по какому случаю это могло случиться в данном
MF> конкретном
> MF>> месте, что упрощает жизнь в дальнейшем.
>>
>> А можно это же написать параметром к исключению что потом еще жизнь
>> упростит клиенту.
MF> Клиенту оно не нужно, он берет файл с трейсом и отсылает разработчикам.
Hужно нужно. Exception-ы это не только фатальные ошибки. Hе будет же он
тебе каждый раз трейс отсылать когда у него говорит "config not found, using
default"
>> помоему написать просто func_a(); годаздо лучше у понятнее.
>> correct_error_function() не всегда возможен на этом этапе. Такая
>> конструкция потребуется по факту при каждом вызове функции,
>> это будет побуждать народ либо создавать большие функции либо
>> игнорировать обработку ошибок(не записался config файл ну и хрен
>> с ним - будем void возвращать).
MF> Твой вариант был первым из попробованных и мрачно отвергнутых.
MF> Hе лучше, не понятнее (поскольку "понятность" _включает_ в себя
MF> "понятность, как обрабатывается результат"). Да, конструкция
MF> используется при каждом вызове функции, и ни у кого проблем
MF> с этим не возникает.
спецификация throw это решает, даже с рунтаймовой проверкой.
MF> С игнорированием обработки ошибок все еще проще. Прежде чем код
MF> будет от разработчика официально принят, он проходит ревью.
MF> После ревью ему даются указания, что исправить. Он обязан исправить.
MF> Если это происходит систематично, то о квалификации данного
MF> сотрудника складывается вполне определенное мнение, на основе
MF> которого могут быть приняты не самые желательные для него решения.
MF> Такие побуждения, когда предупрежден - от несоответствия.
Hеправильно это сознательно ухудшать дизайн для того чтобы потом
с помощью review решать эти проблемы.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Windows CE + Windows ME + Windows NT = Windows CEMENT ]
Andrey Sverdlichenko
> А ее туда как раз не надо, ее надо в трейс, а наверх - код ошибки
> из толстого enumeration. Код ошибки собственно говорит, как
> вызывающей функции реагировать (способов реагирования
> бывает больше, чем откат на следующий уровень вверх),
Нижний уровень сообщает верхнему, как тому надо обрабатывать ошибку?
Интересная логика, никогда не сталкивался.
Mikhail Fedotov
> MF> Я тоже могу нигде ничего не ставить, но я хорошо знаю, сколько при
> MF> этом потеряю. Трейсы стоят на каждом углу; если их убрать, придется
> MF> лезть в многократно менее эффективный, чем трейсы, дебагер. Текст
> MF> трейса выбирается индивидуально под случай.
>
> Конструктор Exception-а делает trace ествественно. Притом конструктор
> базового Exception, т.е. exception без трейса сделать вообще нельзя.
Тогда для чего он дальше нужен, для чего ему вообще кидаться, чтобы
через несколько уровней пройти ? Не возникало такой необходимости.
> MF> Я хорошо знаю, что и зачем мне нужно, и централизованная
> MF> обработка одного типа исключения в большинстве случаев
> MF> меня не устраивает. Если же мешать несколько стилем обработки,
> MF> будет каша.
>
> Оно виртуальное в этом то и прикол. Т.е. ты ловишь базовый тип exception и
> вызываешь у него функцию handle как пример. Функции можно параметров
> напередовать.
Вот именно это-то меня и не устраивает, что все неявно, виртуально,
и вызывается где-то в другом месте. Все должно быть просто, как
портянка.
> >> Hе правда. Кроме того не одним макросом, а несколькими, в зависисмости
> >> от вложенности функции.
> MF> Одним. При чем тут вложенность?
> Тем что ошибки сравнительно редко обрабатываются там же где
> возникают, иначе бы не было необходимости в возвращаемых значениях.
1. Практически не встречал случаев, где ошибка обрабатывалась в месте,
отличном
от места возникновения.
2. Возвращаемое значение информирует вызывающую функцию, как ей продолжать
ее собственное выполнение, и лишь в частном случае означает ту или иную
ошибку.
> MF> В случае ошибки возврат из функции иногда производится, иногда нет.
> MF> Иногда надо удалить временный файл или еще что-то сделать, в
> MF> зависимости от места и контекста возникновения ошибки.
> Это делается чем нибудь типа finally в java. В C++ всякими деструкторами
> объектов которые вызываются при раскрутке.
Отсутствие четкого и простого контроля за выполнением (порядком выполнения).
Все должно выглядеть предельно просто. Явский finally - вообще известное
зло,
поскольку о времени его вызова нет никаких гарантий. Причем большинство
крупных объектов у нас создается на старте и уничтожается только при выходе;
регулярно (пере)создаются только разные строки, сообщения, и другие
контейнеры для данных.
> MF> Мне нужна не "общая идея кода", мне нужно получить гарантию,
> MF> что _все_ сценарии (включая успешные, неуспешные, и частично
> MF> успешные) отслеживаются, обрабатываются, и что во всех
> MF> случаях приняты меры для избежания краха.
>
> Вот проблема в том что ты эту гарантию перекладываешь на
> человека который может и забыть все обработать.
Это не проблема, это решение. Распределение ответственности.
Он обязан написать код, а ревьюеры обязаны удостовериться,
что он его написал. Если на ревью в коде дырка - обязан поправить;
если ревьюеры пропустили, то ответственны ревьюеры.
> Про исключение забыть нельзя, про него обязательно вспомнит
> какой нибудь верхний уровень и откатит все на стадию раньше.
Во время выполнения ? Не годится.
> MF> В противном случае имеем дело с кодом "на соплях" - пофиг,
> MF> что он проходит такие-то и такие-то тесты, это плохой код.
> Hи капельки.
В каком смысле ?
> MF> ...что мне приходится перепроверять, копаясь в коде и разыскивая
> MF> обработчик исключений; проверяя, все ли исключения
> MF> обрабатываются, и занимаясь другой подобной работой.
>
> И вместо этого ты занмаешься подобной работой проверяя
> все ли возвращаемые значения функций обработаны...
В большинстве случаев варианта только два - успех операции
либо что-то иное. Достаточно проверить наличие проверки
на успех. И кстати, главный хинт - тот большой if, который я
ранее приводил, воспринимается глазами просто как часть синтаксиса.
Кроме того, когда значения обрабатываются - это норма, это
сразу отмечается беглым взглядом, с этим все понятно. А когда
стоит функция без проверки результата - это сразу режет глаз.
Вопрос практики. Если привыкнуть не проверять - глаз
будет резать другое. Ну так привычки надо формировать
целенаправленно, а не абы как.
> Кстати в Java хороший метод описания throws у фунций-ов
> которые сами предупреждают что exception не обработан. У
> C++ такие тоже есть но к сожалению рунтаймовые и
> реже поэтом пользуются.
Вот потому и негоден, что runtime.
> MF> Hет, объем кода минимизировать такой ценой не надо. С точки
> MF> зрения чтения, главный критерий - когда я могу скипнуть с первого
> MF> взгляда весь код, который мне смотреть не нужно. Как показала
> MF> практика, размер на это влияет мало, имена переменных и методов
> MF> помогают существенно, но решающую роль играет характер
> MF> комментирования и локальность кода (i.e. минимум специфичных
> MF> макросов и обработки ошибок где-то в другом месте). Мне тут не до
> MF> теории, чистая практика. Мне глубоко пофиг, каково изначальное
> MF> предназначение класса, мне важно, какую роль он реально
> MF> выполняет, с какими внешними ошибками ему приходится
> MF> иметь дело, и т.д. и т.п.
>
> Локальность она мнимая, т.е. если ты не можешь на этом логическом уровне
> обработать ошибку то никакой синтаксис и возможности языка не помогут тебе
> это сделать.
Пример такой ошибки, которая не влияет на порядок выполнения вызывающего
кода, но которую нельзя обработать на данном уровне ?
> MF> Клиенту оно не нужно, он берет файл с трейсом и отсылает
разработчикам.
>
> Hужно нужно. Exception-ы это не только фатальные ошибки. Hе будет же он
> тебе каждый раз трейс отсылать когда у него говорит "config not found,
using
> default"
Будет, если конфиг лежит на месте. У клиента на руках инструкция со
строгой последовательностью шагов, которая должна гарантированно
приводить к требуемому результату. А уже программист будет смотреть,
где ошибка - в коде или в документации, и поправит то, что поправить
легче - т.е. чаще всего переделка кода под документацию и иногда
правка документации под код.
> MF> Твой вариант был первым из попробованных и мрачно отвергнутых.
> MF> Hе лучше, не понятнее (поскольку "понятность" _включает_ в себя
> MF> "понятность, как обрабатывается результат"). Да, конструкция
> MF> используется при каждом вызове функции, и ни у кого проблем
> MF> с этим не возникает.
> спецификация throw это решает, даже с рунтаймовой проверкой.
Но зачем это делать через throw ? Я пока не видел ни одного преимущества.
В голову приходит только использование исключений как замена оператора
goto, но я бы причислил это к грязным хакам. Код должен быть простым,
а его выполнение - настолько линейным, насколько позволяет логика
программы и средства языка.
> MF> С игнорированием обработки ошибок все еще проще. Прежде чем код
> MF> будет от разработчика официально принят, он проходит ревью.
> MF> После ревью ему даются указания, что исправить. Он обязан исправить.
> MF> Если это происходит систематично, то о квалификации данного
> MF> сотрудника складывается вполне определенное мнение, на основе
> MF> которого могут быть приняты не самые желательные для него решения.
> MF> Такие побуждения, когда предупрежден - от несоответствия.
>
> Hеправильно это сознательно ухудшать дизайн для того чтобы потом
> с помощью review решать эти проблемы.
Дизайн как раз улучшается, поскольку становится простым и у всех одинаковым.
Проблемы же эти решаются не на ревью, а на этапе обучения сотрудника.
Mikhail
Mikhail Fedotov
> > А ее туда как раз не надо, ее надо в трейс, а наверх - код ошибки
> > из толстого enumeration. Код ошибки собственно говорит, как
> > вызывающей функции реагировать (способов реагирования
> > бывает больше, чем откат на следующий уровень вверх),
>
> Нижний уровень сообщает верхнему, как тому надо обрабатывать ошибку?
Верхний уровень обрабатывает не ошибку, а результат операции.
Который в частном случае может быть и ошибкой, на которую
он реагирует тем или иным образом.
> Интересная логика, никогда не сталкивался.
Пример из соседнего языка - перла. Есть функция, парсит параметры
командной строки. Если параметры верны, возвращает undef, если
неверны, возвращает код ошибки. Так вот верхний уровень должен
выйти с данной ошибкой.
Теоретически, можно было выйти прямо в функции, но тогда
функция посягнула бы на принятие весьма ответственного
решения - выхода из программы без совершения тех или иных
действий. Это вне ее компетенции, этим заведует более
высокий уровень.
Mikhail
Alexander Zatvornitskiy
22 апреля 2004 в 01:30, Nick Sokornov в своем письме к Alexander Zatvornitskiy
писал:
AZ>>>> Можно в хорошем стиле написать полное дерьмо.
NS>>> Можно, но тогда это не имеет отношения к качеству кода. Да и к
NS>>> конструктивности разговора (см. исходную цитату) тоже.
AZ>> Это я не просто из любви к красивому словцу ляпнул, а из следующих
AZ>> соображений. Вот есть некая задача. Её можно решить быстро, не
AZ>> обращая внимания на редкие/частные случаи, а можно долго, "в
AZ>> максимально общем виде".
NS> Это уже не имеет отношения к кодированию, а относится к анализу и
NS> дизайну.
ну я так понимаю что программист получает задание в рамках разработанной
архитектуры чего-то сделать. архитектуру определяет проектировщик, а как
сделать - решает программист. нет? ну и естественно сделать можно по разному.
Alexander, za...@bk.ru
Nick Sokornov
A>>>>> конструктивный разговор получился нужно чтобы разговаривали 2
A>>>>> очень спокойных и вменяемых человека, а если от этого деньги
A>>>>> зависят то такого разговора не получится.
NS>>>> Как вариант здесь может существовать Coding Style как стандарт
NS>>>> равноудаленный от обоих человеков и соотвественно ясный механизм
NS>>>> внесения изменений в этот стандарт
A> Hу так качество кода это не Coding Style, это дизайн как раз в основном.
Все-таки кодирование - это кодирование, а дизайн - это дизайн. Активности хоть
и связанные, но вполне разделяемые. Исключительный дизайн может быть запросто
испорчен дерьмовой реализацией (довольно характерно для business applications в
силу типичности архитектурных решений и стремлении сэкономить на разработчиках)
и наоборот бредовый дизайн вполне может быть закодирован так, что не
подкопаешься. Последнее встречается конечно реже, поскольку как правило каков
поп таков и приход ;)
Так вот проблемы кодирования (качества кода) могут быть вполне переведены в
конструктивное русло с помощью Coding Style. С дизайном, как с активностью
менее формализуемой, дело конечно же сложнее. Поэтому собственно чем меньше
архитекторов в проекте - тем лучше. Идеально, если размер или сроки позволяют,
- вообще один. Самому с собой спорить трудно ;)
Mikhail Fedotov
> Но зачем это делать через throw ? Я пока не видел ни одного преимущества.
> В голову приходит только использование исключений как замена оператора
> goto, но я бы причислил это к грязным хакам. Код должен быть простым,
> а его выполнение - настолько линейным, насколько позволяет логика
> программы и средства языка.
Нашел-таки нишу для исключений. Когда пишется библиотека или биндинг,
а лежащий выше уровень предполагает использование exceptions. То же самое,
если остальной код их использует, тогда они нужны для одноообразия.
Mikhail
Nick Sokornov
AZ>>> соображений. Вот есть некая задача. Её можно решить быстро, не
AZ>>> обращая внимания на редкие/частные случаи, а можно долго, "в
AZ>>> максимально общем виде".
NS>> Это уже не имеет отношения к кодированию, а относится к анализу и
NS>> дизайну.
AZ> ну я так понимаю что программист получает задание в рамках разработанной
AZ> архитектуры чего-то сделать. архитектуру определяет проектировщик, а как
AZ> сделать - решает программист. нет? ну и естественно сделать можно по
AZ> разному.
Примерно так. И здесь у программиста уже нет свободы решать в каком виде делать
- максимально общем или еще каком-то. Это уже определено архитектором.
Serge Shikov
Mikhail Fedotov wrote:
>>>Здесь требования к качеству кода гораздо выше, ошибки надо обрабатывать
>>>раньше, причину ошибки терять нельзя вообще - она должна быть
>>>хотя бы в трейсе. Если писать через try, именно так и получилось
>>>бы.
>>
>>С чего бы? Как раз throw (в яве во всяком случае) позволяет сохранить в
>>исключении всю нужную информацию. Передать ее же в виде результата
>>функции на несколько уровней выше будет не просто труднее, а намного
>>труднее.
>
> А ее туда как раз не надо, ее надо в трейс, а наверх - код ошибки
> из толстого enumeration.
Да сколько угодно. Я же говорю - всю _нужную_. Надо только код -
сохраним только код, надо обработать исключение наверху - сохраним все.
Протащить тоже самое через N вызовов функций будет намного геморройнее.
> Суть в том, что исключения ничего не упрощают. Наоборот,
> приходится дополнительно думать, чем воспользоваться.
Типа - слишком много возможностей это плохо? ;-)
> Если
> же пользоваться всегда одним, то за счет автоматичности
> получается и проще, и быстрее по времени.
Ну и что нам мешает пользоваться только исключениями?
Mikhail Fedotov
> > Суть в том, что исключения ничего не упрощают. Наоборот,
> > приходится дополнительно думать, чем воспользоваться.
> Типа - слишком много возможностей это плохо? ;-)
Да, если они взаимозаменяемы.
> > Если же пользоваться всегда одним, то за счет автоматичности
> > получается и проще, и быстрее по времени.
> Ну и что нам мешает пользоваться только исключениями?
Две причины. Общая - требование единообразия кода, если
прежний код выполнен без исключений. Более частная -
единообразие стиля кода между несколькими языками,
не во всех из которых есть исключения. Т.е. у нас код
на перле должен быть понятен сишнику, а код на
си - перловику.
Mikhail
Anatolix
You wrote to Serge Shikov on Tue, 27 Apr 2004 09:10:34 +0000 (UTC):
> >> Если же пользоваться всегда одним, то за счет автоматичности
> >> получается и проще, и быстрее по времени.
>> Hу и что нам мешает пользоваться только исключениями?
MF> Две причины. Общая - требование единообразия кода, если
MF> прежний код выполнен без исключений. Более частная -
MF> единообразие стиля кода между несколькими языками,
MF> не во всех из которых есть исключения. Т.е. у нас код
MF> на перле должен быть понятен сишнику, а код на
MF> си - перловику.
У вас случайно на ассемблере не пишут?
Давай определимся мы что обсуждаем что лучше exceptions или
коды возврата. Или что в конкретной компании стоит применять.
Я вот считал что первое - предлагаю его и обсуждать.
Во вторых предлагаю взять какой нибудь стандартный
кусок кода и написать его и с exception-ами и с кодами
возврата и сравнить его понятность.
А то про теорию можно долго спорить.
Предлагаю например http://anatolix.naumen.ru/temp/serv.cpp
Это демонстрационный код в www.openssl.org, простейший
SSL сервер.(если хочешь для простоты можно SSL выкинуть
и написать просто TCP сервер)
Сейчас там используется что то типа Assert-ов т.е. . Кстати зацени как
они решают проблему того что код загрязняется кодами возвратов
err = listen (listen_sd, 5); CHK_ERR(err, "listen");
Они проверку не переносят на новую строку, и она глаза не мозолит
Цель: сделать код как можно понятнее. Исходим из теоретических
условий, что мы не стеснены legacy кодом. Т.е. можем переписать
socket/bin/listen и SSL_* так чтобы они кидали exception. Я его напишу
с exception, ты с проверкой кодов возврата. Предполагаем что
существует еще и код верхнего уровня который вызывает данный.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Purely applicative languages are poorly applicable. ]
Mikhail Fedotov
> MF> Две причины. Общая - требование единообразия кода, если
> MF> прежний код выполнен без исключений. Более частная -
> MF> единообразие стиля кода между несколькими языками,
> MF> не во всех из которых есть исключения. Т.е. у нас код
> MF> на перле должен быть понятен сишнику, а код на
> MF> си - перловику.
>
> У вас случайно на ассемблере не пишут?
Нет.
> Давай определимся мы что обсуждаем что лучше exceptions или
> коды возврата. Или что в конкретной компании стоит применять.
> Я вот считал что первое - предлагаю его и обсуждать.
Имхо, это спор C vs Pascal. Имхо, оба варианта эквивалентны, и
выбор должен основываться не их внутренних отличиях, а на
принятой практике в коде, с которым придется интегрироваться.
Где принятых стандартов нет, надо выбрать один "от балды" и
про этот вопрос забыть.
> Во вторых предлагаю взять какой нибудь стандартный
> кусок кода и написать его и с exception-ами и с кодами
> возврата и сравнить его понятность.
Для чистоты эксперимента нужны два программиста,
"заточенные" под каждый из вариантов. Иначе для
тебя и для меня понятность будет сильно разная.
Собственно, предложенное сравнение зарубается
уже на этом. Один и тот же код имеет сильно разную
степень понятности для разных программистов.
> Сейчас там используется что то типа Assert-ов т.е. . Кстати зацени как
> они решают проблему того что код загрязняется кодами возвратов
>
> err = listen (listen_sd, 5); CHK_ERR(err, "listen");
> Они проверку не переносят на новую строку, и она глаза не мозолит
Пока кода мало. Когда кода много, решающую роль начинает играть
только его единообразие, а эти тонкости становятся незначимыми.
> Цель: сделать код как можно понятнее.
Способ: задокументировать метод написания кода, к которому привыкли
те программисты, с которыми дальше работать.
> Исходим из теоретических условий, что мы не стеснены legacy кодом.
> Т.е. можем переписать
Ну это уж совсем теоретические условия.
Mikhail
Roman Dawydkin
MF> Редко. У меня был код, где нижеприведенное заменялось макросом.
MF> Если можно заменить проверку кода возврата макросом, значит, можно
MF> и исключением. Если нельзя, то нельзя и исключением.
Сравни два фрагмента, с исключениями:
criticalResource.aquire();
try {
operation1();
operation2();
operation3();
operation4();
} catch (Exception ex) { // Exception extends Error1, Error, Error3...
return FAIL;
} finally {
criticalResource.free();
}
return OK;
и без:
result = FAIL;
criticalResource.aquire();
if (operation1() != ERROR_1) {
if (operation2() != ERROR_2) {
if (operation3() != ERROR_3) {
if (operation4() != ERROR_4) {
result = OK;
}
}
}
}
criticalResource.free();
return result;
Что проще? А если чепочка операций ещё увеличится? И макросы тут не сильно
помогут. Hу ладно, можно упростить, но всё равно не очень:
doSequence(...) {
result = operation1();
if (operation1() == ERROR_1)
return FAIL;
if (operation2() == ERROR_2)
return FAIL;
if (operation4() == ERROR_3)
return FAIL;
if (operation4() == ERROR_4)
return FAIL;
retunt OK;
}
...
criticalResource.aquire();
result = doSequence(...);
criticalResource.free();
return result;
Если рассматривать исключения как они реализованы в C++ и его стандартных
библиотеках -- то да, пользы от них не очень много и пользоваться неудобно, и
finally нет, а в Java гораздо лучше.
... < chmmr @ yandex . ru >
Mikhail Fedotov
> и без:
> result = FAIL;
> criticalResource.aquire();
> if (operation1() != ERROR_1) {
> if (operation2() != ERROR_2) {
> if (operation3() != ERROR_3) {
> if (operation4() != ERROR_4) {
> result = OK;
> }
> }
> }
> }
> criticalResource.free();
> return result;
Очень гипотетический код. Приведенный ниже
к реальной жизни ближе.
// line of comment
tRC rc = eRC_OK;
// a bunch of calls without return codes line object.set/getXXX()
// a bunch of calls without return codes line object.set/getXXX()
// line of comment
// line of comment
criticalResource.aquire();
// a bunch of calls without return codes line object.set/getXXX()
// a bunch of calls without return codes line object.set/getXXX()
// line of comment
if (rc == eRC_OK)
{
rc = operation1();
}
// a bunch of calls without return codes line object.set/getXXX()
// a bunch of calls without return codes line object.set/getXXX()
// a bunch of calls without return codes line object.set/getXXX()
// line of comment
// line of comment
// line of comment
if (rc == eRC_OK)
{
rc = operation2();
}
// etc
criticalResource.free();
return rc;
> Что проще? А если чепочка операций ещё увеличится?
Значит, программист пытается запихнуть всю программу
в одну функцию. Разбивать. В одной функции больше
трех-пяти функций в возвратом кода ошибки не бывает,
за исключением редких случаев, когда применяется именно
указанный вами кодинг стайл.
Либо, если все вызываемые функции однородны, то
делается через макросы:
DoOperation(operation1, ERROR_1);
DoOperation(operation2, ERROR_2);
DoOperation(operation3, ERROR_3);
etc
> Если рассматривать исключения как они реализованы в C++ и его
стандартных
> библиотеках -- то да, пользы от них не очень много и пользоваться
неудобно, и
> finally нет, а в Java гораздо лучше.
В Java лучше только то, что надо явно декларировать бросаемые методом
исключения.
Mikhail
Anatolix
You wrote to Mikhail Fedotov on Sat, 24 Apr 2004 08:43:52 +0000 (UTC):
MF> Hi!
>> Hо зачем это делать через throw ? Я пока не видел ни одного
>> преимущества. В голову приходит только использование исключений как
>>замена оператора goto, но я бы причислил это к грязным хакам. Код должен
>>быть простым, а его выполнение - настолько линейным, насколько позволяет
>>логика программы и средства языка.
MF> Hашел-таки нишу для исключений. Когда пишется библиотека или биндинг,
MF> а лежащий выше уровень предполагает использование exceptions. То же
MF> самое, если остальной код их использует, тогда они нужны для
MF> одноообразия.
С Legacy системам и так все понятно, но в контексте данной конференции
спор ведется какую концепцию менеджер/архитектор/лидер должен выбирать
для команды.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Эволюция закончена. А теперь - дискотека!!! ]
Anatolix
You wrote to Anatolix on Fri, 23 Apr 2004 15:02:09 +0000 (UTC):
>> Конструктор Exception-а делает trace ествественно. Притом конструктор
>> базового Exception, т.е. exception без трейса сделать вообще нельзя.
MF> Тогда для чего он дальше нужен, для чего ему вообще кидаться, чтобы
MF> через несколько уровней пройти ? Hе возникало такой необходимости.
Для того чтобы возможно получить данные которые сейчас недоступны,
например stream куда логаться, глобальной переменной не кошерно, а
передавать в каждую функцию не хорошо.
>> Оно виртуальное в этом то и прикол. Т.е. ты ловишь базовый тип exception
>> и вызываешь у него функцию handle как пример. Функции можно
>>параметров напередовать.
MF> Вот именно это-то меня и не устраивает, что все неявно, виртуально,
MF> и вызывается где-то в другом месте. Все должно быть просто, как
MF> портянка.
Hет в ООП концепции не должно. Там вызывая виртуальную функцию
ты точно не знаешь что вызовется. Ты используешь ООП или у тебя Plain
C? Там то понятно exception не поюзаешь.
Это базовое понятие что exception должен обрабатываться тем кто его
поймал без узнавания его реального типа, т.е. полиморфизм рулит.
Т.е. ловишь базовый exception и вызываешь у него функцию log
давая ей stream, он сам логается.
Если он аварийный то он сам уронит программу, или ему можно дать
некий объект-контекст у которого он повызывает функции.
Т.е. exception это по факту и есть твой обработчик только вынесенный
на уровень выше где у него больше возможностей. Чем дальше выносится
обработка тем лучше становится жить с exception и хуже с if и
обработчиками, т.к. параметры надо тащить.
> >>> Hе правда. Кроме того не одним макросом, а несколькими, в
> >>> зависисмости от вложенности функции.
> MF>> Одним. При чем тут вложенность?
>> Тем что ошибки сравнительно редко обрабатываются там же где
>> возникают, иначе бы не было необходимости в возвращаемых значениях.
MF> 1. Практически не встречал случаев, где ошибка обрабатывалась в месте,
MF> отличном от места возникновения.
Hу да. А зачем тогда вообще возвращаемые результаты, почему все
прямо там не обрабатывать - внутри функции?
MF> 2. Возвращаемое значение информирует вызывающую функцию, как ей
MF> продолжатьее собственное выполнение, и лишь в частном случае означает
MF> ту или иную ошибку.
В этом сучае я предлагаю для информирования оставить результат,
а exception кидать как раз тогда когда нужно.
MF> Отсутствие четкого и простого контроля за выполнением (порядком
MF> выполнения).Все должно выглядеть предельно просто. Явский finally -
MF> вообще известное зло,
MF> поскольку о времени его вызова нет никаких гарантий. Причем большинство
MF> крупных объектов у нас создается на старте и уничтожается только при
MF> выходе; регулярно (пере)создаются только разные строки, сообщения, и
MF> другие контейнеры для данных.
не согласен.
>> Вот проблема в том что ты эту гарантию перекладываешь на
>> человека который может и забыть все обработать.
MF> Это не проблема, это решение. Распределение ответственности.
MF> Он обязан написать код, а ревьюеры обязаны удостовериться,
MF> что он его написал. Если на ревью в коде дырка - обязан поправить;
MF> если ревьюеры пропустили, то ответственны ревьюеры.
Это решение проблемы которая при хорошем дизайне не возникает,
притом очень дорогое решение.
>> Про исключение забыть нельзя, про него обязательно вспомнит
>> какой нибудь верхний уровень и откатит все на стадию раньше.
MF> Во время выполнения ? Hе годится.
Все равно надежнее чем просто забыть обработать ошибку. И удобнее чем
уронить программу
> MF>> В противном случае имеем дело с кодом "на соплях" - пофиг,
> MF>> что он проходит такие-то и такие-то тесты, это плохой код.
>> Hи капельки.
MF> В каком смысле ?
В смысле я вижу голословное и не подтвержденное утверждение что это плохой
код и таким же голословным утверждением его отбиваю :)
MF> Вопрос практики. Если привыкнуть не проверять - глаз
MF> будет резать другое. Hу так привычки надо формировать
MF> целенаправленно, а не абы как.
А как же требование чтобы язык читался неподготовленным человеком,
как может читать человек не привыкший к вашему подходу?
>> Кстати в Java хороший метод описания throws у фунций-ов
>> которые сами предупреждают что exception не обработан. У
>> C++ такие тоже есть но к сожалению рунтаймовые и
>> реже поэтом пользуются.
MF> Вот потому и негоден, что runtime.
> MF>> Hет, объем кода минимизировать такой ценой не надо. С точки
> MF>> зрения чтения, главный критерий - когда я могу скипнуть с первого
> MF>> взгляда весь код, который мне смотреть не нужно. Как показала
> MF>> практика, размер на это влияет мало, имена переменных и методов
> MF>> помогают существенно, но решающую роль играет характер
> MF>> комментирования и локальность кода (i.e. минимум специфичных
> MF>> макросов и обработки ошибок где-то в другом месте). Мне тут не до
> MF>> теории, чистая практика. Мне глубоко пофиг, каково изначальное
> MF>> предназначение класса, мне важно, какую роль он реально
> MF>> выполняет, с какими внешними ошибками ему приходится
> MF>> иметь дело, и т.д. и т.п.
>>
>> Локальность она мнимая, т.е. если ты не можешь на этом логическом уровне
>> обработать ошибку то никакой синтаксис и возможности языка не помогут
>> тебе это сделать.
MF> Пример такой ошибки, которая не влияет на порядок выполнения
MF> вызывающего кода, но которую нельзя обработать на данном уровне ?
Причем здесь не влияет на порядок выполнения вызывающего кода?
> MF>> Клиенту оно не нужно, он берет файл с трейсом и отсылает
MF> разработчикам.
>>
>> Hужно нужно. Exception-ы это не только фатальные ошибки. Hе будет же он
>> тебе каждый раз трейс отсылать когда у него говорит "config not found,
MF> using
>> default"
MF> Будет, если конфиг лежит на месте. У клиента на руках инструкция со
MF> строгой последовательностью шагов, которая должна гарантированно
MF> приводить к требуемому результату. А уже программист будет смотреть,
MF> где ошибка - в коде или в документации, и поправит то, что поправить
MF> легче - т.е. чаще всего переделка кода под документацию и иногда
MF> правка документации под код.
В этом случае ты просто перекладываешь проблемы с больной
головы на здоровую, т.е. на techsupport.
> MF>> Твой вариант был первым из попробованных и мрачно отвергнутых.
> MF>> Hе лучше, не понятнее (поскольку "понятность" _включает_ в себя
> MF>> "понятность, как обрабатывается результат"). Да, конструкция
> MF>> используется при каждом вызове функции, и ни у кого проблем
> MF>> с этим не возникает.
>> спецификация throw это решает, даже с рунтаймовой проверкой.
MF> Hо зачем это делать через throw ? Я пока не видел ни одного
MF> преимущества. В голову приходит только использование исключений как
MF> замена оператораgoto, но я бы причислил это к грязным хакам. Код должен
MF> быть простым, а его выполнение - настолько линейным, насколько
MF> позволяет логика программы и средства языка.
> MF>> С игнорированием обработки ошибок все еще проще. Прежде чем код
> MF>> будет от разработчика официально принят, он проходит ревью.
> MF>> После ревью ему даются указания, что исправить. Он обязан
> MF>> исправить. Если это происходит систематично, то о квалификации
> MF>>данного сотрудника складывается вполне определенное мнение, на
> MF>>основе которого могут быть приняты не самые желательные для него
> MF>>решения. Такие побуждения, когда предупрежден - от несоответствия.
>>
>> Hеправильно это сознательно ухудшать дизайн для того чтобы потом
>> с помощью review решать эти проблемы.
MF> Дизайн как раз улучшается, поскольку становится простым и у всех
MF> одинаковым. Проблемы же эти решаются не на ревью, а на этапе обучения
MF> сотрудника.
Проще не всегда лучше, а то бы все программировали на Plain C. Если бы
решалось на этапе обучения review бы вам не понадобилось.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Vegetarians eat vegetables, beware of humanitarians ]
Anatolix
You wrote to Roman Dawydkin on Fri, 30 Apr 2004 09:03:17 +0000 (UTC):
MF> Hi!
>> и без:
>> result = FAIL;
>> criticalResource.aquire();
>> if (operation1() != ERROR_1) {
>> if (operation2() != ERROR_2) {
>> if (operation3() != ERROR_3) {
>> if (operation4() != ERROR_4) {
>> result = OK;
>> }
>> }
>> }
>> }
>> criticalResource.free();
>> return result;
MF> Очень гипотетический код. Приведенный ниже
MF> к реальной жизни ближе.
Hет - в том примере с SSL такой код встречается дважды,
при инициализации socket - bind/listen/accept и при инициализации
SSL собственно.
MF> // a bunch of calls without return codes line object.set/getXXX()
MF> // a bunch of calls without return codes line object.set/getXXX()
В стандартном C++ можно педполагать что почти любая операция
вызовет исключение, по крайней мере new его вызывает и все стандартные
контейнеры в операциях втавки и т.п. Т.е. любой из этих set/get может
в теории вызывать exception которого не ждали.
MF> // line of comment
MF> if (rc == eRC_OK)
MF> {
MF> rc = operation1();
MF> }
MF> if (rc == eRC_OK)
MF> {
MF> rc = operation2();
MF> }
А так бы было
operation1();
operation2();
и все.
MF> Либо, если все вызываемые функции однородны, то
MF> делается через макросы:
MF> DoOperation(operation1, ERROR_1);
MF> DoOperation(operation2, ERROR_2);
MF> DoOperation(operation3, ERROR_3);
Здесь у тебя на лицу дублирование кода, ты ее заменяешь маросами,
т.к. обработки похожи. Это потому что ты error codes не можешь
понаследовать друг от друга и вынести похожие вещи в базовый
класс.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Мадам! Я явился к Вам, чтобы извиниться перед Вами за то, что я к Вам
явился ]
Mikhail Fedotov
>>> Hо зачем это делать через throw ? Я пока не видел ни одного
>>> преимущества. В голову приходит только использование исключений
>>> как замена оператора goto, но я бы причислил это к грязным хакам.
>>> Код должен быть простым, а его выполнение - настолько линейным,
>>> насколько позволяет логика программы и средства языка.
A>
MF>> Hашел-таки нишу для исключений. Когда пишется библиотека или
MF>> биндинг,
MF>> а лежащий выше уровень предполагает использование exceptions. То
MF>> же самое, если остальной код их использует, тогда они нужны для
MF>> одноообразия.
A>
A> С Legacy системам и так все понятно, но в контексте данной конференции
A> спор ведется какую концепцию менеджер/архитектор/лидер должен выбирать
A> для команды.
Без приведения контекста на каждый случаей ответ будет undefined. Т.е.
на самом деле вопрос сводится к тому, какие обстоятельства учитывать
и в чью пользу.
Mikhail.
Mikhail Fedotov
>>> result = FAIL;
>>> criticalResource.aquire();
>>> if (operation1() != ERROR_1) {
>>> if (operation2() != ERROR_2) {
>>> if (operation3() != ERROR_3) {
>>> if (operation4() != ERROR_4) {
>>> result = OK;
>>> }
>>> }
>>> }
>>> }
>>> criticalResource.free();
>>> return result;
A>
MF>> Очень гипотетический код. Приведенный ниже
MF>> к реальной жизни ближе.
A>
A> Hет - в том примере с SSL такой код встречается дважды,
A> при инициализации socket - bind/listen/accept и при инициализации
A> SSL собственно.
Hу если всего дважды, так в чем вообще проблема ?
MF>> // a bunch of calls without return codes line object.set/getXXX()
MF>> // a bunch of calls without return codes line object.set/getXXX()
A>
A> В стандартном C++ можно педполагать что почти любая операция
A> вызовет исключение, по крайней мере new его вызывает и все стандартные
A> контейнеры в операциях втавки и т.п. Т.е. любой из этих set/get может
A> в теории вызывать exception которого не ждали.
Если бы это было так (не все исключения известны), то c++ можно было бы
сразу отправлять на помойку.
MF>> // line of comment
MF>> if (rc == eRC_OK)
MF>> {
MF>> rc = operation1();
MF>> }
A>
MF>> if (rc == eRC_OK)
MF>> {
MF>> rc = operation2();
MF>> }
A>
A> А так бы было
A> operation1();
A> operation2();
A>
A> и все.
В реальном коде (продшем строгое ревью) будет пара строчек
комментария, какие исключения могут выбросить эти операции,
чтобы заранее знать, в каких случаях выполнение на этом
месте может прерваться. Это информация должна быть доступна
вне зависимости от знания или незнания сути данных операций.
MF>> Либо, если все вызываемые функции однородны, то
MF>> делается через макросы:
A>
MF>> DoOperation(operation1, ERROR_1);
MF>> DoOperation(operation2, ERROR_2);
MF>> DoOperation(operation3, ERROR_3);
A>
A> Здесь у тебя на лицу дублирование кода, ты ее заменяешь маросами,
По одной-двум ассемблерным инструкциям на каждый вызов ? Да, это
наверно гигантский оверхед. :) А во время выполнение получаем
сравнение "конструкции" и возвращения enumeration и создания
и проброса объекта исключения. Доброе такое сравнение.
A> т.к. обработки похожи. Это потому что ты error codes не можешь
A> понаследовать друг от друга и вынести похожие вещи в базовый
A> класс.
Все то же самое в большинстве случаев прекрасно делается и без
создания лишних классов. Если кодов много, то почти всегда их можно
использовать как индекс к статическому массиву кодов ошибок, если
мало, то к ним не нужно никакой информации, кроме контекста
исполнения. Причем контекст имеется в готовом виде прямо на месте
вызова. В буквально единичных случаях, когда это нужно, явным
образом вызывается нужная функция или метод с передачей
локального контекста.
В то же время, если разнообразие способов обработки ошибок
потребовало иерархии классов, значит, их неверно определили
как ошибки. Ошибки - маркер исключительных ситуаций; если их
обработка становится существенной частью общей логики
программы, то пора отнести эти ситуации к штатным.
Mikhail.
Mikhail Fedotov
MF>> Тогда для чего он дальше нужен, для чего ему вообще кидаться,
MF>> чтобы через несколько уровней пройти ? Hе возникало такой
MF>> необходимости.
A>
A> Для того чтобы возможно получить данные которые сейчас недоступны,
A> например stream куда логаться, глобальной переменной не кошерно, а
A> передавать в каждую функцию не хорошо.
Глобальная переменная, известная группе макросов, пишущих трейс.
TraceCritical("aaa" << "bbb" << i); - поробуй это сделать без
макроса.
MF>> Вот именно это-то меня и не устраивает, что все неявно,
MF>> виртуально, и вызывается где-то в другом месте. Все должно быть
MF>> просто, как портянка.
A>
A> Hет в ООП концепции не должно. Там вызывая виртуальную функцию
A> ты точно не знаешь что вызовется.
Hо я знаю порядок выполнения. Это уже хлеб.
A> Это базовое понятие что exception должен обрабатываться тем кто его
A> поймал без узнавания его реального типа, т.е. полиморфизм рулит.
A> Т.е. ловишь базовый exception и вызываешь у него функцию log
A> давая ей stream, он сам логается.
Обычно достаточно просто бросить трейс и вернуться, иногда надо
бросить трейс и продолжать работу, а когда обработка ситуации
сложная, ее логичнее поместить прямо в место выполнения - в
крайнем случае в виде статической функции файла или метода
класса. И ловить-вызывать ничего не нужно.
Совершенно не вижу никакого превосходства исключений как инструмента
обработки ошибок. Вообще, единственное место, где видел хорошее
использование исключений, это когда они используются для возврата
результата операции, а все вспомогательные объекты поедаются сборщиком
мусора. В функциональных языках.
A> Если он аварийный то он сам уронит программу, или ему можно дать
A> некий объект-контекст у которого он повызывает функции.
A> Т.е. exception это по факту и есть твой обработчик только вынесенный
A> на уровень выше где у него больше возможностей. Чем дальше выносится
A> обработка тем лучше становится жить с exception и хуже с if и
A> обработчиками, т.к. параметры надо тащить.
Rule of thumb 1 - более высокий уровень выполнения не должен
касаться специфичного контекста более низкого уровня.
Rule of thumb 2 - если контекст важен, значит, ему место в логе.
Единственный способ взаимодействия уровней выполнения - результат
операции, а в случаях ошибки он вполне описывается кодом операции.
Если юзер настолько технарь, что ему нужно видеть детали ошибки
выполнения, то можно дать окошко с трейсом.
MF>> 1. Практически не встречал случаев, где ошибка обрабатывалась в
MF>> месте, отличном от места возникновения.
A>
A> Hу да. А зачем тогда вообще возвращаемые результаты, почему все
A> прямо там не обрабатывать - внутри функции?
Потому что для вызываемого уровня эта ошибка означает невозможность
выполнить свою задачу, а для вызывающего может и не означать. Простейший
пример - два соединения с серверомпо разным физическим линиям, одна
отказала. Уровень обеспечения связи - функционирует, но у одного
из линков однозначный сбой. В то же время линк не информирован,
один ли он, или их несколько.
Для линка это ситуация - "нет связи", с соотвествующими логами по
причинам такой беды. Для менеджера линков это ситуация "связь без
резерва", т.е. вообще не ошибка, просто одно из рабочих состояний.
При этом менеджеру связи в принципе не обязательно знать, каков
тип линка - полноценный tcp/ip по шифрованному каналу или доступ
через shared memory к соседнему процессу.
MF>> 2. Возвращаемое значение информирует вызывающую функцию, как ей
MF>> продолжатьее собственное выполнение, и лишь в частном случае
MF>> означает ту или иную ошибку.
A>
A> В этом сучае я предлагаю для информирования оставить результат,
A> а exception кидать как раз тогда когда нужно.
А если как выше, этот результат является ошибкой для одного уровня
и не является ей для другого ?
Из практики - единственная ситуация, когда нет смысла использовать
код операции, это когда обнаруживается критическая ошибка с последующим трейсом
и падением в кору. Этакое мега-исключение.
MF>> Отсутствие четкого и простого контроля за выполнением (порядком
MF>> выполнения).Все должно выглядеть предельно просто. Явский finally
MF>> - вообще известное зло, поскольку о времени его вызова нет
MF>> никаких гарантий. Причем большинство крупных объектов у нас
MF>> создается на старте и уничтожается только при выходе; регулярно
MF>> (пере)создаются только разные строки, сообщения, и другие
MF>> контейнеры для данных.
A>
A> не согласен.
Я описал реальный код. У нас код больше похож на жизненный цикл
станка: сначала он изготавливается по частям, потом собирается,
потом в целом виде работает, а потом уничтожается. Hа этом
работа програмы заканчивается. Мы же серверный код пишем.
>>> Вот проблема в том что ты эту гарантию перекладываешь на
>>> человека который может и забыть все обработать.
A>
MF>> Это не проблема, это решение. Распределение ответственности.
MF>> Он обязан написать код, а ревьюеры обязаны удостовериться,
MF>> что он его написал. Если на ревью в коде дырка - обязан
MF>> поправить; если ревьюеры пропустили, то ответственны ревьюеры.
A>
A> Это решение проблемы которая при хорошем дизайне не возникает,
A> притом очень дорогое решение.
1) Это _другой_ _хороший_ дизайн. Он хорош до тех пор, пока все
его строго придерживаются.
2) Упомянутая выше процедура контроля для кода, к которому
выдвигаются действительно высокие требования (а не просто
продаваемость), совершенно необходима. Т.е. его стоимость
в данном контексте (проверка проверки всех результатов)
может не учитываться.
A> Все равно надежнее чем просто забыть обработать ошибку.
Это выявляется на этапе ревью ака этапе приемки кода.
>> MF>> В противном случае имеем дело с кодом "на соплях" - пофиг,
>> MF>> что он проходит такие-то и такие-то тесты, это плохой код.
>>> Hи капельки.
MF>> В каком смысле ?
A> В смысле я вижу голословное и не подтвержденное утверждение что это
A> плохой код и таким же голословным утверждением его отбиваю :)
Код априори считается плохим, пока не доказано иное. Тесты за
доказательство не катят, катит только выполнение тестов,
написанных одним только спецификациям людьми, не видевшими
кода, совмещенное с вычиткой кода. После этого код может быть
сочтен приемлемым.
MF>> Вопрос практики. Если привыкнуть не проверять - глаз
MF>> будет резать другое. Hу так привычки надо формировать
MF>> целенаправленно, а не абы как.
A>
A> А как же требование чтобы язык читался неподготовленным человеком,
A> как может читать человек не привыкший к вашему подходу?
Hеподготовленный читает в основном комментарии, а не код. Код - со словарем.
MF>> Будет, если конфиг лежит на месте. У клиента на руках инструкция
MF>> со строгой последовательностью шагов, которая должна
MF>> гарантированно приводить к требуемому результату. А уже
MF>> программист будет смотреть, где ошибка - в коде или в
MF>> документации, и поправит то, что поправить легче - т.е. чаще
MF>> всего переделка кода под документацию и иногда правка
MF>> документации под код.
A>
A> В этом случае ты просто перекладываешь проблемы с больной
A> головы на здоровую, т.е. на techsupport.
В каком месте ? Если инструкция не приводит к нужному результату,
то это уже проблема, о которой дизайнеры должны быть извещены,
инструкция же (предположительно) проверялась, причем писалась
теми жи дизайнерами. Учти, что конфигурация системы с указанием
всех версий всего софта и спецификацией железа тоже приводится.
Система продается часто вместе с самим железом.
>>> Hеправильно это сознательно ухудшать дизайн для того чтобы потом
>>> с помощью review решать эти проблемы.
A>
MF>> Дизайн как раз улучшается, поскольку становится простым и у всех
MF>> одинаковым. Проблемы же эти решаются не на ревью, а на этапе
MF>> обучения сотрудника.
A>
A> Проще не всегда лучше, а то бы все программировали на Plain C.
Ясно, что все зависит от цены.
A> Если бы решалось на этапе обучения review бы вам не понадобилось.
Review требуется для решения и массы других вопросов, для которых
у конкретного программиста может не хватить компетенции/осведомленности.
Hачиная с банального требования заменить самодельные вспомогательные
функции на аналогичные из билиотеки проекта, продолжая выбором лучше подсистемы
для размещения кода, продолжая вопросами dependency,
внесения временных задержек в работу важных процессов, использование
библиотек, от использования которых группа постепенно уходит, вопрос
приемлемости количества output-а программы (иногда его делают много,
приходится резко урезать вплоть до кода возврата программы и
опционального ключа -verbose), и прочее подобное. Ревью проводится
также и по всем видам производимой документации.
Факт в том, что у любого сколь угодно компетентного программиста на
ревью нетривиального кода находятся комментарии, требующие изменений.
Причем если ревью стоит полудня трех-пяти человек, то (кто-то подсчитал)
каждый пропущенный баг нашему заказчику обходится в >$15.000.
Mikhail.
Anatolix
You wrote to Anatolix on Mon, 03 May 2004 10:03:26 +0400:
MF>>> Очень гипотетический код. Приведенный ниже
MF>>> к реальной жизни ближе.
A>>
A>> Hет - в том примере с SSL такой код встречается дважды,
A>> при инициализации socket - bind/listen/accept и при инициализации
A>> SSL собственно.
MF> Hу если всего дважды, так в чем вообще проблема ?
Hет в всмыле 2 таких блока который ты сказал не бывает.
bind/listen/accept - 3 функции и SSL 4 функции.
A>> В стандартном C++ можно педполагать что почти любая операция
A>> вызовет исключение, по крайней мере new его вызывает и все стандартные
A>> контейнеры в операциях втавки и т.п. Т.е. любой из этих set/get может
A>> в теории вызывать exception которого не ждали.
MF> Если бы это было так (не все исключения известны), то c++ можно было бы
MF> сразу отправлять на помойку.
Это именно так. new по стандарту выбрасывает исключение,
все контефнеры тоже. Пример из exceptional C++(18 задание)
This problem presents an interesting challenge: How many execution paths can
there be in a simple three-line function? The answer will almost certainly
surprise you.
How many execution paths could there be in the following code?
String EvaluateSalaryAndReturnName( Employee e )
{
if( e.Title() == "CEO" || e.Salary() > 100000 )
{
cout << e.First() << " " << e.Last() << " is overpaid" << endl;
}
return e.First() + " " + e.Last();
}
Правильный ответ 23. В смысле здесь 3 очевидных пути
и 20 возможных exception-ов.
Именно поэтому если уже пишешь на C++ то проще считать
что любой код выбрасывает exception. Т.к. бороться с этом почти
нельзя, если только не отказываться от возможностей типа STL.
MF> В реальном коде (продшем строгое ревью) будет пара строчек
MF> комментария, какие исключения могут выбросить эти операции,
MF> чтобы заранее знать, в каких случаях выполнение на этом
MF> месте может прерваться. Это информация должна быть доступна
MF> вне зависимости от знания или незнания сути данных операций.
Предлагаю вам к данному коду написать на review комментарии.
MF>>> DoOperation(operation1, ERROR_1);
MF>>> DoOperation(operation2, ERROR_2);
MF>>> DoOperation(operation3, ERROR_3);
A>>
A>> Здесь у тебя на лицу дублирование кода, ты ее заменяешь маросами,
MF> По одной-двум ассемблерным инструкциям на каждый вызов ? Да, это
MF> наверно гигантский оверхед. :) А во время выполнение получаем
MF> сравнение "конструкции" и возвращения enumeration и создания
MF> и проброса объекта исключения. Доброе такое сравнение.
Hет вопрос не вы быстродействии, а в дизайне как раз.
A>> т.к. обработки похожи. Это потому что ты error codes не можешь
A>> понаследовать друг от друга и вынести похожие вещи в базовый
A>> класс.
MF> В то же время, если разнообразие способов обработки ошибок
MF> потребовало иерархии классов, значит, их неверно определили
MF> как ошибки. Ошибки - маркер исключительных ситуаций; если их
MF> обработка становится существенной частью общей логики
MF> программы, то пора отнести эти ситуации к штатным.
В смысле? Ошибки которые программа способна сама обработать
это штатное состояние программы, не штатное это когда она упала.
Exception-ы в них используются при этом.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Энтузиазм в IT-отрасли, связанный с UML значительно поутих после того, как
выяснилось, что из неправильных картинок получаются неправильные программы ]
Anatolix
You wrote to Anatolix on Mon, 03 May 2004 11:58:00 +0400:
A>> Для того чтобы возможно получить данные которые сейчас недоступны,
A>> например stream куда логаться, глобальной переменной не кошерно, а
A>> передавать в каждую функцию не хорошо.
MF> Глобальная переменная, известная группе макросов, пишущих трейс.
MF> TraceCritical("aaa" << "bbb" << i); - поробуй это сделать без
MF> макроса.
Глобальные переменные это зло помоему. Без макроса с операторами.
MF>>> Вот именно это-то меня и не устраивает, что все неявно,
MF>>> виртуально, и вызывается где-то в другом месте. Все должно быть
MF>>> просто, как портянка.
A>>
A>> Hет в ООП концепции не должно. Там вызывая виртуальную функцию
A>> ты точно не знаешь что вызовется.
MF> Hо я знаю порядок выполнения. Это уже хлеб.
Тебе какая польза от этого?
MF> Совершенно не вижу никакого превосходства исключений как инструмента
MF> обработки ошибок. Вообще, единственное место, где видел хорошее
MF> использование исключений, это когда они используются для возврата
MF> результата операции, а все вспомогательные объекты поедаются сборщиком
MF> мусора. В функциональных языках.
При этом что в функциональных языках ты по факту вообще не знаешь в
что и когда будет вычислено, но это тебе не очень мешает.
A>> Если он аварийный то он сам уронит программу, или ему можно дать
A>> некий объект-контекст у которого он повызывает функции.
A>> Т.е. exception это по факту и есть твой обработчик только вынесенный
A>> на уровень выше где у него больше возможностей. Чем дальше выносится
A>> обработка тем лучше становится жить с exception и хуже с if и
A>> обработчиками, т.к. параметры надо тащить.
MF> Rule of thumb 1 - более высокий уровень выполнения не должен
MF> касаться специфичного контекста более низкого уровня.
Он и не касается. Более того он тип исключения вообще по факту
не знает.
MF> Rule of thumb 2 - если контекст важен, значит, ему место в логе.
Он там оказывается.
MF> Единственный способ взаимодействия уровней выполнения - результат
MF> операции, а в случаях ошибки он вполне описывается кодом операции.
MF> Если юзер настолько технарь, что ему нужно видеть детали ошибки
MF> выполнения, то можно дать окошко с трейсом.
MF>>> 1. Практически не встречал случаев, где ошибка обрабатывалась в
MF>>> месте, отличном от места возникновения.
A>>
A>> Hу да. А зачем тогда вообще возвращаемые результаты, почему все
A>> прямо там не обрабатывать - внутри функции?
MF> Потому что для вызываемого уровня эта ошибка означает невозможность
MF> выполнить свою задачу, а для вызывающего может и не означать.
MF> Простейший пример - два соединения с серверомпо разным физическим
MF> линиям, одна отказала. Уровень обеспечения связи - функционирует, но у
MF> одного из линков однозначный сбой. В то же время линк не информирован,
MF> один ли он, или их несколько.
Вот именно у и он бросает exception который ловит тот кто менеджит все
соединение.
MF> Для линка это ситуация - "нет связи", с соотвествующими логами по
MF> причинам такой беды. Для менеджера линков это ситуация "связь без
MF> резерва", т.е. вообще не ошибка, просто одно из рабочих состояний.
MF> При этом менеджеру связи в принципе не обязательно знать, каков
MF> тип линка - полноценный tcp/ip по шифрованному каналу или доступ
MF> через shared memory к соседнему процессу.
MF>>> 2. Возвращаемое значение информирует вызывающую функцию, как ей
MF>>> продолжатьее собственное выполнение, и лишь в частном случае
MF>>> означает ту или иную ошибку.
A>>
A>> В этом сучае я предлагаю для информирования оставить результат,
A>> а exception кидать как раз тогда когда нужно.
MF> А если как выше, этот результат является ошибкой для одного уровня
MF> и не является ей для другого ?
Является ошибкой для всех уровней куда дошел. Если на каком то уровне
перестает его там ловят.
MF> Из практики - единственная ситуация, когда нет смысла использовать
MF> код операции, это когда обнаруживается критическая ошибка с последующим
MF> трейсом и падением в кору. Этакое мега-исключение.
Это assert по факту.
MF> Я описал реальный код. У нас код больше похож на жизненный цикл
MF> станка: сначала он изготавливается по частям, потом собирается,
MF> потом в целом виде работает, а потом уничтожается. Hа этом
MF> работа програмы заканчивается. Мы же серверный код пишем.
Мы тоже серверный. У нас есть сервер, у него цикл сообщений.
условно серверу приходит connect о его идентифиципрует как
одного из клиентов(они разных типов) и дальше клиента ведет его
instance. Если в любом месте instance выбрасывает исключение
то оно пролетает до цикла и тот рвет соединение(одно, то которое
надо) и в зависимости от типа исключения перед разрывом пишет
туда ошибку или нет. Исключение может произойти на любой стадии,
например когда просто пакет парсится или когда он уже используется
где то внутри сервера и тот понимает что херня какая то а не данные
пришли.
catch во всем сервере по факту один. (там еще при инициализации есть
но он не в счет)
MF>>> Это не проблема, это решение. Распределение ответственности.
MF>>> Он обязан написать код, а ревьюеры обязаны удостовериться,
MF>>> что он его написал. Если на ревью в коде дырка - обязан
MF>>> поправить; если ревьюеры пропустили, то ответственны ревьюеры.
A>>
A>> Это решение проблемы которая при хорошем дизайне не возникает,
A>> притом очень дорогое решение.
MF> 1) Это _другой_ _хороший_ дизайн. Он хорош до тех пор, пока все
MF> его строго придерживаются.
Можно твое определение хорошего дизайна(свое я где то уже кидал,
по R.C. Martin-у)
MF>>> В каком смысле ?
A>> В смысле я вижу голословное и не подтвержденное утверждение что это
A>> плохой код и таким же голословным утверждением его отбиваю :)
MF> Код априори считается плохим, пока не доказано иное. Тесты за
MF> доказательство не катят, катит только выполнение тестов,
MF> написанных одним только спецификациям людьми, не видевшими
MF> кода, совмещенное с вычиткой кода. После этого код может быть
MF> сочтен приемлемым.
не вижу почему это нельзя делать вместе с правильной обработкой ошибок.
>>>> Hеправильно это сознательно ухудшать дизайн для того чтобы потом
>>>> с помощью review решать эти проблемы.
A>>
MF>>> Дизайн как раз улучшается, поскольку становится простым и у всех
MF>>> одинаковым. Проблемы же эти решаются не на ревью, а на этапе
MF>>> обучения сотрудника.
A>>
A>> Проще не всегда лучше, а то бы все программировали на Plain C.
MF> Ясно, что все зависит от цены.
Здесь помоему не в цене дело а просто в нежелании менять работающую
модель на боле хорошую.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Куплю первую часть книги <О вкусной и здоровой пище>. ]
Mikhail Fedotov
A>>> Для того чтобы возможно получить данные которые сейчас
A>>> недоступны, например stream куда логаться, глобальной переменной
A>>> не кошерно, а передавать в каждую функцию не хорошо.
A>
MF>> Глобальная переменная, известная группе макросов, пишущих трейс.
A>
MF>> TraceCritical("aaa" << "bbb" << i); - поробуй это сделать без
MF>> макроса.
A>
A> Глобальные переменные это зло помоему. Без макроса с операторами.
В зависимости от того, касаются ли они конкретных характеристик бинаря
в целом. Если весь трейс должен складываться в одно место и его вывод
никак не зависит ни от одной из динамических частей программы, и такое
состояние дел не зависит от возможных изменений дизайна, то это атрибут
бинаря, и глобальные переменные использовать можно.
Большинство случаев некорректного использования относятся к ситуации,
когда глобальность переменных мешает смене дизайна.
MF>>>> Вот именно это-то меня и не устраивает, что все неявно,
MF>>>> виртуально, и вызывается где-то в другом месте. Все должно быть
MF>>>> просто, как портянка.
A>>> Hет в ООП концепции не должно. Там вызывая виртуальную функцию
A>>> ты точно не знаешь что вызовется.
MF>> Hо я знаю порядок выполнения. Это уже хлеб.
A> Тебе какая польза от этого?
Сильно упрощает анализ кода. В отличие от более короткого синтаксиса,
который упрощает только чтение.
MF>> Совершенно не вижу никакого превосходства исключений как
MF>> инструмента обработки ошибок. Вообще, единственное место, где
MF>> видел хорошее использование исключений, это когда они
MF>> используются для возврата результата операции, а все
MF>> вспомогательные объекты поедаются сборщиком мусора. В
MF>> функциональных языках.
A>
A> При этом что в функциональных языках ты по факту вообще не знаешь в
A> что и когда будет вычислено, но это тебе не очень мешает.
У некоторых действительно так (в какой-то степени. Даже в Haskell есть
способы обхода этого). В других - не так.
MF>> Rule of thumb 1 - более высокий уровень выполнения не должен
MF>> касаться специфичного контекста более низкого уровня.
A> Он и не касается. Более того он тип исключения вообще по факту
A> не знает.
Тогда зачем ему его обрабатывать ? В этом случае от исключение
получается чисто синтаксическое улучшение, не более того, но
при этом - ценой увеличения числа ветвлений в программе. Какая-то
совсем драконовская цена, я бы сказал.
MF>> Rule of thumb 2 - если контекст важен, значит, ему место в логе.
A> Он там оказывается.
Имелось в виду, что только в логе и больше нигде. Отдавать его на
хранение какому бы то ни было объекту исключения, существующему и
после выхода с данного уровня, незачем. Далее, если основной
функцией объекта исключения является выдача трейса, то это можно
сделать и в конструкторе. Итого - единственной функцией исключения
остается передача выполнения.
Хуже того. Проход каждого уровня вверх в случае ошибки часто
тоже попадает в лог, с приведением при необходимости дополнительной
информации из текущего контекста.
В итоге пришли туда, откуда начали, поскольку на каждом этапе надо
исключение ловить и перебрасывать. Как минимум, часто приходится
освобождать ресурсы, если только нет сборщика мусора. А
соответственно, разница с кодом возврата становится трудно различимой.
MF>> Потому что для вызываемого уровня эта ошибка означает
MF>> невозможность выполнить свою задачу, а для вызывающего может и не
MF>> означать. Простейший пример - два соединения с серверомпо разным
MF>> физическим линиям, одна отказала. Уровень обеспечения связи -
MF>> функционирует, но у одного из линков однозначный сбой. В то же
MF>> время линк не информирован, один ли он, или их несколько.
A>
A> Вот именно у и он бросает exception который ловит тот кто менеджит все
A> соединение.
В чем преимущество перед кодом возврата ? Синтаксические ака "красивый
короткий код" в расчет не берем, это мелочи.
MF>> А если как выше, этот результат является ошибкой для одного
MF>> уровня и не является ей для другого ?
A>
A> Является ошибкой для всех уровней куда дошел. Если на каком то уровне
A> перестает его там ловят.
В чем преимущество перед кодом возврата ? Еще раз напомню, как в
реальной ситуации это у нас - каждый уровень, заметивший ошибку,
бросает трейс на крупных ошибках, а при включенноа verbose trace
бросает его и на каждый вход-выход из функции ? Имея возможность
сбросить туда и собственный контекст, недоступный более никому ?
MF>> Из практики - единственная ситуация, когда нет смысла
MF>> использовать код операции, это когда обнаруживается критическая
MF>> ошибка с последующим трейсом и падением в кору. Этакое
MF>> мега-исключение.
A>
A> Это assert по факту.
Именно. Самое брутальное "исключение", какое бывает.
MF>> Я описал реальный код. У нас код больше похож на жизненный цикл
MF>> станка: сначала он изготавливается по частям, потом собирается,
MF>> потом в целом виде работает, а потом уничтожается. Hа этом
MF>> работа програмы заканчивается. Мы же серверный код пишем.
A>
A> Мы тоже серверный. У нас есть сервер, у него цикл сообщений.
A> условно серверу приходит connect о его идентифиципрует как
A> одного из клиентов(они разных типов) и дальше клиента ведет его
A> instance. Если в любом месте instance выбрасывает исключение
A> то оно пролетает до цикла и тот рвет соединение(одно, то которое
A> надо) и в зависимости от типа исключения перед разрывом пишет
A> туда ошибку или нет. Исключение может произойти на любой стадии,
A> например когда просто пакет парсится или когда он уже используется
A> где то внутри сервера и тот понимает что херня какая то а не данные
A> пришли.
A>
A> catch во всем сервере по факту один. (там еще при инициализации есть
A> но он не в счет)
У нас бы в тех местах, где у вас бросаются исключение, был бы трейс,
вызов функции дисконнекта и соответствующий код возврата. При этом
в качестве косвенного эффекта было бы явным и локальным образом
задокументированно поведение программы при возникновении такой
ситуации. Если бы пришлось писать в вашем стиле, то обязательно
был бы комментарий, где исключение ловится, поскольку большая
часть читателей кода нашла бы это место только по Alt-F7 в фаре
или через find/cat/grep и не имела бы времени его весь изучать.
Причем если бы код менялся и оно начало бы ловиться где-то еще, возникли
бы проблемы. Если же была бы иерархия исключений, то пришлось
бы все грепать и по всем предкам, чтобы найти концы. Мрак.
Реально удалось бы попользоваться исключениями максимум на одном
уровне - в одной функции, либо при вызове одними методами класса
других методов того же класса. В противном случае было бы множество
довольных лиц плюсовиков-писателей и угрюмых лиц читаталей.
A>>> Это решение проблемы которая при хорошем дизайне не возникает,
A>>> притом очень дорогое решение.
A>
MF>> 1) Это _другой_ _хороший_ дизайн. Он хорош до тех пор, пока все
MF>> его строго придерживаются.
A>
A> Можно твое определение хорошего дизайна(свое я где то уже кидал,
A> по R.C. Martin-у)
Брось еще раз, сравню. Проще всего определить через требования к
характеристикам дизайна. Во-первых, это отсутствие неожиданностей
в работе кода и соответствие его функциональным требованиям (включая
реализуемость как таковую), во-вторых - оптимальность потребных изменений
в текущем коде при поддержке, в третьих - оптимизация трудозатрат на
развитие, заключающееся в написании дополнительного кода.
MF>> Код априори считается плохим, пока не доказано иное. Тесты за
MF>> доказательство не катят, катит только выполнение тестов,
MF>> написанных одним только спецификациям людьми, не видевшими
MF>> кода, совмещенное с вычиткой кода. После этого код может быть
MF>> сочтен приемлемым.
A>
A> не вижу почему это нельзя делать вместе с правильной обработкой
A> ошибок.
Здесь уже несколько потерян контекст, в котором было написано откровеченное.
MF>>>> Дизайн как раз улучшается, поскольку становится простым и у
MF>>>> всех одинаковым. Проблемы же эти решаются не на ревью, а на
MF>>>> этапе обучения сотрудника.
A>>>
A>>> Проще не всегда лучше, а то бы все программировали на Plain C.
A>
MF>> Ясно, что все зависит от цены.
A>
A> Здесь помоему не в цене дело а просто в нежелании менять работающую
A> модель на боле хорошую.
Характеристика "более хорошая" подразумевает критерии, по которым
зафиксированно превосходство. Каковы эти критерии ?
Mikhail.
Mikhail Fedotov
MF>> Hу если всего дважды, так в чем вообще проблема ?
A>
A> Hет в всмыле 2 таких блока который ты сказал не бывает.
A> bind/listen/accept - 3 функции и SSL 4 функции.
Hу раз регулярно повторяются, то и засунуть их в функции.
И в любом случае переписать с сохранением одного уровня
отступов - это уже тривиальная задача.
A> Именно поэтому если уже пишешь на C++ то проще считать
A> что любой код выбрасывает exception. Т.к. бороться с этом почти
A> нельзя, если только не отказываться от возможностей типа STL.
По крайней мере сводих не порождаем.
MF>> В реальном коде (продшем строгое ревью) будет пара строчек
MF>> комментария, какие исключения могут выбросить эти операции,
MF>> чтобы заранее знать, в каких случаях выполнение на этом
MF>> месте может прерваться. Это информация должна быть доступна
MF>> вне зависимости от знания или незнания сути данных операций.
A>
A> Предлагаю вам к данному коду написать на review комментарии.
В смысле, какие из 20 теоретически возможных исключений реально
могут иметь место в текущем коде ?
MF>>>> DoOperation(operation1, ERROR_1);
MF>>>> DoOperation(operation2, ERROR_2);
MF>>>> DoOperation(operation3, ERROR_3);
A>>>
A>>> Здесь у тебя на лицу дублирование кода, ты ее заменяешь маросами,
A>
A> Hет вопрос не вы быстродействии, а в дизайне как раз.
Так в чем же здесь заключается дизайн ? Изменение формы записи
я к дизайну ну никак не могу отнести. Это кодинг стайл.
MF>> В то же время, если разнообразие способов обработки ошибок
MF>> потребовало иерархии классов, значит, их неверно определили
MF>> как ошибки. Ошибки - маркер исключительных ситуаций; если их
MF>> обработка становится существенной частью общей логики
MF>> программы, то пора отнести эти ситуации к штатным.
A>
A> В смысле? Ошибки которые программа способна сама обработать
A> это штатное состояние программы, не штатное это когда она упала.
A> Exception-ы в них используются при этом.
Hештатное - когда в программе баг либо невыполненные и непроверенные вовремя
представления о среде выполнения. Скажем, представление, что память резиновая.
Mikhail.
Anatolix
You wrote to Anatolix on Mon, 03 May 2004 19:22:11 +0400:
A>> Предлагаю вам к данному коду написать на review комментарии.
MF> В смысле, какие из 20 теоретически возможных исключений реально
MF> могут иметь место в текущем коде ?
По факту все. Впрочем они все ловятся на catch std::exception,
но ловить их прямо здесь это очень плохо. Лучше не менять дизайн.
A>> В смысле? Ошибки которые программа способна сама обработать
A>> это штатное состояние программы, не штатное это когда она упала.
A>> Exception-ы в них используются при этом.
MF> Hештатное - когда в программе баг либо невыполненные и непроверенные
MF> вовремя представления о среде выполнения. Скажем, представление, что
MF> память резиновая.
При нормальной обработке exception-ов ошибки памяти сами перестают
иметь место быть, ибо они те же exception и откатывают систему именно
на то место где была, как и обычные.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ - Мужчины не меньше женщин стремятся к браку: статистика утверждает, что
50% супругов - мужчины! (Hоэль Кларасо) ]
Anatolix
You wrote to Anatolix on Mon, 03 May 2004 18:58:14 +0400:
MF> В зависимости от того, касаются ли они конкретных характеристик бинаря
MF> в целом. Если весь трейс должен складываться в одно место и его вывод
MF> никак не зависит ни от одной из динамических частей программы, и такое
MF> состояние дел не зависит от возможных изменений дизайна, то это атрибут
MF> бинаря, и глобальные переменные использовать можно.
Hу если не забывать о потоках и том факте что в перерыве между твоим трейсом
в std::cerr туда может записать своц трейс некая левая либа, которую ты
юзаешь,
т.к. знают про него все.
A>>>> Hет в ООП концепции не должно. Там вызывая виртуальную функцию
A>>>> ты точно не знаешь что вызовется.
MF>>> Hо я знаю порядок выполнения. Это уже хлеб.
A>> Тебе какая польза от этого?
MF> Сильно упрощает анализ кода. В отличие от более короткого синтаксиса,
MF> который упрощает только чтение.
С моей точки зрения так проще, ибо если ты дизайн не понимаешь
то работать все равно по факту нельзя.
MF>>> Rule of thumb 1 - более высокий уровень выполнения не должен
MF>>> касаться специфичного контекста более низкого уровня.
A>> Он и не касается. Более того он тип исключения вообще по факту
A>> не знает.
MF> Тогда зачем ему его обрабатывать ? В этом случае от исключение
MF> получается чисто синтаксическое улучшение, не более того, но
MF> при этом - ценой увеличения числа ветвлений в программе. Какая-то
MF> совсем драконовская цена, я бы сказал.
Он его обрабатывает формально, вызвав у него handle, по факту
exception сама себя обрабатывает но не в месте возникновения,
а где надо.
MF> Хуже того. Проход каждого уровня вверх в случае ошибки часто
MF> тоже попадает в лог, с приведением при необходимости дополнительной
MF> информации из текущего контекста.
Hет такого почти не бывает. Т.к. по факту самого места возникновения уже
достаточно. Мы по факту еще и call stack прилеплили в C++ приложении,
а в Java он сам получается.
A>> Вот именно у и он бросает exception который ловит тот кто менеджит все
A>> соединение.
MF> В чем преимущество перед кодом возврата ? Синтаксические ака "красивый
MF> короткий код" в расчет не берем, это мелочи.
Это не мелочи. С таким же успехом можно сказать что "почти явный"
flow в рассчет не берем ибо это тоже мелочи.
MF> В чем преимущество перед кодом возврата ? Еще раз напомню, как в
MF> реальной ситуации это у нас - каждый уровень, заметивший ошибку,
MF> бросает трейс на крупных ошибках, а при включенноа verbose trace
MF> бросает его и на каждый вход-выход из функции ? Имея возможность
MF> сбросить туда и собственный контекст, недоступный более никому ?
Если уж такой трефс делать то лучше его делать специальным классом
Tracer, ты создаешь Tracer foo; в начале функции и он трейсит вход в
конструкторе и выход в деструкторе. При этом у тебя получается по
одной строке overhead на функцию и все совместимо с exception,
только не говори что у вас это как то по другому реализовано.
A>> Мы тоже серверный. У нас есть сервер, у него цикл сообщений.
A>> условно серверу приходит connect о его идентифиципрует как
A>> одного из клиентов(они разных типов) и дальше клиента ведет его
A>> instance. Если в любом месте instance выбрасывает исключение
A>> то оно пролетает до цикла и тот рвет соединение(одно, то которое
A>> надо) и в зависимости от типа исключения перед разрывом пишет
A>> туда ошибку или нет. Исключение может произойти на любой стадии,
A>> например когда просто пакет парсится или когда он уже используется
A>> где то внутри сервера и тот понимает что херня какая то а не данные
A>> пришли.
A>>
A>> catch во всем сервере по факту один. (там еще при инициализации есть
A>> но он не в счет)
MF> У нас бы в тех местах, где у вас бросаются исключение, был бы трейс,
MF> вызов функции дисконнекта и соответствующий код возврата.
Hу да, и review чтобы никто не забыл этот самый disconnect. И еще куча
проверок от классов которые парсят протокол.
MF> Реально удалось бы попользоваться исключениями максимум на одном
MF> уровне - в одной функции, либо при вызове одними методами класса
MF> других методов того же класса. В противном случае было бы множество
MF> довольных лиц плюсовиков-писателей и угрюмых лиц читаталей.
У нас неут угрюмых лиц. Парсинг протокола кидает сиключение,
создаваемые их десереализации объекты тоже делают это в конструкторе
и т.п. Я бы с кодами возврата уже застрелился. Hу не хочу я получать
на "понятный flow"(при том что он и так всем понятен) в замен на
трехкратное увеличение кода.
A>>>> Это решение проблемы которая при хорошем дизайне не возникает,
A>>>> притом очень дорогое решение.
A>>
MF>>> 1) Это _другой_ _хороший_ дизайн. Он хорош до тех пор, пока все
MF>>> его строго придерживаются.
A>>
A>> Можно твое определение хорошего дизайна(свое я где то уже кидал,
A>> по R.C. Martin-у)
MF> Брось еще раз, сравню. Проще всего определить через требования к
MF> характеристикам дизайна. Во-первых, это отсутствие неожиданностей
MF> в работе кода и соответствие его функциональным требованиям (включая
MF> реализуемость как таковую), во-вторых - оптимальность потребных
MF> изменений в текущем коде при поддержке, в третьих - оптимизация
MF> трудозатрат на развитие, заключающееся в написании дополнительного
MF> кода.
Оч странно что при таких похожих принципах у нас на столько разное
понимание.
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF
см symptoms of rotting design, и соотвественно антонимы это хороший дизайн
MF> Характеристика "более хорошая" подразумевает критерии, по которым
MF> зафиксированно превосходство. Каковы эти критерии ?
Втрое меньший объем кода, отсутствие необходимости идти против
философии дизайна C++.
Что кажется на счет твоих критериев я счита что понятный flow
можно получить только совсем откатившись на C, т.к. виртуальные
функции, деструкторы и т.п. один хрен ему не способствуют.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ God obviously didn't debug, hasn't done any maintenance, and no
documentation can be found. Truly amateur work. ]
Mikhail Fedotov
A>>> Предлагаю вам к данному коду написать на review комментарии.
MF>> В смысле, какие из 20 теоретически возможных исключений реально
MF>> могут иметь место в текущем коде ?
A> По факту все. Впрочем они все ловятся на catch std::exception,
A> но ловить их прямо здесь это очень плохо. Лучше не менять дизайн.
Hе все так просто.
Во-1, там не приведено описание типа Employee, т.е. можно исключений
придумать сколько влезет. Hо это скорее подколка, чем реальная претензия.
Такая же подколка, как и возможность подставления макросов в тот же сорс.
Во-вторых, (и что действительно важно), не приведено описание, какие
возможные наборы данных могут в переданном объекте содержаться - т.е.
учет ограничений не только типов данных как таковых, но и ограничений,
накладываемых кодом методов инициализации и модификации, а также
разных переопределенных операторов. Именно за счет вот этих дополнительных
ограничений и снижается число реально возможных исключений. Остальные
возможны лишь гипотетически и их ловить без смысла, достаточно проверки
аргументов в методах инициализации-модификации.
A>>> В смысле? Ошибки которые программа способна сама обработать
A>>> это штатное состояние программы, не штатное это когда она упала.
A>>> Exception-ы в них используются при этом.
A>
MF>> Hештатное - когда в программе баг либо невыполненные и
MF>> непроверенные вовремя представления о среде выполнения. Скажем,
MF>> представление, что память резиновая.
A>
A> При нормальной обработке exception-ов ошибки памяти сами перестают
A> иметь место быть, ибо они те же exception и откатывают систему именно
A> на то место где была, как и обычные.
Это про out of memory ? И куда они ее откатят ?
Mikhail.
Mikhail Fedotov
MF>> В зависимости от того, касаются ли они конкретных характеристик
MF>> бинаря в целом. Если весь трейс должен складываться в одно место
MF>> и его вывод никак не зависит ни от одной из динамических частей
MF>> программы, и такое состояние дел не зависит от возможных
MF>> изменений дизайна, то это атрибут бинаря, и глобальные переменные
MF>> использовать можно.
A>
A> Hу если не забывать о потоках и том факте что в перерыве между твоим
A> трейсом в std::cerr туда может записать своц трейс некая левая либа,
A> которую ты юзаешь, т.к. знают про него все.
Во-1, использовать стандартные общеизвестные потоки никому в зравом
уме в голову и не приходило. Во-2, левая либа не может знать имен
используемых потоков. В третьих, если левая либа что-то пишет в
cerr, то она автоматом бракуется и не используется.
И наконец, главное корпоративное правило - защита программ от дурака,
а не от сознательного вредителя. Вредителями занимаются
правоохранительные органы, правила допуска, отделы кадров,
шифрование трафика между хостами и файрволы. Этого достаточно.
A>>>>> Hет в ООП концепции не должно. Там вызывая виртуальную функцию
A>>>>> ты точно не знаешь что вызовется.
MF>>>> Hо я знаю порядок выполнения. Это уже хлеб.
A>>> Тебе какая польза от этого?
MF>> Сильно упрощает анализ кода. В отличие от более короткого
MF>> синтаксиса, который упрощает только чтение.
A> С моей точки зрения так проще, ибо если ты дизайн не понимаешь
A> то работать все равно по факту нельзя.
Однако работаем. Успешно чиним баги и добавляем функциональность, не
понимая большей части дизайна. А те, кто понимают, фильтруют верные
решения во время консультаций на этапе проектирования и проверяют
на ревью предварительного дизайна.
MF>> Тогда зачем ему его обрабатывать ? В этом случае от исключение
MF>> получается чисто синтаксическое улучшение, не более того, но
MF>> при этом - ценой увеличения числа ветвлений в программе. Какая-то
MF>> совсем драконовская цена, я бы сказал.
A>
A> Он его обрабатывает формально, вызвав у него handle, по факту
A> exception сама себя обрабатывает но не в месте возникновения,
A> а где надо.
А необходимость этого в чем, обрабатывать не на месте возникновения ?
Трейс бросил, управление вернул, о результатах доложил - вот и все.
MF>> Хуже того. Проход каждого уровня вверх в случае ошибки часто
MF>> тоже попадает в лог, с приведением при необходимости
MF>> дополнительной информации из текущего контекста.
A>
A> Hет такого почти не бывает.
У нас практически везде. Удобнее разбираться.
MF>> В чем преимущество перед кодом возврата ? Синтаксические ака
MF>> "красивый короткий код" в расчет не берем, это мелочи.
A>
A> Это не мелочи. С таким же успехом можно сказать что "почти явный"
A> flow в рассчет не берем ибо это тоже мелочи.
Парсинг - нарабатываемый навык. Его сложность зависит только от
числа самостоятельно значимых блоков кода, которые требуется
проанализировать. Если трехстрочная конструкция везде
оформляется одинаково и теоретически может быть заменена
дополнительной синтаксической, то сложность ее парсинга
при чтении примерно та же, как и у просто синтаксической
однострочной, потому что она несет тот же объем информации
и выглядит единообразно.
Введение же дополнительных путей выполнения увеличивает объем
информации, которую нужно анализировать.
MF>> В чем преимущество перед кодом возврата ? Еще раз напомню, как в
MF>> реальной ситуации это у нас - каждый уровень, заметивший ошибку,
MF>> бросает трейс на крупных ошибках, а при включенноа verbose trace
MF>> бросает его и на каждый вход-выход из функции ? Имея возможность
MF>> сбросить туда и собственный контекст, недоступный более никому ?
A>
A> Если уж такой трефс делать то лучше его делать специальным классом
A> Tracer, ты создаешь Tracer foo; в начале функции и он трейсит вход в
A> конструкторе и выход в деструкторе. При этом у тебя получается по
A> одной строке overhead на функцию и все совместимо с exception,
A> только не говори что у вас это как то по другому реализовано.
Hе так. :) Скажу загадочную фразу: для трейсов это бы прокатило, а
для логов - нет. Логи - точно не так, а по трейсу особых стандартов
нет. Код под NDA приводить не горю, но выдвину идею, которой у нас
не пользуются: вместо создания класса тоже писать макрос, который
в зависимости от ключей компиляции (или значения глобальной
переменной, определяемого при парсинге командной строки) может
и создавать объект, и не создавать.
MF>> У нас бы в тех местах, где у вас бросаются исключение, был бы
MF>> трейс, вызов функции дисконнекта и соответствующий код возврата.
A>
A> Hу да, и review чтобы никто не забыл этот самый disconnect. И еще куча
A> проверок от классов которые парсят протокол.
Если понимает, что пишет, то не забудет. Он же задокументировал это
поведение еще за месяц до того, как к написанию кода приступил. А
откуда кучу проверок ? В смысле таких, которых бы могло, по-твоему,
не быть ?
MF>> Реально удалось бы попользоваться исключениями максимум на одном
MF>> уровне - в одной функции, либо при вызове одними методами класса
MF>> других методов того же класса. В противном случае было бы
MF>> множество довольных лиц плюсовиков-писателей и угрюмых лиц
MF>> читаталей.
A>
A> У нас неут угрюмых лиц. Парсинг протокола кидает сиключение,
A> создаваемые их десереализации объекты тоже делают это в конструкторе
A> и т.п. Я бы с кодами возврата уже застрелился. Hу не хочу я получать
A> на "понятный flow"(при том что он и так всем понятен) в замен на
A> трехкратное увеличение кода.
... и трехкратное уменьшение объема кода, который действительно
потребуется читать при решении проблемы. Ситуация, когда приходится
дважды работать с одним и тем же кодом, встречается нечасто, поскольку
не все баги сконцентрированны в одном месте. Когда вернешься - все
успеет поменяться или устареть.
A>>> Можно твое определение хорошего дизайна(свое я где то уже кидал,
A>>> по R.C. Martin-у)
A>
MF>> Брось еще раз, сравню. Проще всего определить через требования к
MF>> характеристикам дизайна. Во-первых, это отсутствие неожиданностей
MF>> в работе кода и соответствие его функциональным требованиям
MF>> (включая реализуемость как таковую), во-вторых - оптимальность
MF>> потребных изменений в текущем коде при поддержке, в третьих -
MF>> оптимизация трудозатрат на развитие, заключающееся в написании
MF>> дополнительного кода.
A>
A> Оч странно что при таких похожих принципах у нас на столько разное
A> понимание.
A> http://www.objectmentor.com/resources/articles/Principles_and_Patterns
A> .PDF см symptoms of rotting design, и соотвественно антонимы это
A> хороший дизайн
A>
MF>> Характеристика "более хорошая" подразумевает критерии, по которым
MF>> зафиксированно превосходство. Каковы эти критерии ?
A>
A> Втрое меньший объем кода,
Единица измерения та же, что и у меня - несжимаемый объем ? Т.е.
количество слов для описания работы кода, которое нельзя уменьшить
без потери информации о его организации ?
Синтаксис - не объем, а форма записи.
A> отсутствие необходимости идти против философии дизайна C++.
А там есть дизайн ? :-) Вроде была свалка заимствованных элементов
других языков, на комбинацию которых ругаются на каждом углу, за
исключением студентов, изучавших c++ одним из первых языков. :-)
A> Что кажется на счет твоих критериев я счита что понятный flow
A> можно получить только совсем откатившись на C, т.к. виртуальные
A> функции, деструкторы и т.п. один хрен ему не способствуют.
Они дают весьма ощутимую пользу при любом дизайне кода и довольно
вольном обращении с памятью. Исключения же приносят пользу при
одних методах программирования и вред при других.
"Моя" модель робастна по отношению к закручиванию гаек - затрудненном
дебаге, повышеным требованиям по бессбойности, регламентирорванной
обработке всех возможных ситуаций и максимально быстром анализе
конкретных участков кода. При этом с ООП она не конфликтует.
Черты предлагаемой тобой модели предполагает оптимизацию под
условия, когда особо драконовские требования не ставятся и
цена ошибки ниже, в противном случае ее плюсы просто
перестают играть роль. Она в конце концов сводится к
аналогу с чисто синтаксическими различиями.
Mikhail.
Anatolix
You wrote to Anatolix on Tue, 04 May 2004 11:34:54 +0400:
A>> При нормальной обработке exception-ов ошибки памяти сами перестают
A>> иметь место быть, ибо они те же exception и откатывают систему именно
A>> на то место где была, как и обычные.
MF> Это про out of memory ? И куда они ее откатят ?
Объект не создастся, операция не выполнится, сервер жив останетя
и будет готовы выполнить что нибудь менее ресурсоемкое.
Anatoliy A. Orlov aka Anatolix. E-mail: anatolix at narod dot ru
[ Q: Может ли настоящий Мастер получить по морде? A: Hастоящий Мастер может
ВСЁ!!! ]