Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
IO>Как вы думаете, хорошая ли это стратегия?
Плохая. Ровно об этом — о грязи в коде — пишет дядюшка Боб Мартин в своей новой книжке "Идеальный программист".
И грязь в коде неизбежно ведет к катастрофе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
18.02.2012 20:04, Здравствуйте, IObserver : > Есть программисты и чел, проверяющий работу (от которого зависит оплата > и пр.). Проверяющий хоть и может читать код, но никогда этого не делает.
А толку? Для вдумчивого code review нужно во-первых время, сопоставимое
со временем написания этого же кода, и во-вторых железные нервы, ибо
code review штука весьма конфликтная. Так как человек на проекте один, а
программистов не одна особь, то на полноценный анализ просто нет ресурсов.
> Учитывается только сделанный функционал, качество кода игнорируется и > даже не смотрится.
Плюс время на проверку функционала, наклепанного командой программеров.
Плюс отчитаться перед начальством/инвесторами. Плюс выплатить
программерам бабло. Я боюсь, на большее у человека просто нет времени и
сил.
> Как вы думаете, хорошая ли это стратегия?
А хз. Для пилотного проекта или быстрого стартапа вполне себе правильная
стратегия.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится. IO>Как вы думаете, хорошая ли это стратегия?
А кто код пишет? Если правильно подобран народ, то за ними вполне возможно и смысла нет код глядеть — все хорошо. Тем более ревью кода на уровне чего должен производиться? На уровне функций, классов, чистоты — тут надо программистов подбирать, иначе в ревью и смысла нет — только переделывать. На уровне глобальной архитектуры?.. Ну так это должно как-то организованно\выделено решаться.
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
IO>Как вы думаете, хорошая ли это стратегия?
Если у него есть обязанность проверять код, то он не выполняет свои обязанности. Если у него обязанность в основном сделать, чтобы продукт продавался, то хорошая стратегия.
Здравствуйте, LaptevVV, Вы писали:
IO>>Как вы думаете, хорошая ли это стратегия? LVV>Плохая. Ровно об этом — о грязи в коде — пишет дядюшка Боб Мартин в своей новой книжке "Идеальный программист".
Что за "Идеальный программист"? Clean Coder, что ли?
У меня на прошлой работе один кодер ревьювил команду из 8 человек с ммм... не очень поставленным ситилем кодирования. И код был охерителен, лучше чем обычно я сам пишу (а я элито, ебенамать, интеллигент, без пяти минут еврей и практически хаскеллист соль земли). Потом человек ушеу и проект меньше чем за месяц скатился в сраное говно. Так что ищите лидов, они могут поставить процесс ревью.
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится. IO>Как вы думаете, хорошая ли это стратегия?
Я честно не помню автора, но цитата выглядела примерно так:
"Плохое качество кода похоже на бомбу с неисправным взрывателем.
Может не взорваться никогда. А может взорваться и через секунду"
Во всех случаях их моей практики обычно "взрывалось" рано или поздно и последствия были соответствующие.
Поэтому я всегда сторонник качества. Но это субьективно конечно.
Противоположное мнение вполне достойно существования и как мне кажется живет себе припеваючи и возможно даже своим существованием повышая мою зарплату год от года. Дай им Бог здоровья
Здравствуйте, aleks_mur, Вы писали:
_>А кто код пишет?
Те, у кого максимально быстро получается реализовать требуемый функционал. При этом код во внимание абсолютно не принимается. К примеру, один умник написал класс на 50 экранов (который можно и нужно было разделить на несколько классов) -- отлично. Единственный критерий -- чтобы функционировало (хотя опять же -- момент довольно скользкий, т.к. мелкие недоработки как то игнорируются).
Получается что те, кто уделяет внимание коду -- долго не задерживаются. Ведь качественный код не сразу приносит пользу, а по достижению определенной сложности.
_>Если правильно подобран народ, то за ними вполне возможно и смысла нет код глядеть — все хорошо.
Именно по этому критерию народ и подбирается.
_>Тем более ревью кода на уровне чего должен производиться? На уровне функций, классов, чистоты — тут надо программистов подбирать, иначе в ревью и смысла нет — только переделывать. На уровне глобальной архитектуры?.. Ну так это должно как-то организованно\выделено решаться.
Ни то ни то значения не имеет никакого
P.S.
Контору называть не буду, интересно обсудить абстрактно. Может я чего не понимаю.
Здравствуйте, Ромашка, Вы писали:
Р>А толку? Для вдумчивого code review нужно во-первых время, сопоставимое Р>со временем написания этого же кода, и во-вторых железные нервы, ибо Р>code review штука весьма конфликтная. Так как человек на проекте один, а Р>программистов не одна особь, то на полноценный анализ просто нет ресурсов.
Вы все правильно описали -- именно такая причина называется.
Здравствуйте, LaptevVV, Вы писали:
LVV>И грязь в коде неизбежно ведет к катастрофе.
гм.. при плохой архитектуре, любой самый идеальный код не спасет проект.
а при хорошей архитектуре, любой неэффективный код, даже если он найден в пост-продакшне, может быть пофикшен быстро и просто.
поэтому присоединюсь к мнению выше. ищите хороших лидов, они просто не заведут в ситуацию, когда один плохой девелопер валит весь проект.
да, по поводу идеального кода. из опыта, все наезды про код были не от большого ума, а от последней прочитанной книги (хабра, конфы, ещеченить). и если вдруг вы читали разные книги, то идеальным будет считаться код начальника. во
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
IO>Как вы думаете, хорошая ли это стратегия?
А почему команда сама не проводит ревью перед сдачей этому челу?
А потом и его приглашать, может выскажет полезные замечания.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
IO>Как вы думаете, хорошая ли это стратегия?
Зависит от целей проверяющего. Если проверяющий стремится сократить суммарные затраты на разработку, то он будет заинтересован в качестве кода и дизайна. А если ему нужно сдать готовый функционал в срок, то качество ему нафиг не упало.
Здравствуйте, gandjustas, Вы писали:
G>Зависит от целей проверяющего. Если проверяющий стремится сократить суммарные затраты на разработку, то он будет заинтересован в качестве кода и дизайна. А если ему нужно сдать готовый функционал в срок, то качество ему нафиг не упало.
Проверяющий видит и учитывает только текущий момент. О суммарных затратах пытался заговорить, но он, похоже, подумал что его хотят "развести на бабки". Как пояснить доходчиво?
Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, LaptevVV, Вы писали:
LVV>>И грязь в коде неизбежно ведет к катастрофе.
B>гм.. при плохой архитектуре, любой самый идеальный код не спасет проект. B>а при хорошей архитектуре, любой неэффективный код, даже если он найден в пост-продакшне, может быть пофикшен быстро и просто.
B>поэтому присоединюсь к мнению выше. ищите хороших лидов, они просто не заведут в ситуацию, когда один плохой девелопер валит весь проект.
Для этого достаточно архитектуры "Разделяй и властвуй" никаких выдающихся знаний не требуется, алсо требуется чуствовать баланс чтобы не наплодить ненужных абстракций которые сделают крах по перформансу и оптимальном использовании ресурсов.
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
IO>Как вы думаете, хорошая ли это стратегия?
Я иду до метро пешком, а мог бы ехать на трамвае. Как вы думаете это хорошая стратегия?
Здравствуйте, IObserver, Вы писали:
G>>Зависит от целей проверяющего. Если проверяющий стремится сократить суммарные затраты на разработку, то он будет заинтересован в качестве кода и дизайна. А если ему нужно сдать готовый функционал в срок, то качество ему нафиг не упало.
IO>Проверяющий видит и учитывает только текущий момент. О суммарных затратах пытался заговорить, но он, похоже, подумал что его хотят "развести на бабки". Как пояснить доходчиво?
Сначала подумай, как бы убедиться точно, что ты прав, а он нет.
Здравствуйте, IObserver, Вы писали:
IO>Здравствуйте, gandjustas, Вы писали:
G>>Зависит от целей проверяющего. Если проверяющий стремится сократить суммарные затраты на разработку, то он будет заинтересован в качестве кода и дизайна. А если ему нужно сдать готовый функционал в срок, то качество ему нафиг не упало.
IO>Проверяющий видит и учитывает только текущий момент. О суммарных затратах пытался заговорить, но он, похоже, подумал что его хотят "развести на бабки". Как пояснить доходчиво?
А как долго такая ситуация наблюдается? Ведь если за несколько лет ни разу не выстрелило, значит все ОК.
Здравствуйте, IObserver, Вы писали:
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
IO>Как вы думаете, хорошая ли это стратегия?
Нет. У людей, которые пишут код, должно немного посверливать в одном месте, при мысли о том,
что их код время от времени кто-то читает и, возможно, тихо матерясь сквозь зубы,
пинцетом выдергивает из проекта, как плохо впаянные в электронную плату резисторы.
Тогда будет хоть какой-то стоп-фактор, удерживающий от написания некачественного кода.
А так — очень быстро можно расслабиться. Программисту нужно держать себя в форме.
Некоторые этого не умеют и им нужно помогать.
