Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
Здравствуйте, 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>Как вы думаете, хорошая ли это стратегия?
Нет. У людей, которые пишут код, должно немного посверливать в одном месте, при мысли о том,
что их код время от времени кто-то читает и, возможно, тихо матерясь сквозь зубы,
пинцетом выдергивает из проекта, как плохо впаянные в электронную плату резисторы.
Тогда будет хоть какой-то стоп-фактор, удерживающий от написания некачественного кода.
А так — очень быстро можно расслабиться. Программисту нужно держать себя в форме.
Некоторые этого не умеют и им нужно помогать.
IO>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
Define "сделанный функционал".
Где я сейчас работаю — сделанный функционал — это полное покрытие тестами, включая странные сценарии. Если находится баг — сценарий добавляется (да, их очень много, но не обязательно гонять все сценарии при активной разработке — но pre-commit script все равно прогонит все, и ничего не должно фейлиться).
Каждый баг файлится со сценарием (в идеальном случае — уже закодированным, жаль, это пока редкость). Первая ступень любого фикса, если сценарий еще не закодирован — закодировать его (общий workflow, упрощенно: open -> existence verified -> test added -> fixed -> verified -> closed).
Таки да, высокотеоретическое "качество кода" не очень отчетливо влияет.
Здравствуйте, SkyDance, Вы писали:
IO>>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
SD>Define "сделанный функционал".
Функционал — это то, что понятно пользователям продукта и из-за чего они им пользуются.
SD>Где я сейчас работаю — сделанный функционал — это полное покрытие тестами, включая странные сценарии.
Это все какие-то странные программистские штучки, а не функционал.
LS>Функционал — это то, что понятно пользователям продукта и из-за чего они им пользуются.
Все верно. Пользователь исполняет себе сценарий "добавить жабу в заказ", и по дороге заодно еще выключает cookies. Жизненно? Вполне. Backend от этого не должен сходить с ума и начинать рассылать угрозы админу сайта. Так? Вот не всегда так. Чтобы было так, нужно сей функционал тестировать.
Вот такие они, "странные программистские штучки". Говорю же, define "функционал".
18.02.2012 21:04, IObserver пишет:
> Как вы думаете, хорошая ли это стратегия?
В общем случае невозможно сказать. В конкретном, ревизии кода нужны с
некоторой периодичностью, по мере его загаживания период же определяется
конкретными задачами, конкретной конторой, конкретным уровнем программистов.
18.02.2012 21:08, LaptevVV пишет:
> Плохая. Ровно об этом — о грязи в коде — пишет дядюшка Боб Мартин в > своей новой книжке "Идеальный программист". > И грязь в коде неизбежно ведет к катастрофе.
В идеальном сферическом вакууме для идеального сферического программиста.
В общем случае ни к какой катастрофе не ведет. И даже наоборот, безумное
вылизывание кода быстрее приведет к катастрофе.
18.02.2012 21:23, Ромашка пишет:
> А толку? Для вдумчивого code review нужно во-первых время, сопоставимое > со временем написания этого же кода, и во-вторых железные нервы, ибо > code review штука весьма конфликтная. Так как человек на проекте один, а > программистов не одна особь, то на полноценный анализ просто нет ресурсов.
Не, толк есть, проверено не раз, вопрос же как часто этим заниматься
определяется в конкретном случае. Для некоторых проектов и задач оно
действительно не нужно.
18.02.2012 21:27, aleks_mur пишет:
> А кто код пишет? Если правильно подобран народ, то за ними вполне > возможно и смысла нет код глядеть — все хорошо. Тем более ревью кода на > уровне чего должен производиться? На уровне функций, классов, чистоты — > тут надо программистов подбирать, иначе в ревью и смысла нет — только > переделывать. На уровне глобальной архитектуры?.. Ну так это должно > как-то организованно\выделено решаться.
Тут уже давно ищут "серебряную пулю" по подбору программистов и их
мотивации без денег и уверен, еще тысячи лет искать будут. Так может
выручишь всех, поделишься этой пулей.
18.02.2012 21:58, Sharowarsheg пишет: > Если у него обязанность в основном сделать, чтобы продукт > продавался, то хорошая стратегия.
Вопрос, как долго продавался?
Здравствуйте, gandjustas, Вы писали:
G>А как долго такая ситуация наблюдается? Ведь если за несколько лет ни разу не выстрелило, значит все ОК. G>Чтобы объяснить нужна явная проблема.
А что должно выстрелить? Здесь разница только, как вы сказали, в суммарных затратах на поддержку. Но этого ведь сразу не заметно, нужно смотреть в перспективе.
18.02.2012 23:25, IObserver пишет:
> Те, у кого максимально быстро получается реализовать требуемый > функционал. При этом код во внимание абсолютно не принимается. К > примеру, один умник написал класс на 50 экранов (который можно и нужно > было разделить на несколько классов) -- отлично. Единственный критерий > -- чтобы функционировало (хотя опять же -- момент довольно скользкий, > т.к. мелкие недоработки как то игнорируются).
Ну тогда он рванет, если понадобиться поддержка проекта более чем на
несколько месяцев. Если же проект растянется в таком виде на долгие годы
— будет катастрофа.
Если же слепил функционал, передал заказчику, он его использовал и через
3 месяца выкинул и забыл, то подход должен именно таким и быть.
19.02.2012 7:08, bastrakov пишет:
> да, по поводу идеального кода. из опыта, все наезды про код были не от > большого ума, а от последней прочитанной книги (хабра, конфы, > ещеченить). и если вдруг вы читали разные книги, то идеальным будет > считаться код начальника. во
Ты просто, наверное, мало кода странного видел. А вот когда такое (а это
бывает ну очень такое) выдает твой подчиненный, а проект должен еще жить
лет 10, то единственный вариант заставлять переделывать.
19.02.2012 8:27, LaptevVV пишет:
> IO>Как вы думаете, хорошая ли это стратегия? > А почему команда сама не проводит ревью перед сдачей этому челу?
Как это? С какого бодуна? Команда не может сама чего-то проводить.
Проведение чего-то в команде должен организовать лидер (начальник или
кто-там неважно).
> А потом и его приглашать, может выскажет полезные замечания.
Если уже организовано полноценное code review (скажем так, круговое), а
это очень дорогое развлечение, то никого приглашать уже не имеет смысла.
Здравствуйте, Vzhyk, Вы писали:
>> Если у него обязанность в основном сделать, чтобы продукт >> продавался, то хорошая стратегия. V>Вопрос, как долго продавался?
Это тоже не указано в задаче. В принципе, может и трех дней хватить, а там хоть трава не расти. Скажем, если продукт — считалка чего-нибудь к чемпионату мира по футболу N+1-го года.
19.02.2012 17:12, IObserver пишет:
> Проверяющий видит и учитывает только текущий момент. О суммарных > затратах пытался заговорить, но он, похоже, подумал что его хотят > "развести на бабки". Как пояснить доходчиво?
Перестать его доставать.
20.02.2012 10:37, IObserver пишет:
> А что должно выстрелить? Здесь разница только, как вы сказали, в > суммарных затратах на поддержку. Но этого ведь сразу не заметно, нужно > смотреть в перспективе.
Просто в какой-то момент поддержка становится невозможной. При правке в
одном месте, все валится в 3 других. Дальше лавина, начальство бегает с
криками "просрали все полимеры", затем принимают решение о полном
переделывании всего написанного и иногда это решение доводит фирму до
банкротства.
Для тебя же главное заранее почувствовать этот момент и поменять контору.
Здравствуйте, IObserver, Вы писали:
IO>Здравствуйте, gandjustas, Вы писали:
G>>А как долго такая ситуация наблюдается? Ведь если за несколько лет ни разу не выстрелило, значит все ОК. G>>Чтобы объяснить нужна явная проблема.
IO>А что должно выстрелить? Здесь разница только, как вы сказали, в суммарных затратах на поддержку. Но этого ведь сразу не заметно, нужно смотреть в перспективе.
"Перспектива" это как горизонт, пытаешься приблизиться к нему, а он удаляется.
Зато есть "ретроспектива". Вот оценить прошедшие проекты и возникшие проблемы можно.
Есть же предварительная оценка задач, посмотреть случаи где предварительная оценка сильно расходится с фактической. Посмотреть причины. Если они в низком качестве кода, то показать тому кто проверяет.
Другой вариант — задачи, которые на виду простые, но в оценке — заоблачные цифры. Если причины как раз в существующем (говно)коде, то тоже показывать "проверящему"
Здравствуйте, SkyDance, Вы писали:
IO>>Есть программисты и чел, проверяющий работу (от которого зависит оплата и пр.). Проверяющий хоть и может читать код, но никогда этого не делает. Учитывается только сделанный функционал, качество кода игнорируется и даже не смотрится.
SD>Define "сделанный функционал". SD>Где я сейчас работаю — сделанный функционал — это полное покрытие тестами, включая странные сценарии. Если находится баг — сценарий добавляется (да, их очень много, но не обязательно гонять все сценарии при активной разработке — но pre-commit script все равно прогонит все, и ничего не должно фейлиться). SD>Каждый баг файлится со сценарием (в идеальном случае — уже закодированным, жаль, это пока редкость). Первая ступень любого фикса, если сценарий еще не закодирован — закодировать его (общий workflow, упрощенно: open -> existence verified -> test added -> fixed -> verified -> closed).
SD>Таки да, высокотеоретическое "качество кода" не очень отчетливо влияет.
Здравствуйте, Vzhyk, Вы писали:
V>Тут уже давно ищут "серебряную пулю" по подбору программистов и их V>мотивации без денег и уверен, еще тысячи лет искать будут. Так может V>выручишь всех, поделишься этой пулей.
У меня ее нет, я про это и не писал. Если у них нормальная команда, то проверять за ними может и не быть смысла — вот я о чем написал
24.02.2012 1:38, aleks_mur пишет:
> У меня ее нет, я про это и не писал. Если у них нормальная команда, то > проверять за ними может и не быть смысла — вот я о чем написал
Любой человек делает ошибки, так и результат работы команды может быть с
ошибками.
24.02.2012 11:46, aleks_mur пишет:
> V>Любой человек делает ошибки, так и результат работы команды может быть с > V>ошибками. > Я про качество кода
То же самое.
И кстати, низкое качество кода порождает больше ошибок и удорожает проект.
