Это в теории. Практика такова, что комментарии тоже надо поддерживать, как и код. Обычно при добавлении костылей и хаков под прессингом времени комментарии не обновляются. Это приводит к том, что комментарии расходятся с кодом.
Кстати написать хороший комментарий сложнее, чем написать хороший код.
Я вот умудряюсь читать разобранные в ILSpy сборки Microsoft SharePoint. Там не то что комментариев, там даже имен переменных нет. Нормально читается, видимо потому что много из этого кода поддерживается уже 10 лет. Нечитаемый код столько просто не прожил бы.
А вот зря не волнует, потому что любой код надо:
1) Написать
2) Протестировать
3) Поддерживать
«Сроки» оценивают только «написать». На «протестировать» чаще всего закладывается процент от «сроки», а на «поддерживать» не закладывается ничего. Вот только поддержка кода — очень дорогой процесс, напрямую он отражается на «сроках» других задач проекта.
Иногда наступает момент, когда любые «сроки» становятся гораздо выше ожидаемых и наступает непрерывный аврал.
Слава богу что многие проекты кончаются раньше.
Качество может увеличить сроки на написание и заметно сократить на тестировании и поддержке. Но об этом часто ни менеджеры, ни программисты не думают.
Теория хаоса вообще о другом. Она говорит изучает детерминированные системы, наблюдаемое поведение которых очень сложно. Разработка кода не является детерминированной системой.
Сюда бы больше подошла термодинамика и закон неубывания энтропии. Но разработка кода не является системой замкнутой.
Теория разбитых окон не о математике и не о физике, она о психологии. Имеет множество подтверждений как прямое действие, так и обратное.
Устраивать периодические чистки — не работает. Я пробовал. Во-первых неизвестно где чистить, не будешь же 10к трок просто так перечитывать в поисках чего бы почистить. Во-вторых это попытка чинить то, что не сломано, это психологически мешает проводить полезные улучшения.
Единственный инструмент повышения качества кода – вы сами. Если вы не стремитесь всегда делать хороший код, то вам не помогут ни тесты, ни инструменты статического анализа. Даже ревью других программистов не поможет.
Работа на метрики не дает гарантий качества кода. Именно поэтому программистов надо бить палками надо обучать писать хороший код и поощрять такое поведение.
Бывают обратные функции справа и слева, соответственно F` и F``, такие что
F(F'(y)) = y и F``(F(x)) = x, если F` = F`` то её просто называют обратной функцией G, для нее x = F(G(x)) = G(F(x))
Хеш функции H делаются как раз так, чтобы не было очевидной функции H`, такой что H(H`(x)) = x.
Для взлома RSA нужно иметь функцию обратную умножению пары простых чисел (F`), причем такую, чтобы F`(F(x,y)) = (x,y).
И такая функция есть, и если докажут что P=NP, то её можно будет считать за полиномиальное время.
Вы тут говорите о другой плоскости. Качество продукта и качество кода хоть и связаны, но не настолько сильно, как кажется.
Качество продукта зависит в первую очередь от восприятия его пользователями. Продукт может решать одну маленькую проблему, при этом не доставлять неудобств, он уже будет хорош. Для того чтобы его сделать не надо пилить 100500 фич в авральном режиме.
Пиление 100500 фич в авральном режиме случается в заказной разработке, когда проект надо сдавать, а ожидания заказчика не согласованы с тем что было сделано, Но и в этом случае нет никакого резона жертвовать качеством. Лучше приоритезировать фичи, сделать 20% самых важных, остальное подвинуть. Окажется что остальное делать и не очень надо.
Я много работал тимлидом в заказной разработке, на моей практике жертвовать качеством — всегда выбор программиста.
Уровень качества кода всегда программисты определяют самостоятельно, если нету формальных ревью. Никакие слова менеджера не помешают им писать так, как хотят. При этом некоторые (например Вы) считают что сделать быстро и грязно выйдет дешевле. Практика показывает что не дешевле.
Код на C#, отлавливал try\catch(Exception), где внутри catch не было throw. API никогда не кидает Exception базового класса.
Любой такой код проглатывает все ошибки независимо от их природы, даже если писать в лог, то непонятно что произошло, ибо контекста очень мало.
Нашел три модуля, в которых плотность таких try\catch превышена. На всех трех было много ошибок (примерно в 2 раза больше) и огромные затраты на тестирование (в 5-6 раз больше), по сравнению с кодом где плотность таких try\catch ниже.
Иногда такой код оправдан, но обычно это не чаще, чем 1 раз на 300 строк.
Я всегда заставлял команду смотреть на код и переделывать после того как заработает. Помогало. В релизе, сделанном в таком режиме, тестер нашел всего одну багу за день.
Но часто срабатывает прессинг сроков, как только код начал давать результат похожий на тот, который нужен, он сразу становится священной коровой. Его нельзя трогать, чтобы, ни дай бог, оно не развалиось.
Если быть математически точным, то корреляция отрицательная.
Если вы разочаровались в метриках, то скорее всего просто не те метрики используете. Я, напрмиер, недавно посчитал плотность try с пустым catch(Exception) в проекте. В хороших проектах получилось около 1 на 200 строк, а в плохих 1 на 20 строк, разница в 10 раз. Естественно эти плохие проекты принесли очень много проблем.
Понятно что одними метриками определить качество кода не выйдет. Поэтому я в посте и про метрики ничего не сказал. Но метрики могут сказать очень много. Особенно если их отслеживать в динамике и коррелировать с состоянием проекта.
WTF/s хороший параметр, но слишком субъективный. И, самое главное, только малая часть программистов способны читать код.
Первый показатель — IRR (Internal Return Rate).
Просто сравнить процент доходности от вложенных денег с тем, что вы бы просто складывали деньги на депозит в банке.
Ваше время — тоже деньги, посчитайте сколько бы вы получили, если бы получали ЗП все это время.
4-7 лет? Вы точно о стартапах?
Чтобы работать надо темой столько времени надо чтобы тепа приносила деньги. Когда 4-7 лет у вас есть доход это уже не стартап.
В C# нет шаблонов, есть Generic. Шаблоны инстанцируются в compile-time и могут, например, реализовать rank-2 полиморфизм.
А F# есть подобная штука, называется compile-time generics, но она работает только в inline функциях, что сильно ограничивает применение.
Кстати написать хороший комментарий сложнее, чем написать хороший код.
Я вот умудряюсь читать разобранные в ILSpy сборки Microsoft SharePoint. Там не то что комментариев, там даже имен переменных нет. Нормально читается, видимо потому что много из этого кода поддерживается уже 10 лет. Нечитаемый код столько просто не прожил бы.
1) Написать
2) Протестировать
3) Поддерживать
«Сроки» оценивают только «написать». На «протестировать» чаще всего закладывается процент от «сроки», а на «поддерживать» не закладывается ничего. Вот только поддержка кода — очень дорогой процесс, напрямую он отражается на «сроках» других задач проекта.
Иногда наступает момент, когда любые «сроки» становятся гораздо выше ожидаемых и наступает непрерывный аврал.
Слава богу что многие проекты кончаются раньше.
Качество может увеличить сроки на написание и заметно сократить на тестировании и поддержке. Но об этом часто ни менеджеры, ни программисты не думают.
Сюда бы больше подошла термодинамика и закон неубывания энтропии. Но разработка кода не является системой замкнутой.
Теория разбитых окон не о математике и не о физике, она о психологии. Имеет множество подтверждений как прямое действие, так и обратное.
Устраивать периодические чистки — не работает. Я пробовал. Во-первых неизвестно где чистить, не будешь же 10к трок просто так перечитывать в поисках чего бы почистить. Во-вторых это попытка чинить то, что не сломано, это психологически мешает проводить полезные улучшения.
Работа на метрики не дает гарантий качества кода. Именно поэтому программистов
надо бить палкаминадо обучать писать хороший код и поощрять такое поведение.F(F'(y)) = y и F``(F(x)) = x, если F` = F`` то её просто называют обратной функцией G, для нее x = F(G(x)) = G(F(x))
Хеш функции H делаются как раз так, чтобы не было очевидной функции H`, такой что H(H`(x)) = x.
Для взлома RSA нужно иметь функцию обратную умножению пары простых чисел (F`), причем такую, чтобы F`(F(x,y)) = (x,y).
И такая функция есть, и если докажут что P=NP, то её можно будет считать за полиномиальное время.
Качество продукта зависит в первую очередь от восприятия его пользователями. Продукт может решать одну маленькую проблему, при этом не доставлять неудобств, он уже будет хорош. Для того чтобы его сделать не надо пилить 100500 фич в авральном режиме.
Пиление 100500 фич в авральном режиме случается в заказной разработке, когда проект надо сдавать, а ожидания заказчика не согласованы с тем что было сделано, Но и в этом случае нет никакого резона жертвовать качеством. Лучше приоритезировать фичи, сделать 20% самых важных, остальное подвинуть. Окажется что остальное делать и не очень надо.
Я много работал тимлидом в заказной разработке, на моей практике жертвовать качеством — всегда выбор программиста.
Любой такой код проглатывает все ошибки независимо от их природы, даже если писать в лог, то непонятно что произошло, ибо контекста очень мало.
Нашел три модуля, в которых плотность таких try\catch превышена. На всех трех было много ошибок (примерно в 2 раза больше) и огромные затраты на тестирование (в 5-6 раз больше), по сравнению с кодом где плотность таких try\catch ниже.
Иногда такой код оправдан, но обычно это не чаще, чем 1 раз на 300 строк.
Но часто срабатывает прессинг сроков, как только код начал давать результат похожий на тот, который нужен, он сразу становится священной коровой. Его нельзя трогать, чтобы, ни дай бог, оно не развалиось.
Если вы разочаровались в метриках, то скорее всего просто не те метрики используете. Я, напрмиер, недавно посчитал плотность try с пустым catch(Exception) в проекте. В хороших проектах получилось около 1 на 200 строк, а в плохих 1 на 20 строк, разница в 10 раз. Естественно эти плохие проекты принесли очень много проблем.
Понятно что одними метриками определить качество кода не выйдет. Поэтому я в посте и про метрики ничего не сказал. Но метрики могут сказать очень много. Особенно если их отслеживать в динамике и коррелировать с состоянием проекта.
WTF/s хороший параметр, но слишком субъективный. И, самое главное, только малая часть программистов способны читать код.
Так вот эти показатели очень сильно коррелируют с одной стороны с читаемостью, с другой стороны с багами. Я это на десятке проектов проверял.
Просто сравнить процент доходности от вложенных денег с тем, что вы бы просто складывали деньги на депозит в банке.
Ваше время — тоже деньги, посчитайте сколько бы вы получили, если бы получали ЗП все это время.
Чтобы работать надо темой столько времени надо чтобы тепа приносила деньги. Когда 4-7 лет у вас есть доход это уже не стартап.
А F# есть подобная штука, называется compile-time generics, но она работает только в inline функциях, что сильно ограничивает применение.