K>Что и требовалось доказать. Что было бы не сказано или сделано, менеджер всегда "виноват" на rsdn. Честно говоря я другого не ожидал. Очень четко прослеживается данная линия в других ветках где заходит разговор про менеджеров.
И не на RSDN тоже. Это входит в его обязанности — проследить, выяснить. За это менеджер и получает свою зарплату. Другое дело что никакой менеджер не может быть на 100% настороже, и ругать его за каждую промашку — все равно что ругать инженера за каждый баг в закоммиченном коде.
, почему на исполнителей (разработчиков, инженеров и т.п.) делегировать ответственность малореально. Вкратце — у них нет рычагов влияния на процесс. Тех, что есть только у руководства.
Здравствуйте, enji, Вы писали:
E>Наткнулся на интересное
Прочитал полный текст и у меня один вывод — виноваты ВСЕ, кроме самого несчастного программиста.
Во-первых, за кадром остался руководитель программиста. По всей видимости, это тим лид. Судя по полной версии истории, он сам первоначально "разругался" с подрядчиком. Затем пошел "на попятную" и померился, но не смог убедить продолжить работу своего подчиненного — программиста.
По хорошему, вопросы "убеждения" выполнения технической части лежат именно на тим. лиде. Именно он должен доносить ТЗ до программистов, отстаивать свое видение решения проблемы и отчитываться перед менеджерами. Не справляется? Пусть выгоняет программиста и интергрируется с подрядчиком самостоятельно. Не может? Гнать "погаными тряпками" уже его и искать другого тим. лида.
Во-вторых. Как я понимаю, программист работает уже достаточно давно и именно поэтому ему доверили столь ответственную часть (интеграцию с продуктом, написанным сторонней командой). Если так, то вы ранее не знали, какой у человека характер и какой нужен к нему подход? Действительно, есть такой тип программистов, для которых надо ставить максимально сложные задачи с минимально трудоемкой интеграцией их модулей. Если он именно такой, то руководитель серьезно ошибся поставив его выполнять задачу по интеграции, где нужна гибкость.
В-третьих, может быть подрядчик действительно работает хреново? Если так, то почему бы не поговорить с программистом "по человечески" и не объяснить, что первую версию выпустим согласно первоначальному плану. Далее, после выпуска первого релиза, спокойно "переделаешь самостоятельно" и будем поддерживать уже твое решение. Судя по моему опыту, гораздо проще проект поддерживать своей командой. В противном случае, даже для любого минимального исправления приходится согласовывать ТЗ + обосновывать расходы "на фичу" перед руководством. То и другое крайне тормозит развитие проекта.
Здравствуйте, gandjustas, Вы писали:
SK>>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов. G>То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее?
Вот тебе простой пример.
Самый обычный SQL запрос. На одной и той же базе данных в зависимости от настроект оптимизатора выполняется от 0.1 сек до 58 сек.
Найди ошибку при ревью
SELECT SUM(Art.ArtGfgGew * Bst.BstMg) AS AktMenge
FROM Art_T Art, Bst_T Bst, Te_T Te, Pl_T Pl, Be_T Be
WHERE Art.ArtKnzGfgOk = 1
AND Art.ArtKnzGfg = 1
AND Te.TeKnzGfg = 1
AND ( 1 = 0 OR Art.ArtKlaGfgLg = 952 )
AND ( 0 = 0 OR Art.ArtKlaGfgWass = 0 )
AND Pl.WmgeBeNam = 'LHR2'
AND Art.ArtId = Bst.ArtId
AND Bst.TeNamTrg = Te.TeNam
AND Te.PlNam = Pl.PlNam
AND Be.BeNam = Pl.BeNam;
Это обычный sql запрос для Oracle. ничего такого особенного в нем нет, но вот тупит. Этот запрос, кстати, был тоже проревьюен.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
SK>>>Трудозатраты на тестирование внесены в смету проекта. Т.е. из опыта мы уже примерно знаем, что на тестирование модуля надо будет 50 часов. Трудозатраты на ревью в смету проекта я внести явно не могу, т.е. надо будет выдумывать какую-нибудь статью расходов. G>>То есть вопрос только в том как назвать позиции в смете, а в остальном ревью таки выгоднее? SK>Вот тебе простой пример. SK>Самый обычный SQL запрос. На одной и той же базе данных в зависимости от настроект оптимизатора выполняется от 0.1 сек до 58 сек. SK>Найди ошибку при ревью
SK>Это обычный sql запрос для Oracle. ничего такого особенного в нем нет, но вот тупит. Этот запрос, кстати, был тоже проревьюен.
Сразу в глаза бросается:
1) Нечитаемые имена, семантика запроса не ясна
2) Непонятно где условия join, а где выборка
Оба фактора затрудняют дальнейший анализ.
А вообще review делается для проверки корректности и сопровождаемости кода, оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла.
Здравствуйте, gandjustas, Вы писали:
G>Сразу в глаза бросается: G>1) Нечитаемые имена, семантика запроса не ясна
По-немецки еще как читаемы. G>2) Непонятно где условия join, а где выборка
что там непонятного? Все видно.
G>А вообще review делается для проверки корректности и сопровождаемости кода,
Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки.
G>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла.
Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации.
Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области.
Ну а так, индексов было наоборот слишком много, причем воспроизводится тупит этот запрос только если optimizer_mode установлен в Rule.
Здравствуйте, alexsoff, Вы писали:
SK>>AND ( 1 = 0 )
A>Прошу прощения за оффтопик, а что за странные условия 1=0, это оптимизация в оракле такая хитрая?
Такое обычно делают, чтобы выбрать только названия столбцов. Конкретно, что происходит в запросе х.з. — это надо у автора говнокода спрашивать, да и он уже скорее всего уже не знает. Вот для этого, в том числе, код-ревью и нужен, чтобы в продакшн не попал "совсем понятный, простой и очевидный запрос".
Здравствуйте, MTD, Вы писали:
MTD>Такое обычно делают, чтобы выбрать только названия столбцов.
АА вон как, я просто использую только ms sql,а там это делается через более очевидный оператор TOP 0
Здравствуйте, alexsoff, Вы писали:
A>Здравствуйте, SkyKnight, Вы писали:
SK>>AND ( 1 = 0 OR Art.ArtKlaGfgLg = 952 ) SK>>AND ( 0 = 0 OR Art.ArtKlaGfgWass = 0 )
A>Прошу прощения за оффтопик, а что за странные условия 1=0, это оптимизация в оракле такая хитрая?
Скажем так, один и тот же запрос используется для поиска суммы, скажем количества товара, в одном случае по одному критерию (ArtKlaGfgLg), а в другом случае по ArtKlaGfgWass.
Эти запросы сначала кладутся в xml файло, из этого xml для каждого запроса автоматом при постройки системы делается свой класс.
Т.е. можно было бы запрос разбить на 2, тогда было бы на 1 класс в C++ больше. Поэтому тут они ввели такую практику, что пишется один запрос и с помощью вот этих 1 = 0 или 0 = 0 отключается или включается то или иное условие.
В этом случае идет выборка по ArtKlaGfgLg = 952, условие ArtKlaGfgWass = 0 не проверяется.
В C++ коде вызов этого запроса выглядит примерно так
sqlBlaBlaBla oSql(... 1, 952, 0, 0);
в приницпе можно написать и так
sqlBlaBlaBla oSql(... 1, 952, 0, 34646);
в итоге из этого сгенерируется
AND ( 1 = 0 OR Art.ArtKlaGfgLg = 952 )
AND ( 0 = 0 OR Art.ArtKlaGfgWass = 34646 )
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Сразу в глаза бросается: G>>1) Нечитаемые имена, семантика запроса не ясна SK>По-немецки еще как читаемы.
Даже по немецки это набор сокращений. ухудшает читаемость, никуда от этого не денешься.
G>>2) Непонятно где условия join, а где выборка SK>что там непонятного? Все видно.
Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден.
G>>А вообще review делается для проверки корректности и сопровождаемости кода, SK>Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки.
А о чем ты говорил?
G>>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла. SK>Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации.
А кто-то говорил что review помогает оптимизировать? Максимум можно какиенить антипаттерны обнаружить, не более того.
SK>Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области.
Не понял на основе чего ты сделал вывод. Тесты тоже не помогают оптимизировать. Ревью дает гораздо больше тестов, есть статистика на этот счет.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, SkyKnight, Вы писали:
SK>>Здравствуйте, gandjustas, Вы писали:
G>>>Сразу в глаза бросается: G>>>1) Нечитаемые имена, семантика запроса не ясна SK>>По-немецки еще как читаемы. G>Даже по немецки это набор сокращений. ухудшает читаемость, никуда от этого не денешься.
По-немецки нормально читается. я даже когда в эту контору только пришел и увидел эти сокращения понял о чем речь. К тому же есть документы как у них принято сокращать. В это плане читаемость не падает совершенно.
G>Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден.
Там два условия выборки только, все остальное join и видно это невооруженным взглядом.
G>>>А вообще review делается для проверки корректности и сопровождаемости кода, SK>>Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки. G>А о чем ты говорил?
Я и говорил, что ревью поможет для проверки корректности с сопровождаемости кода. Чтобы в код не попадало типа if ( bIsSomethingNeeded.toString().Length == 4 ) ....
А так же неправильное использование операторов new и ошибки типа if (a = 1) ....
G>>>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла. SK>>Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации. G>А кто-то говорил что review помогает оптимизировать? Максимум можно какиенить антипаттерны обнаружить, не более того.
SK>>Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области. G>Не понял на основе чего ты сделал вывод. Тесты тоже не помогают оптимизировать.
Тесты помогают найти вот такие неоптимальные места. Это разве не помогает?
G>Ревью дает гораздо больше тестов, есть статистика на этот счет.
А статистика, она такая статистика. У меня своя статистика, которая говорит об обратном.
Я уже какой раз говорю, что подходы комбинировать надо. Один подход не даст никакой эффективности.
Вот жаль у меня кода нет, а то я бы скинул исходники API для видео-регистраторов. Я бы посмотрел, как бы ты ревью этого кода делал, особенно если нет знаний в предметной области.
Здравствуйте, SkyKnight, Вы писали:
G>>Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден. SK>Там два условия выборки только, все остальное join и видно это невооруженным взглядом.
Точно восемь условий джойна там? Можешь назвать два условия выборки по твоей версии?
Мне лично кажется, что концептуально там либо 3, либо 4 параметра джойна, в зависимости от того, чего же хотел добиться автор.
И соответственно, то ли 6, то ли 7 условий выборки.
Вот это условие (and Be_T.BeТam = Pl.BeNam) — оно что из себя представляет? Это джойн всех записей Be_T, или неоднозначно
записанное условие (and Pl.BeNam in (select BeNam from Be_T))?
Здравствуйте, _ABC_, Вы писали:
_AB>Мне лично кажется, что концептуально там либо 3, либо 4 параметра джойна, в зависимости от того, чего же хотел добиться автор. _AB>И соответственно, то ли 6, то ли 7 условий выборки.
5 или 6 условий выборки (в зависимости от) и 3 условия join. Я не много запутался, признаю. Забыл про эти параметры, которые "= 1"
_AB>Вот это условие (and Be_T.BeТam = Pl.BeNam) — оно что из себя представляет? Это джойн всех записей Be_T, или неоднозначно _AB>записанное условие (and Pl.BeNam in (select BeNam from Be_T))?
Оно тут вообще не нужно и уже удалено. Это можно игнорировать. Вообще это join, но это лишнее.
Ответ не тебе, а gandjustas: условия выборки и join не "перемешаны".
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, alexsoff, Вы писали:
SK>>>AND ( 1 = 0 )
A>>Прошу прощения за оффтопик, а что за странные условия 1=0, это оптимизация в оракле такая хитрая?
MTD>Такое обычно делают, чтобы выбрать только названия столбцов. Конкретно, что происходит в запросе х.з. — это надо у автора говнокода спрашивать, да и он уже скорее всего уже не знает. Вот для этого, в том числе, код-ревью и нужен, чтобы в продакшн не попал "совсем понятный, простой и очевидный запрос".
Это стандартно. Приходит кто-то смотрит пол секунды, объявляет кусок кода говнокодом и начинает это все оптимизировать, при этом не спросив у "долгожителей" конторы "а почему так, а не так?". И вот если после этого вопроса выяснится, что да, действительно, это говнокод, тогда можно его переписывать. Все остальное — убийство времени.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, SkyKnight, Вы писали:
SK>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Сразу в глаза бросается: G>>>>1) Нечитаемые имена, семантика запроса не ясна SK>>>По-немецки еще как читаемы. G>>Даже по немецки это набор сокращений. ухудшает читаемость, никуда от этого не денешься. SK>По-немецки нормально читается. я даже когда в эту контору только пришел и увидел эти сокращения понял о чем речь. К тому же есть документы как у них принято сокращать. В это плане читаемость не падает совершенно.
G>>Еще раз — смешение условий выборки и джоинов ухудшает читаемость. Для любого здравого человка сей факт очевиден. SK>Там два условия выборки только, все остальное join и видно это невооруженным взглядом.
Это лишь твое мнение, а факт остается фактом. Читаемость код гораздо ниже, чем могла бы быть.
Я кажется начал понимать почему ты так против ревью. Критика всегда плохо воспринимается программистами, ты не одинок.
G>>>>А вообще review делается для проверки корректности и сопровождаемости кода, SK>>>Вот о чем я и говорил. Такое можно и нужно ловить ревью, а так же простые логические ошибки. G>>А о чем ты говорил? SK>Я и говорил, что ревью поможет для проверки корректности с сопровождаемости кода. Чтобы в код не попадало типа if ( bIsSomethingNeeded.toString().Length == 4 ) .... SK>А так же неправильное использование операторов new и ошибки типа if (a = 1) ....
Корректность гораздо шире, чем "использование операторов new...". Ты о чем сейчас?
G>>>>оптимизация совершенно другая область, там надо мерить. Поэтому надо для начала посмотреть план, а еще луче прямо на живой системе мониторить missed indexes или что там подобное у оракла. SK>>>Вот и это тоже я имел ввиду. Что ревью не добьешься оптимизации. G>>А кто-то говорил что review помогает оптимизировать? Максимум можно какиенить антипаттерны обнаружить, не более того.
SK>>>Самый лучший способ это комбинирование ревью и тестов, но в некоторых случаях (как в приведенном выше) — ревью практически ничего не даст. Особенно, если не очень разбираешься в предметной области. G>>Не понял на основе чего ты сделал вывод. Тесты тоже не помогают оптимизировать. SK>Тесты помогают найти вот такие неоптимальные места. Это разве не помогает?
Каким образом? Тесты обычно гоняют на тестовом наборе данных, а неоптимальность может проявится только на продуктивной среде.
G>>Ревью дает гораздо больше тестов, есть статистика на этот счет. SK>А статистика, она такая статистика. У меня своя статистика, которая говорит об обратном.
У тебя по десятке проектов максимум, да и то вряд ли ты реальные цифры имеешь, а исследования есть по 18,000 (восемнадцать тысяч) проектов.
SK>Я уже какой раз говорю, что подходы комбинировать надо. Один подход не даст никакой эффективности.
Комбинирование ревью и тестов (если мы говорим о функциональных тестах) не поможет улучшить производительость.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, _ABC_, Вы писали:
SK>5 или 6 условий выборки (в зависимости от) и 3 условия join. Я не много запутался, признаю. Забыл про эти параметры, которые "= 1"
Так немудренно запутаться, когда запрос так написан.
Здравствуйте, SkyKnight, Вы писали:
SK>Это стандартно. Приходит кто-то смотрит пол секунды, объявляет кусок кода говнокодом и начинает это все оптимизировать, при этом не спросив у "долгожителей" конторы "а почему так, а не так?".
Ну ты же реально говнокод привел, даже сам запутался
. И еще дельный совет — если вы используете непонятные стороннему человеку, но рабочие решения, то опишите их в вики, а в коде напишите комментарий с ссылкой.
Здравствуйте, MTD, Вы писали:
MTD>И еще дельный совет — если вы используете непонятные стороннему человеку, но рабочие решения, то опишите их в вики, а в коде напишите комментарий с ссылкой.
Вообще лучше в таких случаях комментарии в коде делать, рядом с непонятным кодом.
