Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>И они будут правы. Тем не менее приемкой занимается тестер, а не ты. SK>Еще раз. С точки зрения тестировщика — да, с точки зрения вышестоящего начальства — нет. Обычно считается (официально) принимает тот, кто несет потом за это ответственность. Ответсвенный, конечно, может это делегировать ниже, но от этого его ответсвенность перед вышестоящим начальством не уходит ни куда.
напимню что разговор начался с того что ты бы не смог читать код для приекми. После выяснения подробностей оказалось что лично ты не занимаешься приемкой, а это делает тестер.
Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации.
G>>Есть план. Но это не помогает когда воссоздать внешние условия сложно. SK>У нас тестируются на данных максимально приближенных к реальным. Поэтому можно на тестах покрыть много чего. Но все, конечно, не покроешь.
Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова.
G>>Потому что разработчик, может лучше качество обеспечить в случае нетривиального приложения. G>>Не факт конечно что захочет. SK>И как поможет ревью, если в системе несколько исполняемых файлов, которые между собой разными путиями коммуницируют (кто-то по TCP/IP, кто-то через файлы, кто-то через базу данных). В этом случае ревью поможет чуть менее, чем ничем. Или если в программе несколько потоков, то гонки между ними при ревью отловить почти что невозможно, ну разве что у человека в голове компилятор зашит. К тому же, как уже сказали, надо точно понимать, что происходит в коде.
Как раз гонки тестами выловить нереально, потому что race condition на машине тестера может не возникать. Кроме того, даже если тест обнаружит concurrency баг, то не сможет определить его место, так как программа упадет сильно позже, чем то место, где проблема появилась и придется читать код чтобы место найти.
Кстаи баги, связанные c race condition очень хорошо видны, они часто возникают при обращении к static полям и данным, явно передаваемым в другой поток. Таких обычно в программе немного.
SK>А чтобы понять, что написали 4 человека, весьма и весьма сложно.
Проще чем протестировать, особенно если задача не сводится реализации алгоритма\ простого интерфейса.
SK>Просто прочитать его как книжку смысла не иммет, разве что отловятся ошибки типа SK>
SK>int i = 0;
SK>for ( i = 0; i < n; i++)
SK>{
SK> ....
SK> for ( i = 5; i < m; i++ )
SK> {
SK> }
SK> ....
SK>}
SK>
А ты пробовал формальный code review проводить? Такое ощущение что нет.
SK>Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку.
Все наборы выходных данных прогнать нельзя, все параметры окружения в тестах учесть нельзя.
Ты говоришь только о функциональном тестировании, которое само по себе не полностью покрывает "качество".
SK>Я, конечно, не хочу занижать твои способности, если ты правда при ревью видишь все ошибки и довольно быстро их находишь, то в твоем случае действительно может быть так и лучше делать. Я, например, слету в чужой код врубиться не смогу. Даже довольно простые функции мне надо сначала посмотреть, потом посмотреть места где она вызывается и только потом принять решение ошибка там или нет. Так что тут может только на одну функцию у меня уйти от 20 мин до 1 часа и при куче кода в пару мегов я просто никогда приемку не закончу.
Этим ты как раз подтвердаешь тезис, что не каждому программисту дано приемкой кода заниматься. Кто-то умеет быстро код читать и восстанавливать мысль автора, но таких мало, обычно программисты умеют писать быстрее, чем читать.
Навык чтения кода можно ( и ИМХО нужно) тренировать, от этого программисты становятся лучше.
Кстати пару мегов кода генерить надо около 3 месяцев. Ты же не будешь плевать в потолок все это время. Ревью имеет смысл делать в процессе. Если ты получешь результат в конце, то и вариантов как-бы нет, только и остается тестировать.
Здравствуйте, gandjustas, Вы писали:
G>А ты первоисточник прочитай, там и ссылка на оригинальное исследование, и само исследование вполне достойное. Довольно глупо отрицать его результаты
G>Вот тебе краткая выжимка — http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html
Вот возьмем, например, regressions tests. Не совсем понятно какие именно 25% тут имеются ввиду?
Поясню.
Всего в программе есть 100 ошибок (это 100%). Из них 10 ошибок это эти самые regression bugs (это 10% от всех) и 90 ошибок это ошибки из нового кода, которые никак не влияют на старый.
Т.е. получается, что при regression tests ловят только 3 ошибки или все-таки они ловят в среднем 25 ошибок?
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 1:48 PM, gandjustas пишет:
>> Вот тебе краткая выжимка — >> http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html >> >> Вообще ошибаться не страшно, страшно не признавать ошибки и называть >> всех вокруг идиотами. V>Ну тогда тебе простой вопрос. Как определялось полное количество ошибок V>в проекте?
Почитай по ссылкам.
V>Лично я не могу даже представить способа определить это?
А в чем проблема? Лезешь в трекер и считаешь кол-во ошибок. В США самые толстые проекты очень плотно обкладываются всяческими метриками и фиксируется буквально все, вплоть до ошибок компиляции. Поэтому по таким проектам есть очень хороршая статистика. Сейчас такую статистику собрать сложнее, ибо в эру стартапов код пишется почти бесконтрольно. Но есть другие исследования, которые показывают что программисты пишу примерно одинаково, независимо от инструментов и языков.
V>Т.е. пойдем от печки, что значит его циферки в процентах, надеюсь не то, V>что в известных анекдотах про проценты.
Сколько в среднем та или иная методика устраняет ошибок. По каждому проекту посчитали процентное соотношение и усреднили. Это конечно вносит искажения, но на большой выборке все стремится к матожиданию.
V>Ну и следующий вопрос — ошибка ошибке рознь, одна ошибка приводит V>программу в состояние неработоспособности или неправильной работы, а V>другая всего-лишь о том, что кнопка не тем цветом нарисована. Это к V>тому, что какие ошибки учитывать в этой оценке, а какие нет?
Традиционный подход — считать дефектами все, вплоть то ошибок компиляции. Такой подход наиболее соответствует воспринимаемому качеству.
Хотя наверное цвета кнопок не учитывались.
V>Ну и сразу еще вопрос. Даже если мы каким-то фантастическим образом V>смогли найти все ошибки в проекте. Но в одном 99% ошибки уровня "не тот V>цвет", а в другом 99% ошибки уровня "не работает и работает не V>правильно". Я так понимаю, что это все учтено и отражено в той книжке?
См выше.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>А ты первоисточник прочитай, там и ссылка на оригинальное исследование, и само исследование вполне достойное. Довольно глупо отрицать его результаты
G>>Вот тебе краткая выжимка — http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html
SK>Вот возьмем, например, regressions tests. Не совсем понятно какие именно 25% тут имеются ввиду? SK>Поясню. SK>Всего в программе есть 100 ошибок (это 100%). Из них 10 ошибок это эти самые regression bugs (это 10% от всех) и 90 ошибок это ошибки из нового кода, которые никак не влияют на старый. SK>Т.е. получается, что при regression tests ловят только 3 ошибки или все-таки они ловят в среднем 25 ошибок?
Распределения по типам ошибок нет, в твоем случае это 25 ошибок будет.
Кстати очень похоже на правду. Если писать тесты после кода для контроля чтобы не поломалось, то потом при доработках примерно четверть ошибок отловит.
Здравствуйте, gandjustas, Вы писали:
G>напимню что разговор начался с того что ты бы не смог читать код для приекми. После выяснения подробностей оказалось что лично ты не занимаешься приемкой, а это делает тестер. G>Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации.
Все-таки повторять мне опять придется. Принимаю работу подрядчика я. Я не гений, читать быстро чужой код не умею. В своем проекте, я конечно, знаю о чем идет речь и тут-то идет у меня все быстрее.
G>Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова.
Reliability покрывается такими же функциональными тестами без проблем. Manageability мне неизвестна.
G>Как раз гонки тестами выловить нереально, потому что race condition на машине тестера может не возникать. Кроме того, даже если тест обнаружит concurrency баг, то не сможет определить его место, так как программа упадет сильно позже, чем то место, где проблема появилась и придется читать код чтобы место найти.
Может не возникать, а может и возникать, поэтому и тестируется на максимально больших и разных наборах данных. У нас их дофига. От разных клиентов и с разными параметрами.
G>Кстаи баги, связанные c race condition очень хорошо видны, они часто возникают при обращении к static полям и данным, явно передаваемым в другой поток. Таких обычно в программе немного.
Мне не нужно точное место этого бага. Мне достаточно, что тестировщик найдет ошибки при тестировании, а что там внутри (race conditions или if (a = 1) .... ) меня уже не касается. Я отдаю набор данных подрядчику, шаги как возпроизхвести баг и все. Дальше там он уже сам разбирается читать ему код или нет.
SK>>А чтобы понять, что написали 4 человека, весьма и весьма сложно. G>Проще чем протестировать, особенно если задача не сводится реализации алгоритма\ простого интерфейса.
Кому как, мне — нет.
G>А ты пробовал формальный code review проводить? Такое ощущение что нет.
Внутри команды всегда.
SK>>Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку. G>Все наборы выходных данных прогнать нельзя, все параметры окружения в тестах учесть нельзя.
Что тут подразумевается под параметрами окружения? Фаза луны? У клиента все настраивается один раз, параметры системы меняются чуть реже, чем никогда. Систему учета товара на складе каждый день параметрироваь не будешь, а так же сервера для БД или еще чего-то раз в год менять тоже не будешь.
G>Ты говоришь только о функциональном тестировании, которое само по себе не полностью покрывает "качество".
Для этих плагинов от подрядчиков нам достаточно только функционаьного тестирования. Потому что это ни что иное как функция для нас. Мы вызвали ее с параметром a, должен получиться результат a/2, если получился a/3, значит что-то там не то.
G>Этим ты как раз подтвердаешь тезис, что не каждому программисту дано приемкой кода заниматься. Кто-то умеет быстро код читать и восстанавливать мысль автора, но таких мало, обычно программисты умеют писать быстрее, чем читать. G>Навык чтения кода можно ( и ИМХО нужно) тренировать, от этого программисты становятся лучше.
Я не занимаю приемкой кода, я делаю приемку модуля, а точнее приемку функциональности этого модуля, как он там внутри реализован мне абсолютно фиолетово, мне важно, чтобы при определенном наборе входных данных я получал нужный мне результат за нужный мне отрезок времени. Если например при объеме данных X мне нужен результат через время t, а он приходит через время t*2, то я говорю подрядчику, что "модуль не принят, не удовлетворяет спецификации. Работай дальше". И он работает.
G>Кстати пару мегов кода генерить надо около 3 месяцев. Ты же не будешь плевать в потолок все это время. Ревью имеет смысл делать в процессе. Если ты получешь результат в конце, то и вариантов как-бы нет, только и остается тестировать.
Кто бы мог подумать, что ревью надо делать в процессе. Только вот результат я получаю в конце. По крайней мере когда уже есть первая pre-alpha версия, которая хотя бы чего-то может, просто чтобы определить движется ли подрядчик в правильном направлении. И даже уже эту pre-alpha не отревьюешь за пару дней.
SVZ>>По моему опыту ревью ловит только стилистические отклонения от Code Standard и потенциальные ошибки, которые просто бросаются в глаза (типа неуместного использования new/delete в С++ коде). G>Это значит что ты код смотрел, а не читал.
Читал это высказывание. Смотрел в картинку в твоей подписи. Вспоминал анекдот про "либо крестик, либо трусы". Много думал.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>напимню что разговор начался с того что ты бы не смог читать код для приекми. После выяснения подробностей оказалось что лично ты не занимаешься приемкой, а это делает тестер. G>>Если бы приемкой занимался ты, то быстро бы понял (я надеюсь) что код читать получается быстрее, чем тесты гонять. Особенно в сложных проектах, где недостаточно соотвествия функциональной спецификации. SK>Все-таки повторять мне опять придется. Принимаю работу подрядчика я. Я не гений, читать быстро чужой код не умею. В своем проекте, я конечно, знаю о чем идет речь и тут-то идет у меня все быстрее.
Руками делает тестер, а не ты.
G>>Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова. SK>Reliability покрывается такими же функциональными тестами без проблем. Manageability мне неизвестна.
Интересно...
Как проверить что код не развалится и не положит все остальное при удалении сервера из фермы? Или при изменении доступов?
G>>Кстаи баги, связанные c race condition очень хорошо видны, они часто возникают при обращении к static полям и данным, явно передаваемым в другой поток. Таких обычно в программе немного. SK>Мне не нужно точное место этого бага. Мне достаточно, что тестировщик найдет ошибки при тестировании, а что там внутри (race conditions или if (a = 1) .... ) меня уже не касается. Я отдаю набор данных подрядчику, шаги как возпроизхвести баг и все. Дальше там он уже сам разбирается читать ему код или нет.
У тебя очень хорошие подрядчики. Обычно бывает так:
1) Подрядчики не находят race condition потому что тестирует один пользователь
2) UAT не находят race condition потому что тестирует один пользователь
3) В продакшене возникает баг почти сразу
4) Тестеры не могут воспроизвести
5) Инженер долго ковыряется на продакшене, смотрит логи, в конце-концов понимает что бага в race condition
6) Тестеры делают новый тест на race condition, выясняют что бага есть
6) Начинаешь пинать подрядчиков, они мамой клянутся что все работает (у них теста на race condition нет)
7) Ругаешься с ними, они долго тупят и не понимают как найти место где возникает race condition, отправляют тебе пару нерабочих версий
8) Наконец происходит озарение и подрядчики чинят баг.
По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз.
И это кстати реальная история.
SK>>>А чтобы понять, что написали 4 человека, весьма и весьма сложно. G>>Проще чем протестировать, особенно если задача не сводится реализации алгоритма\ простого интерфейса. SK>Кому как, мне — нет.
Я уже понял что для тебя сложно код читать, но есть статистика, которая говорил что формальные review эффективнее тестов.
G>>А ты пробовал формальный code review проводить? Такое ощущение что нет. SK>Внутри команды всегда.
Помогает?
SK>>>Но и при тестировании может показать, что в таком-то модуле при таких-то действиях выходные данные не те, которые нужны и дальше уже программисты ищут ошибку. G>>Все наборы выходных данных прогнать нельзя, все параметры окружения в тестах учесть нельзя. SK>Что тут подразумевается под параметрами окружения? Фаза луны? У клиента все настраивается один раз, параметры системы меняются чуть реже, чем никогда. Систему учета товара на складе каждый день параметрироваь не будешь, а так же сервера для БД или еще чего-то раз в год менять тоже не будешь.
Ключевое выделил. Если окружение полностью котролируемо, то проблем таких почти нет. А когда могут пооменяться: учетки, права, код может переехать на другой сервер без твоего ведома, серваки могут добавляться и удаляться, могут ставиться другие приложения, которые что-то делают, админы могут менять логику итд.
G>>Ты говоришь только о функциональном тестировании, которое само по себе не полностью покрывает "качество". SK>Для этих плагинов от подрядчиков нам достаточно только функционаьного тестирования. Потому что это ни что иное как функция для нас. Мы вызвали ее с параметром a, должен получиться результат a/2, если получился a/3, значит что-то там не то.
Значит ничего сложного подрядчики не делают если таких тестов достаточно.
G>>Этим ты как раз подтвердаешь тезис, что не каждому программисту дано приемкой кода заниматься. Кто-то умеет быстро код читать и восстанавливать мысль автора, но таких мало, обычно программисты умеют писать быстрее, чем читать. G>>Навык чтения кода можно ( и ИМХО нужно) тренировать, от этого программисты становятся лучше. SK>Я не занимаю приемкой кода, я делаю приемку модуля, а точнее приемку функциональности этого модуля, как он там внутри реализован мне абсолютно фиолетово, мне важно, чтобы при определенном наборе входных данных я получал нужный мне результат за нужный мне отрезок времени. Если например при объеме данных X мне нужен результат через время t, а он приходит через время t*2, то я говорю подрядчику, что "модуль не принят, не удовлетворяет спецификации. Работай дальше". И он работает.
Я по моему писал уже, что далеко не всегда достаточно удовлетворения только функциональных требований. Как минимум код еще поддерживать надо. И это должно быть дешевле, чем код писать. Как это тестами покроешь?
G>>Кстати пару мегов кода генерить надо около 3 месяцев. Ты же не будешь плевать в потолок все это время. Ревью имеет смысл делать в процессе. Если ты получешь результат в конце, то и вариантов как-бы нет, только и остается тестировать. SK>Кто бы мог подумать, что ревью надо делать в процессе. Только вот результат я получаю в конце. По крайней мере когда уже есть первая pre-alpha версия, которая хотя бы чего-то может, просто чтобы определить движется ли подрядчик в правильном направлении. И даже уже эту pre-alpha не отревьюешь за пару дней.
Мне кажется что тебе очень повезло с подрядчиками если при таком подходе проблем нет. Или с проектом.
1/15/2014 2:35 PM, gandjustas пишет:
> Почитай по ссылкам.
ЧТД.
> V>Лично я не могу даже представить способа определить это? > А в чем проблема? Лезешь в трекер и считаешь кол-во ошибок.
Упс. В трекере может быть как 100% ошибок, так и 3% от всех возможных
ошибок, которые просто не были обнаружены. Уже здесь левое предположение
о том, что в трекере 100% ошибок.
> Сколько в среднем та или иная методика устраняет ошибок. По каждому > проекту посчитали процентное соотношение и усреднили. Это конечно вносит > искажения, но на большой выборке все стремится к матожиданию.
Жесть. С такими подходами я тебе любые циферки по любым исходным данным
нарисую.
> Традиционный подход — считать дефектами все, вплоть то ошибок > компиляции.
Еще круче.
> См выше.
Да я понял. Очередная туфта ни о чем, точнее о том, что мужик умница
написал книжек несколько и заработал на их продаже денег.
З.Ы. Или это ты настолько "хорошо" Макконела понял, или он еще тот
разводящий.
З.З.Ы. А по сути куча ни на чем не основанных допущении и на основе этих
допущений некие глобальные выводы.
Здравствуйте, gandjustas, Вы писали:
G>>>Я говорю не про функциональное тестирование. Есть немало проектов где функционал составляет не более 50% качества всего решения, остальное это UX, manageability, reliability и прочие страшные слова. SK>>Reliability покрывается такими же функциональными тестами без проблем. Manageability мне неизвестна. G>Интересно... G>Как проверить что код не развалится и не положит все остальное при удалении сервера из фермы? Или при изменении доступов?
Сервера не "исчезают" просто так, к тому же в таких крупных конторах как наши клиенты.
Изменение доступа тоже просто так не происходит, чтобы там на продакшене что-то поменять админ перед этим должен получить кучу разрешений.
G>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>И это кстати реальная история.
Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются.
G>Я уже понял что для тебя сложно код читать, но есть статистика, которая говорил что формальные review эффективнее тестов.
Я не знаю на основе чего собрана эта статистика, я вообще статистикам не особо доверяю. Там можно нарисовать все что угодно.
Вот я возьму создам свою статистику где напишу, что собирались данные по 10 тыс проектов и результат — тесты эффективнее ревью. И это никак не опровергнешь, потому что все данные по всем проектом нигде не выложены в открытом доступе.
G>Помогает?
Конечно.
G>Ключевое выделил. Если окружение полностью котролируемо, то проблем таких почти нет. А когда могут пооменяться: учетки, права, код может переехать на другой сервер без твоего ведома, серваки могут добавляться и удаляться, могут ставиться другие приложения, которые что-то делают, админы могут менять логику итд.
Если админ просто так меняет логику на продакшене и в результате этого что-то происходит с системой, то он несет за это ответсвенность. Тоже самое, если вдруг удалить исполняемый файл (или модуль) и потом удивляться, что что-то не так работает.
G>Значит ничего сложного подрядчики не делают если таких тестов достаточно.
С нашей точки зрения нет. Для нас они пишут одну большую функцию, а реализована ли она сложно или просто я не знаю.
G>Я по моему писал уже, что далеко не всегда достаточно удовлетворения только функциональных требований. Как минимум код еще поддерживать надо. И это должно быть дешевле, чем код писать. Как это тестами покроешь?
Код поддерживает подрядчик. Так что это в его интересах написать его хорошо.
G>Мне кажется что тебе очень повезло с подрядчиками если при таком подходе проблем нет. Или с проектом.
Всякие бывают. Вот был проект с Казино в Австрии. Была там одна фирма, которая поставляла туда видеорегистраторы. У них была API для доступа к видео, архиву и прочему. Так вот проблема возникала только у клиента. В итоге после 2х или 3х месяцев борьбы с этими поставщиками выяснилось, что проблема возникала на компьютерах, где стояли 4х ядерные процы. На 2х ядерных было еще все нештяг.
Предупреждая твой вопрос о ревью скажу, что доступа к коду этого производителя у нас не было, да и я бы все равно в него бы смотреть не стал. Приложение, которое по сети запрашивает видо с регистратора, декодирует mpeg4 и показывает Live-Video или архив не такое уж и тривиальное, чтобы там быстро найти ошибку такую ошибку.
Да и вообще в Европе не принято отдавать код. Если хочешь его позырить — покупай всю контору целиком. И не важно разовая эта работа или же коробочный продукт.
Здравствуйте, gandjustas, Вы писали:
G>У тебя очень хорошие подрядчики. Обычно бывает так: G>1) Подрядчики не находят race condition потому что тестирует один пользователь G>2) UAT не находят race condition потому что тестирует один пользователь G>3) В продакшене возникает баг почти сразу G>4) Тестеры не могут воспроизвести G>5) Инженер долго ковыряется на продакшене, смотрит логи, в конце-концов понимает что бага в race condition G>6) Тестеры делают новый тест на race condition, выясняют что бага есть G>6) Начинаешь пинать подрядчиков, они мамой клянутся что все работает (у них теста на race condition нет) G>7) Ругаешься с ними, они долго тупят и не понимают как найти место где возникает race condition, отправляют тебе пару нерабочих версий G>8) Наконец происходит озарение и подрядчики чинят баг.
Вообще-то это называется: "бардак обыкновенный". Но мне больше всего понравилось про "мамой клянутся".
Ну и совет. Послушай оппонента SD и постарайся хоть чуть приблизить вашу работу к его.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 2:35 PM, gandjustas пишет:
>> Почитай по ссылкам. V>ЧТД.
Значит не читал
>> V>Лично я не могу даже представить способа определить это? >> А в чем проблема? Лезешь в трекер и считаешь кол-во ошибок. V>Упс. В трекере может быть как 100% ошибок, так и 3% от всех возможных V>ошибок, которые просто не были обнаружены. Уже здесь левое предположение V>о том, что в трекере 100% ошибок.
Думаешь люди, которые проводили анализ об этом не знали? Обычно анализ проводится на завершенных проектах.
Кстати в их понятии "завершенный" означает что не просто акты подписали.
>> Сколько в среднем та или иная методика устраняет ошибок. По каждому >> проекту посчитали процентное соотношение и усреднили. Это конечно вносит >> искажения, но на большой выборке все стремится к матожиданию. V>Жесть. С такими подходами я тебе любые циферки по любым исходным данным V>нарисую.
Нарисуй, в чем проблема?
>> См выше. V>Да я понял. Очередная туфта ни о чем, точнее о том, что мужик умница V>написал книжек несколько и заработал на их продаже денег.
О как-бы на исследования опирается, сам ничего не придумал. Исследования гуглятся.
V>З.Ы. Или это ты настолько "хорошо" Макконела понял, или он еще тот V>разводящий. V>З.З.Ы. А по сути куча ни на чем не основанных допущении и на основе этих V>допущений некие глобальные выводы.
См. то что я написал выше.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>>И это кстати реальная история. SK>Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются.
А трудозатраты на тестирование тогда как окупаются?
G>>Я уже понял что для тебя сложно код читать, но есть статистика, которая говорил что формальные review эффективнее тестов. SK>Я не знаю на основе чего собрана эта статистика, я вообще статистикам не особо доверяю. Там можно нарисовать все что угодно. SK>Вот я возьму создам свою статистику где напишу, что собирались данные по 10 тыс проектов и результат — тесты эффективнее ревью. И это никак не опровергнешь, потому что все данные по всем проектом нигде не выложены в открытом доступе.
Ок, создай.
G>>Ключевое выделил. Если окружение полностью котролируемо, то проблем таких почти нет. А когда могут пооменяться: учетки, права, код может переехать на другой сервер без твоего ведома, серваки могут добавляться и удаляться, могут ставиться другие приложения, которые что-то делают, админы могут менять логику итд. SK>Если админ просто так меняет логику на продакшене и в результате этого что-то происходит с системой, то он несет за это ответсвенность. Тоже самое, если вдруг удалить исполняемый файл (или модуль) и потом удивляться, что что-то не так работает.
Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться.
G>>Я по моему писал уже, что далеко не всегда достаточно удовлетворения только функциональных требований. Как минимум код еще поддерживать надо. И это должно быть дешевле, чем код писать. Как это тестами покроешь? SK>Код поддерживает подрядчик. Так что это в его интересах написать его хорошо.
Он же за это деньги получает, ему выгодно побольше на поддержке сшибать.
SK>Да и вообще в Европе не принято отдавать код. Если хочешь его позырить — покупай всю контору целиком. И не важно разовая эта работа или же коробочный продукт.
Очень повезло. Все друг другу доверяют и не нае... обманывают.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>У тебя очень хорошие подрядчики. Обычно бывает так: G>>1) Подрядчики не находят race condition потому что тестирует один пользователь G>>2) UAT не находят race condition потому что тестирует один пользователь G>>3) В продакшене возникает баг почти сразу G>>4) Тестеры не могут воспроизвести G>>5) Инженер долго ковыряется на продакшене, смотрит логи, в конце-концов понимает что бага в race condition G>>6) Тестеры делают новый тест на race condition, выясняют что бага есть G>>6) Начинаешь пинать подрядчиков, они мамой клянутся что все работает (у них теста на race condition нет) G>>7) Ругаешься с ними, они долго тупят и не понимают как найти место где возникает race condition, отправляют тебе пару нерабочих версий G>>8) Наконец происходит озарение и подрядчики чинят баг. V>Вообще-то это называется: "бардак обыкновенный". Но мне больше всего понравилось про "мамой клянутся". V>Ну и совет. Послушай оппонента SD и постарайся хоть чуть приблизить вашу работу к его.
В России и странах СНГ так чуть менее, чем везде. Почти все конторы, которые зарабатывают аутсорсингом кодирования жестко экономят на разработчиках и на контроле качества. А эффективные менеджеры прекрасно знают формулу "у нас все работает — проблема на вашей стороне".
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, SkyKnight, Вы писали:
SK>>Здравствуйте, gandjustas, Вы писали:
G>>>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>>>И это кстати реальная история. SK>>Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются. G>А трудозатраты на тестирование тогда как окупаются?
Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов.
G>Ок, создай.
Да ради Бога.
Вот в течение 10 лет собирал статистику по проектам. В итоге была собрана статистика по 10 тыс проектов. Статистика показала, что тестирование в 4 раза эффективнее ревью.
G>Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться.
На продакшене любые действия админа без разрешения вышестоящих людей являются незаконными. Потому что если в результате его дейтствий случится что-то с операционной системой ему настанет такой кирдык, что засовывание ведра в задницу покажется райским наслаждением по сравнению с этим кирдыком.
G>Он же за это деньги получает, ему выгодно побольше на поддержке сшибать.
Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия. Далее за кажый баг срубается деньга в зависимости от наглости подрядчика. А ты уже решаешь хочешь ты его пофиксенным или нет.
Внесение новых фич оговаривается и оплачивается отдельно. В любом случае, если я заказываю работу на стороне (модуль), то в зависимости от внутренних ресурсов потом решаю, переносить дальнейшее развитие этого модуля к себе или оставлять там снаружи. Зачастую получается дешевле оставить разработку и поддержку на всегда внешей конторе. Если же ясно, что модуль всегда останется "у них", то и исходники мне нафиг не нужны.
Если же еще в самом начале ясно, что модуль потом перейдет в нашу контору на дальнейшее развитие, то понятно, что и исходники надо будет забирать, в этом случае да, подписывается такой контракт, что исходники передаются полногстью нам, включая полную документацию и прочее, прочее. Такие контракты обычно стоят дороже, потому что подрядчику надо еще тратить время на написание очень подробной документации.
G>Очень повезло. Все друг другу доверяют и не нае... обманывают.
А зачем обманывать?
1/15/2014 4:26 PM, gandjustas пишет:
> В России и странах СНГ так чуть менее, чем везде. Почти все конторы, > которые зарабатывают аутсорсингом кодирования жестко экономят на > разработчиках и на контроле качества. А эффективные менеджеры прекрасно > знают формулу "у нас все работает — проблема на вашей стороне".
Вот об этом тебе уже не раз намекнули, а ты еще и макконела к этому
приплетаешь, причем еще и не поняв толком того, что он писал. А SK пишет
о конторах с нормальными методами работы.
Про тут часто и говорить стыдно про организацию разработки и приемки, в
подавляющем большинстве случаев карго-культ с агилей, а в реальности "у
меня все работает", а директора уже новый поршекаены купили и давно все
приняли и сдали.
Да, продуктовые местные конторы часто еще хуже аутсорсинговых,
аутсорсеров еще западные заказчики могут и наказать, а продуктовые в
подавляющем большинстве на госзаказах живут.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, SkyKnight, Вы писали:
SK>>>Здравствуйте, gandjustas, Вы писали:
G>>>>По времени 1-8 занимает две недели и более. Если читать код на шаге 1, то можно количество таких случаев сократить на 60%, по времени можно выйграть на порядок, по трудозатратам в 10 раз. G>>>>И это кстати реальная история. SK>>>Ну да, так тоже случается. Не без этого. Но случается это довольно редко, поэтому трудозатраты на кодревью кода подрятчика никак не окупаются. G>>А трудозатраты на тестирование тогда как окупаются? SK>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов.
То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее?
G>>Ок, создай. SK>Да ради Бога. SK>Вот в течение 10 лет собирал статистику по проектам. В итоге была собрана статистика по 10 тыс проектов. Статистика показала, что тестирование в 4 раза эффективнее ревью.
У меня ровно наоборот, а еще и исследования есть, которые подтверждают мою точку зрения.
G>>Админ делает вполне законные, с точки зрения платформы, действия. А решение на рассчитано что такие действия будут производиться. SK>На продакшене любые действия админа без разрешения вышестоящих людей являются незаконными. Потому что если в результате его дейтствий случится что-то с операционной системой ему настанет такой кирдык, что засовывание ведра в задницу покажется райским наслаждением по сравнению с этим кирдыком.
Читай выделенное.
G>>Он же за это деньги получает, ему выгодно побольше на поддержке сшибать. SK>Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия.
а сколько вы подрядчикам за такое платите?
G>>Очень повезло. Все друг другу доверяют и не нае... обманывают. SK>А зачем обманывать?
Философский вопрос. Я не знаю ответа на него, знаю лишь что в России везде так.
Неочень честная конкуренция построенная на ассиметричности информации.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 4:26 PM, gandjustas пишет:
>> В России и странах СНГ так чуть менее, чем везде. Почти все конторы, >> которые зарабатывают аутсорсингом кодирования жестко экономят на >> разработчиках и на контроле качества. А эффективные менеджеры прекрасно >> знают формулу "у нас все работает — проблема на вашей стороне". V>Вот об этом тебе уже не раз намекнули, а ты еще и макконела к этому V>приплетаешь, причем еще и не поняв толком того, что он писал. А SK пишет V>о конторах с нормальными методами работы.
Он пишет о европе, а я о России. Там подрядчики сдают код с плотностью ошибок в 10 раз меньше, а заказчики платят в 2 раза больше за час работы.
Тем не менее на defect removal rate это никак не влияет, просто при такой разнице в качестве работы эта разница в defect removal rate становится незначительной.
Здравствуйте, Vzhyk, Вы писали:
V>1/15/2014 4:26 PM, gandjustas пишет:
>> В России и странах СНГ так чуть менее, чем везде. Почти все конторы, >> которые зарабатывают аутсорсингом кодирования жестко экономят на >> разработчиках и на контроле качества. А эффективные менеджеры прекрасно >> знают формулу "у нас все работает — проблема на вашей стороне". V>Вот об этом тебе уже не раз намекнули, а ты еще и макконела к этому V>приплетаешь, причем еще и не поняв толком того, что он писал. А SK пишет V>о конторах с нормальными методами работы.
Ну и основной фактор у SK — код не передают, без него review не сделаешь, так что разговор ни о чем.
Здравствуйте, SkyKnight, Вы писали:
SK>Первые 2 года после покупки или приемки баги фиксятся бесплатно. Гарантия. Далее за кажый баг срубается деньга в зависимости от наглости подрядчика. А ты уже решаешь хочешь ты его пофиксенным или нет. SK>Внесение новых фич оговаривается и оплачивается отдельно. В любом случае, если я заказываю работу на стороне (модуль), то в зависимости от внутренних ресурсов потом решаю, переносить дальнейшее развитие этого модуля к себе или оставлять там снаружи. Зачастую получается дешевле оставить разработку и поддержку на всегда внешей конторе. Если же ясно, что модуль всегда останется "у них", то и исходники мне нафиг не нужны. SK>Если же еще в самом начале ясно, что модуль потом перейдет в нашу контору на дальнейшее развитие, то понятно, что и исходники надо будет забирать, в этом случае да, подписывается такой контракт, что исходники передаются полногстью нам, включая полную документацию и прочее, прочее. Такие контракты обычно стоят дороже, потому что подрядчику надо еще тратить время на написание очень подробной документации.
Блин, круто. Неужели в мире где-то так организована работа?
Я в восхищении.
Я помню французский RECIF, немецкий АТОТЕСН — бардак был близкий к местному здесь. Про аустрсорсеров наших и не говорю, втюхать заказчику фигню и забить. Говоришь начальнику можно на 3 часа говно, типа работающее, или за 3-5 дней качественно и правильно, начальник говорит за 3 часа.
1/15/2014 4:56 PM, gandjustas пишет:
> А ты где работаешь, в Европе ли в России?
В РБ и РФ и прекрасно знаю наш местный бардак и дичающую любовь всех
кинуть всех остальных вокруг.
А да, если бы я работал в Европе, то меня бы здесь на кывте не было бы —
это здесь я использую данный форум для психотерапии.
