LVV>Кто может привести примеры прекрасного качества кода?
Прекрасный код это код, который пишу я в текущий момент, все остальное — отстой, включая мой код, который я писал вчера .

Здравствуйте, IT, Вы писали:

LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
IT>Для начала хорошо бы определить критерии хорошего качественного кода.

1. Единообразие подходов
2. Сложность вхождения не выше сложности задачи
3. Отсутствие ненужной избыточности

Или так: код, который не совершает следующих грехов:

Гордыня — код понятен даже джуниору (если он понял задачу)
Зависть — код не дублирует уже существующий код
Чревоугодие — код не пожирает все возможные ресурсы себе в угоду
Блуд — код не содержит бессмысленных конструкций просто ради кода
Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать
Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль
Уныние — код написан не на выброс

Здравствуйте, LaptevVV, Вы писали:

LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Я могу. Рассказать. Не показать.
Несколько лет был на поддержке кода пользовательского интерфейса моторольских телефонов. Когда только вообще впервые увидел моторольский код, ужаснулся, но не от качества (что я понимал тогда в этом), а от его объёма — и понял, какой же фигнёй занимался до этого. И только ленивый не ругался на его качество. То ли под воздействием таких разговоров, то ли в силу возрастающего профессионализма я стал считать, что могу писать код лучше. Ещё некоторое время спустя я увидел (стал различать), что это не то чтобы плохое качество кода, а заплатка тут, заплатка там, и местами вообще заплата на заплате. Но такова была политика (процесс разработки) Моторолы. На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.

Здравствуйте, LaptevVV, Вы писали:

LVV>Я довольно давно на РСДН.
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
LVV>Как правило, посты следующего содержания:
LVV>

LVV>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.

На всякий, шоб ссылаться, признаки проблемного кода

1. Кривой дизайн/микродизайн (непонятное, много мест для изменения, много сущностей и тд)
2. Дублирование (в любом виде: от строчек, функций, классов до параллельных механизков вроде трёх версий контроллера ) ACHTUNG !
3. Простыни (длинные файлы/классы/функции/конфиги/имена/цепочки и тд)
4. Высокая вложенность конструкций
а Несколько классов в одном рукописном файле
б уровень вложенности блоков >= 3 ACHTUNG !
в вложенные конструкции вроде сложных запросов linq(на пол-экрана и более)
г несколько операторов в одной строке или одной конструкции, например условие цикла из десятка логический условий

И разные эвристики ACHTUNG !

1. Количество ревизий у файла превышает все разумные границы ACHTUNG !
2. Появления кучки странных багов после небольшого фикса ("добавил картинку — пропал грид")
3. Комментарии в файле (sic!)
4. Велосипеды. Например самопальное кеширование без грамотных юнит-тестов == рассадник багов.
5. Глотание исключений
6. Десятки сборок по пять классов на каждую
7. разделение проекта на несколько солюшнов
8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка
9. мануал или т.н. курс молоджого бойца для работы с проектом

Здравствуйте, LaptevVV, Вы писали:

LVV>Кто может привести примеры прекрасного качества кода?

Можно-с. Только код привести не получится. Во многих случаях большой он для rsdn-на. Почему? А потому что он не из книжек, а из жизни.

Было дело, один коллега написал преобразование текста из одного формата в другой на XSLT. Я ему сразу сказал, что он сошел с ума. Но этот код просуществовал долго, пока мне с ним не пришлось работать. Тогда он был переписан за один день на перле. Самое смешное, что xslt код был достаточно длинный. Но код на перле получился короткий, буквально в 1.5 экрана. Поэтому я просто послал этот код коллеге в назидание по почте (а остальных добавил в CC, чтобы они прикололись).

Было дело, один коллега недопонял модель MVC и написал код на C++, где между model, view и controller передавались сообщения через тип VARIANT (запаковывались в VARIANT, а потом распаковывались из VARIANT в огромных switch-ах, — да, коллега был немного долбанутым, извените за выражение). Другие коллеги как-то мирились с этим кодом и, вроде, даже не жаловались. Только продуктивность почему-то была небольшая. И я понял почему, когда мне пришлось добавить пару сообщений в этот код. Я буквально на каждое сообщение тратил дня два (сначала куча нетривиального кода, а потом мучительная отладка). Мне хотелось обложить коллегу матом, но к сожалению, он бы не оценил, так как он не умел говорить по-русски. Пришлось потратить еще два дня, выкинуть весь его код и переписать его на@#$. Он после этого все-таки сказал мне спасибо, и я подумал, ладно живи, bastard.

Я заметил, что не многие могут увидет, а тем более оценить по достоинству красивый код. Причина в том, что для начала нужно научиться видеть плохой код. У тебя должно быть чувство постоянного неудовлетворения существующим кодом. Когда в процессе рефакторинга, ты сводишь это чувство к минимуму, то можно сказать, что код начинает становиться красивым.

Здравствуйте, LaptevVV, Вы писали:

LVV>Кто может привести примеры прекрасного качества кода?
курим ГОСТ 28195–99. кстати, международный. а еще есть гост на качество колбасы. все гостировано.

LVV>Из жизни, а не из книжек.
без книжек не получится. без книжек все слишком субъективно. свой код я считаю отстойным, но у коллег он нареканий не вызывает. вот и определи -- говно это или мармелад в шоколаде.

кстати, учиться по книжкам и чужому коду -- плохая идея ИМХО. у меня код нашпигован глобальными переменными, но от этого он только выигрывает, т.к. глобальные переменные используются так, что решают больше проблем, чем создают и любое другое решение (из числа известных) устраняя проблемы, свойственные глобальным переменным, привносит другие.

это я к тому, что руководство "не используйте глобальные переменные" нужно понимать с умом, т.е. пока вы не совсем понимаете, что именно вы делаете и как оно работает, то, действительно, от глобальных переменных лучше воздержаться. но... если бы дети слушались родителей, то так бы и ходили в шкурах. так что эксперементировать, нарушая запреты, все-таки полезно. ходи против правил и смотри, что из этого получается.

в этом смысле разглядывание исходников "качественного" кода только вредит. типа, ага! тут и глобальные переменные и даже goto есть!!!

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, LaptevVV, Вы писали:

LVV>>Я довольно давно на РСДН.
LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
LVV>>Как правило, посты следующего содержания:
LVV>>

LVV>>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.

LVV>>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...

I>Очень мало контор уделяет внимание качеству кода.
А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д. Если качество кода ставится во главу угла, то во-первых, получается процесс ради процесса, а во-вторых, если на входе и есть что-то, то оно настолько сделано через задницу, что использовать его всем кроме автора (или небольшой групп ы авторов) соверешенно невозможно, причем модификацию и поддержку тоже необходимо осуществлять исключительно через задницу.

Здравствуйте, Dym On, Вы писали:

Vi2>>Прекрасный код — это код, который ты напишешь завтра.
DO>Завтра я напишу совершенный код .
Его уже написал Макконнелл.

Здравствуйте, neFormal, Вы писали:

I>>Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?

F>справа их описание..
F>лично для тебя:
F>Гордыня — не усложнять без надобности
F>Зависть — не дублировать существующий код/функционал
F>Чревоугодие — следить за расходом ресурсов
F>Блуд — не словоблудствовать, писать достаточно кратко
F>Гнев — думать о том, кто это будет использовать/поддерживать, а не ненавидеть его заранее
F>Алчность — не тащить весь доступный функционал в каждый(или единственный) модуль, сокращать зависимости
F>Уныние — не писать на выброс

Мнэээ... то есть надо не совершать ни один из этих грехов, а именно:
* усложнять без надобности
* дублировать код и функционал
* игнорировать траты ресурсов
* писать развесисто и бессмысленно
* игнорировать, ненавидеть и презирать пользователя
* развешивать зависимости
* писать так, чтобы нельзя было развивать

Я правильно понял?

Или всё-таки надо совершать все эти грехи?

Здравствуйте, Testator, Вы писали:

T>А что тут особенного? Сишный код, написанный четко по документации. Выдает на выходе ровно то что должно выходить. Баги есть в основном логические, те что выше. А формальную правильность можно даже доказать если сильно нужно. Теория неподвижной точки тут применима, но очень объемное доказательство выйдет Вы в курсе про эту возможность, или снова дважды два не четыре?

Можно вопрос? Спасибо! Если у вас всё так формально определено ещё до написания кода, то зачем вам вообще программисты? Мы в таких случаях просто тупо генерируем код и всё. Про метапрограммирование слышал? Вот как раз оно очень хорошо заменяет обезъянок. Рекомендую.

Здравствуйте, Testator, Вы писали:

IT>>Да ладно! Количество багов, уходящих в продакшин у вас тоже формализовано?

T>У нас баги в основном лезут из-за недокументированных особенностей сторонних компонент. В ядре Windows их не перечесть

Как меряли ? Разбор полетов проводили ? Как тестировали ? Регрессионные тесты были ?

IT>>Видимо ты чего-то не договариваешь, скрываешь от нас где-то серебряную пульку.

T>Так а откуда баги то берутся? Не дизайновые, а именно тупые ошибки кодирования.

Тупые ошибки кодирования берутся по разным причинам, если считать, что все одинаково подготовлены (что уже нонсенс), то основных причин 2 — зевки и потеря контроля над кодом.

>Элементарные правила как раз и нужны чтобы уменьшить вероятность их появления. То что облась эта хорошо формализуемая, надеюсь нет сомнений?

Нет здесь формализации толком. Есть разные метрики, но толку мало. У каждого правила вроде "не надо дублировать" есть правило прямо противоположное — "сжатие кода затрудняет чтение и поднимает входной порог". То есть, нужны не просто метрики, а еще целую функцию, которая будет баланс учитывать .

>Умные компиляторы выдают варнинги на любой чих, есть отдельные анализаторы для разных языков и платформ. Все в конечном итоге упирается в человеческий фактор, аккуратность в соблюдении набора известных правил. Т.е. если все написано так что баг там невозможен, то его и не будет

Если ты можешь вывести формулу, почему же баг невозможен, то это и есть формула качества. Реально ты не знаешь и не можешь знать, где потеряешь контроль над кодом. Грубо говоря, если в моент t ты на 100% контролируешь N строк кода, то это ничего не значит, т.к. нет механизма который скажет тебе что строка N+1 уже выходит из под контроля
Психика так устроена, что бессознательное выполняет бОльшую часть работы(на порядок-два больше чем сознание), но при этом оно не уведомляет, какую именно часть работы оно выполнило и ты даже не знаешь всех результатов деятельности этого бессознательного, более того, в принципе не можешь контролировать бессознательное.
Второй момент это сложность софта — взаимосвязи между компонентами, функциями, модулями в софте имеют мягко говоря нелинейный характер. Все модули явно и неявно влияют на все, как минимум через кеш команд, кеш данных, системную шину или конроллер ввода-вывода.

T>Просвети же наконец, что ты то понимаешь под _качеством кода_?

Нет никакой ложки Есть вариант вроде тех, что используется в интеллектуальных играх — за отсутствием эталона вроде игрока-бога берется мнение адского эксперта в своей области.

Дело в том, что качетсво кода по своей сути привязано к особенностям человеческой психики. Предположим существует идеальный программист God-Dev который может любую фичу с любым количеством ограничений любой сложности заимплементить за 0 (нуль) времени.

На кой ляд этому God-Dev какое то качество кода ? Все композиции-декомпозиции нужны человеку, потому что у человеческих мышления/памяти/внимания/восприятия человека есть объективные ограничения.

Здравствуйте, LaptevVV, Вы писали:

LVV>Я довольно давно на РСДН.
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

Был один

Автор: Privalov
Дата: 14.04.05

, по крайней мере.

LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Давно было, код не сохранился. Но представь себе код на древнем Basic, где нет ни одной строчки спагетти. Я к тому проекту на заключительных этапах присоединился, и в одиночку пару лет потом поддерживал.

Здравствуйте, Mystic, Вы писали:

I>>Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.
M>А потом просят добавить новые фичи, но только в одну из веток. В результате возникают флажки, виртуальные функции, а конце скрещивание ежа и ужа.

Есть пять способов борьбы

1. Сделай код чище чем был до тебя. Вынесешь ветку в отдельную функцию — это вполне достаточно для начала.

2. Правило трёх раз (бог любит троицу) — меняешь код первый раз, смотришь сколько сил-времени уходит и какой результат. Меняешь код второй раз — смотришь что можно улучшить. Меняешь код в третий раз — обязательно делай его лучше.

3. Правило четырёх (без четырях углов изба не стоит)- меняешь код первый раз, меряешь профит. Меняешь код второй раз — смотришь что можно улучшить. Меняешь код в третий раз — исправляешь дизайн, дублирование нахрен, т.е. тотально, после чего делаешь откат. Меняешь код в четвертый раз и обязательно улучшаешь его.

4. Закон сохранения энергии — что бы ускорить(== удешевить) проект, нужно отдать ему часть своей энергии, которую направить на а. облегчение б. ускорение (фича != ускорение)

5. Эволюция — что бы сделать чтото хорошо, надо сначала сделать это плохо а потом обязательно улучшать

Выбирай любой. Оставлять говнокод тоже вариант, надо только набраться храбрости и сказать себе : "Дырка в заднице является оправданием для говнокода".

LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Не знаю насчет прекрасности, но

Например есть такая схема HTTP: http://webmachine.basho.com/diagram.html
И вот, как с ней работает webmachine: https://github.com/basho/webmachine/blob/master/src/webmachine_decision_core.erl

Обращаю внимание:

%% "Service Available"
decision(v3b13) ->

%% "Known method?"
decision(v3b12) ->

%% "URI too long?"
decision(v3b11) ->

И т.п. v3 — это версия схемы. b13, b12 и т.п. — соответствующее место на схеме. В итоге код получается достаточно поянтынм и документированым.

Здравствуйте, LaptevVV, Вы писали:

LVV>Я довольно давно на РСДН.
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

Русский программист уже давно (как минимум среди своих) стало нарицательным =)

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, ry, Вы писали:

ry>>Несколько лет был на поддержке кода пользовательского интерфейса моторольских телефонов. Когда только вообще впервые увидел моторольский код, ужаснулся, но не от качества (что я понимал тогда в этом), а от его объёма — и понял, какой же фигнёй занимался до этого. И только ленивый не ругался на его качество. То ли под воздействием таких разговоров, то ли в силу возрастающего профессионализма я стал считать, что могу писать код лучше. Ещё некоторое время спустя я увидел (стал различать), что это не то чтобы плохое качество кода, а заплатка тут, заплатка там, и местами вообще заплата на заплате. Но такова была политика (процесс разработки) Моторолы. На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.

I>Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
I>Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда
Ты не прав, P2K платформа была одна из самых качественных и гибких у мотороллы (посмотри сколько телефонов на ней было сделано). Единственный минус, она устарела. С юзабилити у моторов было всё хорошо, всегда всё под рукой и легко найти, в отличии от нокии к примеру.

Здравствуйте, ry, Вы писали:

I>>Конечно. Только задача, сроки и качество диктуются проектом. Если это не "накидал-отдал-забыл", то сам понимаешь, что качество кода играет роль.
ry>Конечно, играет, но, повторюсь, потом. Я и был нанят в тот стартап из-за плохого качества кода, созданного студентами, но свою роль (огромную и положительную) тот код сыграл.

Ты пойми простую вещи, качество кода и цели проекта это разные вещи и не нужно смешивать эти понятия.

У (не)качественного кода вполне характерные признаки и цели проекта здесь ни при чем.

Если у тебя в целях проекта быстрый выпуск версии и ты решил пожертвовать качетсвом, то пожалуйста, сколько угодно. Но это не сделает код качественным А из твоего определения следует ровно обратное.

Разделение этих двух понятий даёт полезное свойство — качество кода может соответсвтвовать целям проекта, а может и не соответствовать. То есть появляется дополнительная точка контроля — девелоперу можно внятно объяснить, что не так с его кодом.

И если вдруг тебе придется искать аналогии, то далеко ходить не надо — стерильный инструмент используется в хирургической, а вот на кухне или в столовой добиваться хирургической чистоты это безумие.

LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Исходники StyleCop неплохо выглядят — http://stylecop.codeplex.com/SourceControl/list/changesets

Здравствуйте, мыщъх, Вы писали:

8>>а завтра придет вася пупкин за место тебя, и такое нафигачит с твоими глобальными переменными.
М>давайте исходить из того, что не придет, ибо такими аргументами можно уничтожить кого угодно

не, давайте исходить из того что придет, потому что он придет, рано или поздно.

Здравствуйте, LaptevVV, Вы писали:

LVV>Я довольно давно на РСДН.
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
LVV>Как правило, посты следующего содержания:
LVV>

LVV>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.

LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы... :)

А зачем рассказывать про хороший код?
Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует.

LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Я могу их из своей практики привести хоть тысячу, но не вижу смысла. Во-первых, что это прекрасный код — то есть выполняет ровно свою задачу, чёток, понятен и пригоден к развитию — пойму только я и коллеги, остальные в лучшем случае пожмут плечами. Во-вторых, он соседствует в одном и том же проекте с кошмарами, которые нельзя выбросить только потому, что они доведены до достаточно рабочего состояния. В-третьих, такой код часто требовал больше усилий, чем надо бы (есть у меня в подчинённых, например, перфекционист, который никогда не может выдержать сроки).

Так что я (повторюсь) устроил бы тут голосование. Дать пяток уровней качества — от кошмара до идеала — и вопрос типа "то с чем вы работаете сейчас — к чему ближе?"

Здравствуйте, Vlad_SP, Вы писали:

I>>Очень мало контор уделяет внимание качеству кода.

V_S>И это правильно. Клиент платит за продукт, решающий его проблемы, а не за мифическое "качество кода". Поэтому качество кода и находится на соответствующем месте в иерархии ценностей компании... что тут удивительного?

Клиент как правило не в курсе, что качество кода может быть разным или, как минимум, не понимает насколько это важно.

V_S>Есть, безусловно, некоторое количество компаний, которые продают исходники. Вот тут "качеству кода" уделяется внимание, — ну, так этот код и есть их продаваемый продукт. Нет?

Нет. Стоимость последующих изменений напрямую зависит от качетсва кода. Я занимался несколькими длинными проектами, которые пришлось буквально воскрешать.
Все такие проекты останавливаются в основном из за того, что стоимость изменений становится слишком высокой.
Выход один — вложить кучу денег и начать новый проект или вложить кучу денег и воскресить.
Качество кода позволяет увеличить цикл жизни кода — внимание — в разы за счет снижения стоимости разработки.

Теперь вопрос — является ли стоимость изменения критичной для клиента который платит за продукт решающий его проблемы ?

Здравствуйте, Kernan, Вы писали:

I>>Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
I>>Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда
K>Ты не прав, P2K платформа была одна из самых качественных и гибких у мотороллы (посмотри сколько телефонов на ней было сделано). Единственный минус, она устарела. С юзабилити у моторов было всё хорошо, всегда всё под рукой и легко найти, в отличии от нокии к примеру.

Я често не понимаю, где ты углядел юзабилити у моторов. Что за модель с P2K ? Может я такую знаю.

Здравствуйте, ry, Вы писали:

I>>Проблемы менеджемента как раз проявляются тотально, в т.ч. и в коде. Если менеджменту насравть на код это ровно тоже самое, что заинтересованность в говнокоде. Есть такое являение: "Пока будут баги, у меня будет работа" Это пораженческие настроение и от такого руководителя/команды надо бежать без оглядки.

ry>Я плохо выразился. Под "проблемы менеджмента" имел в виду продуктовый менеджмент, не кода. У всякого продукта есть срок жизни, и всему наступает конец. Будь то программа, дом, дерево, сын или телефон. Телефон — это аппаратно-программный комплекс. И уж коли платформе пришёл кирдык, то сколько и как ни старайся продлить ей жизнь, лучше её вовремя прибить самому, а Моторола протянула с этим.

I>>И то и другое проявляется в т.ч. в виде говнокода, а у говнкода основной эффект — окончание цикла жизни кода. Повторяю — основной !
ry>Не согласен. Конечно, код может укорачивать жизненный цикл, но, думается, главным ограничителем жизни является востребованность продукта рынком. А говнокод просто может сыграть злую шутку с его автором при наличии конкурентного продукта (а может и не сыграть).

Говнокод всегда удорожает разработку. Всегда. И всегда это становится причиной окончания цикла жизни кода. Ты можешь хотеть юзать платформу год-два три, но денег больше нет
Дорогая разработка софта — значит на разработку железа денег будет меньше. Все очень просто.

I>1. Количество ревизий у файла превышает все разумные границы ACHTUNG !

В случае, если идем от прототипа к работающему коду, да еще с git'ом, то окличество ревизий ожет быть большое

Здравствуйте, ry, Вы писали:

I>>Дорогая разработка софта — значит на разработку железа денег будет меньше. Все очень просто.

ry>Нет, не всё просто.
ry>В начале разработки удешевляет. Всегда. Наверно . А дальше — как кривая вывезет.
ry>На прототипах — всегда дешевле.

Прототип это не продакшн. Пока тебе не надо менять готовый код или можно быстро менять готовые куски кода, говнокод рулит. За эту скорость придется заплатить — девелопер перестаёт развиваться, т.к. все эффективные решения обычно требуют многих переделок прежде, чем появится чтото более менее толковое.

ry>На продуктах, предназначенных для внутреннего использования, — в основном дешевле.

Дешевле там, где можно допиливать фичи сбоку. Как только надо влазить и править уже готовый код, всё, туши свет — ни качества, ни сроков невозможно гарантировать.

Если кода еще мало, то есть шанс один говнокод заменить быстро другим говнокодом. Со временем и этот резерв исчерпывается.

ry>На разовых продуктах (например, тесты) — всегда дешевле.

Тест и разовые продукты это разные вещи Говнокод в тестах вносит хаос еще почище говнокода в продукте.

Здравствуйте, IT, Вы писали:

LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

IT>Для начала хорошо бы определить критерии хорошего качественного кода.

Качественным кодом является код, полностью удовлетворяющий ТЗ и внутренним документам (например, внутрифирменному стандарту кодирования) подрядчика/заказчика.
Пойдёт?

Здравствуйте, ry, Вы писали:

ry>А теперь представь себя владельцем стартапа. Ты заинтересовал инвестора, и он дал тебе денег на разработку. И почти никогда он не даст тебе денег столько, чтобы ты шиковал — возможно, сам ты лично вообще будешь сидеть без денег. Представил? Теперь ответь, только честно, куда ты пошлёшь девелопера с его требованиями/желаниями развиваться.

Если стартап это не "накидал-отдал-забыл" то никуда посылать не надо.

>Ты будешь экономить на всём, в частности на качестве кода,

Ни в коем случае. Говнокод _замедляет_ и _удорожает_.

>лишь бы добиться поставленной цели. Так является ли "говнокод" говнокодом? Да, возможно, потом он будет тормозить разработку, да, возможно, потом ты что-то не дополучишь, но — потом, к тому же не факт. Так что, не всё то — говно, что воняет

Из за таких рассуждений многие проекты ко второй-третьей версии уходят со сцены имея неплохой функционал, просто потому что не могут развиваться.

Здравствуйте, blackhearted, Вы писали:

I>>7. разделение проекта на несколько солюшнов
I>>8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка

B>после этих пунктов возникают серьёзные сомнения, что кроме лабы в институте автор этих строк написал хоть что-то.

Скажи честно, ты где то увидел у меня нечто вроде "разделение проекта на несколько солюшнов есть необходимый и достаточное условие говнокода" ?

Твой скептицизм выдаёт с головой неумение решать задачи диагностики.

Здравствуйте, IT, Вы писали:

LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

IT>Для начала хорошо бы определить критерии хорошего качественного кода.

Это КСВ и ты всё испортил

Здравствуйте, ry, Вы писали:

ry>Здравствуйте, Testator, Вы писали:

T>>Бывает кстати внутрифирменные стандарты применяются с таким безумным фанатизмом, что в итоге получается бестолковый монстр, который использовать невозможно. По мне главное чтоб какой-то стиль вообще был, общий для всего кода.
ry>Это проблемы менеджмента, но я не встречал особого фанатизма, скорее, наоборот.

Такое в крупных конторах бывает, где бюрократия уже оторвалась от реальности Поинт в том, что "внутрифирменные стандарты" и качество кода не всегда коррелируют в нужном виде.

T>>>>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.
ry>>>А эти в ТЗ неплохо укладываются, если, конечно, заказчик согласится.

T>>Если хотя бы что-то из того что выше упущено, код получается говно, т.е. некачественный И не важно куда чего там засовывается или укладывается. Заказчик он как пациент в больнице. Слушать его жалобы конечно надо, но принимать решения все равно должен лечащий врач
ry>А если больной не в состоянии оплатить то лечение? Ну или не хочет по любой причине: не понимает необходимости или понимает его бесполезность. Тогда подрядчик может это делать за счёт внутренних ресурсов, если оные есть. Либо утереть руки.

Я тиражируемыми продуктами занимаюсь. Больных сотни тысяч, всех выслушать нет возможности. Если даже что-то на заказ делается, и у заказчика какие-то серьезные проблемы с пониманием соотношения сроков/качества/трудозатрат, надо однозначно бросать это дело и искать более вменяемых людей. Иначе все время будешь заниматься заплатками к говнокоду, и жаловаться что жизнь дала трещину

Здравствуйте, Ikemefula, Вы писали:

I>Много мест для изменения это достаточно простой признак. Больше — хуже, меньше — лучше. Много сущностей — точно такой же признак. Понятно-непонятно это с учетом целевой аудитории(команда/организация и тд). Всем понятно — хорошо. Не всем — плохо. Опять таки все просто.
Много мест для изменения — это факт по результатам багфикса, или прогноз для исправления бага (добавления функциональности). Если прогноз, то это тут много вопросов: разобрался ли человек в проблеме, решаема ли задачи для данной архитектуры/дизайна. При этом вопрос кривизны дизайна зависит от того для чего был сделан именно такой дизайн. В общем один субъективизм, нет конкретики. Качество кода — это субъективная характеристика, уровня нравится не нравится. Чем больше человек участвует в создании и оценке кода, тем меньше он нравится этому коллективу. Качество кода можно объективно судить только на основе какого то стандарта. Если нет стандарта, то все оценки субъективны. Кому-то нравится, кому то нет. Если стандарта нет роль стандарта обычно выполняет ведущие программисты или кто-там-еще-стоит-повыше. Полный субъективизм, который сложно распространить на другие проекты.

I>>>3. Простыни (длинные файлы/классы/функции/конфиги/имена/цепочки и тд)
I>>>4. Высокая вложенность конструкций
I>>> а Несколько классов в одном рукописном файле
I>>> б уровень вложенности блоков >= 3 ACHTUNG !
I>>> в вложенные конструкции вроде сложных запросов linq(на пол-экрана и более)
I>>> г несколько операторов в одной строке или одной конструкции, например условие цикла из десятка логический условий
_>>3 и 4 пункт — тут надо найти оптимальное решение. Улучшение одного параметра ухудшает другой параметр.

I>Оптимальное искать надо, но можно избегать вложенности и простыней при этом не будет.
Вложенность => 3: проект-модуль-файл — предел вложенности исчерпан. Все проекты плохие. А солюшены подавно.


I>>>3. Комментарии в файле (sic!)
_>>Если кратко(?) и по существу(?), а не поздравление с днем рождения, то претензий не имею.

I>

I>            //       __________________
I>            // _____/ AddFileToMRUList \___________________________________________________
I>

Красиво, мне нравится.

I>или

I>

I>        /// Gets filter string for designs files
I>        /// </summary>
I>        /// <returns>The filter string.</returns>
I>        private string GetDesignFilesFilter()
I>

Возможно такие требования — обязательный комментарий для автодокументирования. Иначе метод не попадет в документацию и никто не узнает о его существовании.

I>или

I>

I>              else{  
I>                   //Revert cancelled
I>                   SetCanceled();
I>                   }
I>

Нормально, главное чтоб комментарий и выполняемые действия не противоречили друг другу.

I>>>6. Десятки сборок по пять классов на каждую
I>>>7. разделение проекта на несколько солюшнов
_>>3,4 пункты предыдущей секции.

I>Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится.
Тут много вопросов: сперва надо узнат почему так разделили, может это специально сделано, чтоб любители рефакторить не поломали/испортили чужой код, в котором он не разбирается.

I>>>8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка
_>>зависит от проекта, с таким же успехом можно сказать msbuild в топку.

I>Можно. Но это всего лишь симптом. Все эвристики это только симптомы.
Тогда почему такие конкретно идиоматические приставки к вполне хорошим инструментам. То есть эвристики еэто субъективность в квадрате.

I>>>9. мануал или т.н. курс молоджого бойца для работы с проектом
_>>То есть молодые бойцы должны терроризировать стариков глупыми вопросами и коммитами не совместимыми с жизнью проекта?

I>Бывает так, что старики пишут нечто понятное только им самим а мануал просто маскирует эту проблему.
А как же первый пункт про понятность дизайна.

_>>Не объяснимые "черные ящики" в коде проекта, думаю, это не хорошо. Не все молодые бойцы реверс-инженеры с рождения. Русский язык проще понимается, чем противоречивый синтаксис с семантикой некоторых языков программирования.

I>А еще мануал вытесняет живое общение.
Субъективизм в кубе. Дефицит общения вне рабочее время?
Не все хорошо импровизируют, проще читать по бумажке, объясняя непонятные моменты.

Повторюсь, нет смысла говорить качестве кода при отсутствии стандартов (общепринятых принципов).

Здравствуйте, Ikemefula, Вы писали:

IT>>Для начала хорошо бы определить критерии хорошего качественного кода.
I>Это КСВ и ты всё испортил
Извините

Здравствуйте, blackhearted, Вы писали:

I>>А еще мануал вытесняет живое общение.
B>а как же распределённые команды?
B>ждать в Саратове, пока проснётся НЙ?

Есть варианты :
1 сделать билд в один шаг, т.е. удалённый разраб скачивает код, запускает сборку хоткеем в IDE и работает
2 обложить костылями (говнанты,гономавены) и тд. Вот типичный расклад в этом случае http://rsdn.ru/forum/humour/2651979.1.aspx

Автор: --
Дата: 11.09.07

3 написать мануал, после пары месяцев все сведётся к п.2 с той разницей, что мануал будет устаревшим и времени будет уходить больше чем в п.2

Выбирай

Здравствуйте, Testator, Вы писали:

T>А я и не писал о достаточных условиях, только о необходимых. Вот к как контр-пример типичные признаки говнокода:
T>- В проекте используется куча разных нотаций. Названия переменных, функций, классов ни о чем не говорят, их друг от друга не отличить.
T>- В каждом подпроекте своя реализация примитивов всяких строк, контейнеров. Повсеместный копипаст с минимальными заплатками. Изменение/добавление фичи требует перелопачивания кучи файлов.
T>- Проект делается под узкие текущие требования. При любом изменении в них проще переделать все заново чем пытаться перекроить тонны спагетти.

Это всё больше эмоции Капитана Очевидности, а не определение качества кода.

Здравствуйте, pzhy, Вы писали:

P>>>Нет, много хорошего кода, и в опенсорсе, и в МС, и в другом. Только мне ваш вопрос, напомнил о моей "проблемме" — все время рефакторю код, и не потому что он плох, он работает, и за год, ни одного бага, но рефакторю из любви к красивому, и тут нать, баги ... Как от этой привычки избавиться?
N>>Ничего не понял. Расшифруйте.
P>Вот пишите вы код. Часто в дедлайне, поэтому — архитектурно — он не красив. Потом вы его поддерживаете... Потом — есть у вас время — начинаете в нем красоту наводить (и архитектурно и локально), и багов после этого больше, чем в первоначально было...

Почему это багов больше? При правильном подходе этот процесс не создаёт новые баги.

Здравствуйте, Testator, Вы писали:

IT>>Да ладно! Количество багов, уходящих в продакшин у вас тоже формализовано?
T>У нас баги в основном лезут из-за недокументированных особенностей сторонних компонент. В ядре Windows их не перечесть

А зачем вы лазиете в ядро Windows?

T>Так а откуда баги то берутся? Не дизайновые, а именно тупые ошибки кодирования. Элементарные правила как раз и нужны чтобы уменьшить вероятность их появления. То что облась эта хорошо формализуемая, надеюсь нет сомнений?

Есть.

T>Умные компиляторы выдают варнинги на любой чих, есть отдельные анализаторы для разных языков и платформ. Все в конечном итоге упирается в человеческий фактор, аккуратность в соблюдении набора известных правил. Т.е. если все написано так что баг там невозможен, то его и не будет

Я же говорю, где-то вы там у себя серебрянную пульку прикопали и не сознаётесь.

T>Просвети же наконец, что ты то понимаешь под _качеством кода_?

Я не знаю Знал бы — не спрашивал. Могу только предположить, что к разному коду могут предъявляться абсолютно разные требования, в том числе и к его качеству. А по сему разговор, который вы здесь ведёте мне странен и непонятен.

Здравствуйте, Mamut, Вы писали:


LVV>>Кто может привести примеры прекрасного качества кода?
LVV>>Из жизни, а не из книжек.

M>Не знаю насчет прекрасности, но

M>Например есть такая схема HTTP: http://webmachine.basho.com/diagram.html
M>И вот, как с ней работает webmachine: https://github.com/basho/webmachine/blob/master/src/webmachine_decision_core.erl

M>И т.п. v3 — это версия схемы. b13, b12 и т.п. — соответствующее место на схеме. В итоге код получается достаточно поянтынм и документированым.

Взгляд со стороны.
Сначала посмотрел код. Ничего не понятно: туча decision(v3*) которые не понятно что делают. Что будет если циферкой ошибешься и вместо 4 напишешь 5. Особенно вот это v3l13 — это "V три тысячи сто тринадцать" или "V тридцать один L три" или V три L тринадцать?
Посмотрел диаграмму — какие-то знакомые кодовые буковки и циферки, где то я их видел, сама диаграмма достаточно понятна, а код еще под вопросом. А после того как я прочитал что код реализует эту диаграмму — теперь все понятно, но v3l13 не одобряю, хотя если проводить аналогии с диаграммой то можно сделать вывод о формате кодирования состояний.
Выводы: код — "плохой", диаграмма — "хорошая", код вместе с диаграммой — достаточно хороший. То есть в данном случае "качество" диктуется документацией. Про качество продукта (программного средства) ничего не известно, гулить не хочется.

Здравствуйте, Testator, Вы писали:

I>>Ого, это сильно — писать без багов

T>А что тут особенного? Сишный код, написанный четко по документации. Выдает на выходе ровно то что должно выходить. Баги есть в основном логические, те что выше. А формальную правильность можно даже доказать если сильно нужно. Теория неподвижной точки тут применима, но очень объемное доказательство выйдет Вы в курсе про эту возможность, или снова дважды два не четыре?

Я никогда не поверю, что сишные программисты никогда не ошибаются с указателями

I>>Я уже объяснил, почему это невозможно.

T>Не взял бы я такого на проект. Постоянно встречаются люди, которые начинают объяснять почему что-то сделать невозможно. И как мало тех, кто ищет и находит варианты решения на первый взгляд черезчур трудных задач.

Писать без ошибок невозможно. Создавать хорошие продукты, даже если писать с ошибками, возможно. Ты определись, что для тебя важнее.

Я довольно давно на РСДН.
И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
Как правило, посты следующего содержания:

Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.

Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
Кто может привести примеры прекрасного качества кода?
Из жизни, а не из книжек.

Здравствуйте, netch80, Вы писали:

N>А зачем рассказывать про хороший код?
N>Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует.
Требует!
Ведь именно так рассуждают журналисты! Поэтому по ТВ — одна чернуха. Как говорил Задорнов: наши новости можно смотреть только под водку и не чокаясь!
Хороший код — это пример для новичков — нужно его показывать!
LVV>>Кто может привести примеры прекрасного качества кода?
LVV>>Из жизни, а не из книжек.
N>Я могу их из своей практики привести хоть тысячу, но не вижу смысла. Во-первых, что это прекрасный код — то есть выполняет ровно свою задачу, чёток, понятен и пригоден к развитию — пойму только я и коллеги, остальные в лучшем случае пожмут плечами. Во-вторых, он соседствует в одном и том же проекте с кошмарами, которые нельзя выбросить только потому, что они доведены до достаточно рабочего состояния. В-третьих, такой код часто требовал больше усилий, чем надо бы (есть у меня в подчинённых, например, перфекционист, который никогда не может выдержать сроки).
1. Ну, можно ведь не просто код, а небольшие пояснения дать, и объяснить в чем красота. А иначе КАК учиться хорошему кодированию?
2. Не выдерживание сроков может говорить о том, что сроки просто занижены. Расчитаны на написание быдлокода, а не качественного кода. И никто об этом не задумывается.
N>Так что я (повторюсь) устроил бы тут голосование. Дать пяток уровней качества — от кошмара до идеала — и вопрос типа "то с чем вы работаете сейчас — к чему ближе?"
Возможно, но я пока не могу четко сформулировать.

Здравствуйте, LaptevVV, Вы писали:

N>>А зачем рассказывать про хороший код?
N>>Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует.
LVV>Требует!
LVV>Ведь именно так рассуждают журналисты! Поэтому по ТВ — одна чернуха. Как говорил Задорнов: наши новости можно смотреть только под водку и не чокаясь! :)
LVV>Хороший код — это пример для новичков — нужно его показывать!

Угу. Но вместе с ТЗ, разве не так? А это уже немного другой уровень рассмотрения.


LVV>1. Ну, можно ведь не просто код, а небольшие пояснения дать, и объяснить в чем красота. А иначе КАК учиться хорошему кодированию?
LVV>2. Не выдерживание сроков может говорить о том, что сроки просто занижены. Расчитаны на написание быдлокода, а не качественного кода. И никто об этом не задумывается.

Он сам называл сроки. Ладно, это тема отдельная.

N>>Так что я (повторюсь) устроил бы тут голосование. Дать пяток уровней качества — от кошмара до идеала — и вопрос типа "то с чем вы работаете сейчас — к чему ближе?"
LVV>Возможно, но я пока не могу четко сформулировать.

Аналогично. Ладно, ещё подумаем...

Здравствуйте, LaptevVV, Вы писали:

LVV>Я довольно давно на РСДН.
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
LVV>Как правило, посты следующего содержания:
LVV>

LVV>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.

LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...

Очень мало контор уделяет внимание качеству кода.

Здравствуйте, denisko, Вы писали:

I>>Очень мало контор уделяет внимание качеству кода.
D>А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д.

Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.

>Если качество кода ставится во главу угла, то во-первых, получается процесс ради процесса, а во-вторых, если на входе и есть что-то, то оно настолько сделано через задницу, что использовать его всем кроме автора (или небольшой групп ы авторов) соверешенно невозможно, причем модификацию и поддержку тоже необходимо осуществлять исключительно через задницу.

"модификацию и поддержку тоже необходимо осуществлять исключительно через задницу" — собственно качество кода и необходимо для устранения этой проблемы

Здравствуйте, Ikemefula, Вы писали:

I>Очень мало контор уделяет внимание качеству кода.

И это правильно. Клиент платит за продукт, решающий его проблемы, а не за мифическое "качество кода". Поэтому качество кода и находится на соответствующем месте в иерархии ценностей компании... что тут удивительного?
Есть, безусловно, некоторое количество компаний, которые продают исходники. Вот тут "качеству кода" уделяется внимание, — ну, так этот код и есть их продаваемый продукт. Нет?

Здравствуйте, ry, Вы писали:

ry>Несколько лет был на поддержке кода пользовательского интерфейса моторольских телефонов. Когда только вообще впервые увидел моторольский код, ужаснулся, но не от качества (что я понимал тогда в этом), а от его объёма — и понял, какой же фигнёй занимался до этого. И только ленивый не ругался на его качество. То ли под воздействием таких разговоров, то ли в силу возрастающего профессионализма я стал считать, что могу писать код лучше. Ещё некоторое время спустя я увидел (стал различать), что это не то чтобы плохое качество кода, а заплатка тут, заплатка там, и местами вообще заплата на заплате. Но такова была политика (процесс разработки) Моторолы. На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.

Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда

Здравствуйте, LaptevVV, Вы писали:

LVV>Кто может привести примеры прекрасного качества кода?

Помню, в квейках, вроде, хороший код.

LVV>Из жизни, а не из книжек.

Здравствуйте, Alexéy Sudáchen, Вы писали:

LVV>>Я довольно давно на РСДН.
LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

AS>Русский программист уже давно (как минимум среди своих) стало нарицательным =)

Есть поговорка: "некогда пилу точить, пилить надо". Как раз про русских

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, denisko, Вы писали:

I>>>Очень мало контор уделяет внимание качеству кода.
D>>А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д.

I>Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.
Аккуратно, когда написан ради того, чтобы решить задачу с соблюдением простых правил типа.
1. Читабельные имена функций и переменных.
2. Есть комментарии, там где это необходимо.
3. Нет одной и той же простыни более двух раз с разными названиями. Копипаста держится в разумных пределах.
4. Нет магических чисел и переменных судьбы.
5. Нет применения модных приемов (типа идиотские схемы наследования в стиле Шеридана) только ради того, чтобы применить модные приемы.


>>Если качество кода ставится во главу угла, то во-первых, получается процесс ради процесса, а во-вторых, если на входе и есть что-то, то оно настолько сделано через задницу, что использовать его всем кроме автора (или небольшой групп ы авторов) соверешенно невозможно, причем модификацию и поддержку тоже необходимо осуществлять исключительно через задницу.

I>"модификацию и поддержку тоже необходимо осуществлять исключительно через задницу" — собственно качество кода и необходимо для устранения этой проблемы
Смотри, упрощенно, чтобы добавить новую фичу ты смотришь куда добавить (n_1 квантов времени), думаешь как (n_2 квантов времени), добавляешь (n_3). Если у тебя аккуратный и относительно понятный код без изысков, то n_3 самое большое, n_1,n_2 довольно малы. Если у тебя очень качественный код созданный ради качества кода, то очень часто n_3 действительно очень мало, а вот додуматься до способа, когда оно мало (n_2), и понять куда приспособить новую фичу (n_1) занимает очень много времени, так что суммарное время добавления может быть больше, чем в первом случае.

Здравствуйте, Ikemefula, Вы писали:

ry>>Ведь столько лет этот код жил, развивался, поддерживался и успешно продавался.

I>Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
Просто-напросто кончился цикл жизни данного продукта. Но это уже проблемы менеджмента, никак не кода.

I>Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда
По поводу юзабельности могу сказать следующее: на своей нокии, которая у меня уже 3,5 года, пути доступа к некоторым редко используемым фичам приходится искать (никак не запомню), в моторольских же телефонах такого вроде бы не было никогда. Но это, видимо, проблемы персональных предпочтений. Хотя вот к иФону вообще практически никаких претензий (у меня) — а какого качества там код?

Здравствуйте, denisko, Вы писали:

I>>Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.
D>Аккуратно, когда написан ради того, чтобы решить задачу с соблюдением простых правил типа.
D>1. Читабельные имена функций и переменных.
D>2. Есть комментарии, там где это необходимо.

комментарии чаще всего указывают на проблемные места

D>3. Нет одной и той же простыни более двух раз с разными названиями. Копипаста держится в разумных пределах.

я бы сказал "двух и более раз"

D>4. Нет магических чисел и переменных судьбы.
D>5. Нет применения модных приемов (типа идиотские схемы наследования в стиле Шеридана) только ради того, чтобы применить модные приемы.

всех 5 пунктов сильно недостаточно

I>>"модификацию и поддержку тоже необходимо осуществлять исключительно через задницу" — собственно качество кода и необходимо для устранения этой проблемы
D>Смотри, упрощенно, чтобы добавить новую фичу ты смотришь куда добавить (n_1 квантов времени), думаешь как (n_2 квантов времени), добавляешь (n_3). Если у тебя аккуратный и относительно понятный код без изысков, то n_3 самое большое, n_1,n_2 довольно малы. Если у тебя очень качественный код созданный ради качества кода, то очень часто n_3 действительно очень мало, а вот додуматься до способа, когда оно мало (n_2), и понять куда приспособить новую фичу (n_1) занимает очень много времени, так что суммарное время добавления может быть больше, чем в первом случае.

Это чуток упрощенно.

Некачественный код это целая куча признаков, отдельным сообщением запощу

А Некачественный

1 Сначла мне надо разобраться в имеющемся коде и понять что он делает, пару раз продебажить и тд
2 найти местА (sic!) где нужно внести изменения
3 внести изменения — долго, но меньше чем п.1 и п.2 + повторить п.2 т.к. не всегда очевидно что и где надо менять
4 проверить все смежные места, если вдруг менялось поведение общей функции и повторить п. 1..3
5 в некачественном коде всегда возникает кучка багов, для каждого повторить 1..5

Б Качественным кодом

1 Прочитать имеющийся коде — этого достаточно что бы понять, что к чему
2 найти местО (sic!) где нужно внести изменени — как правило одно или дизайн подсказывает где такие места
3 внести изменения — очень быстро
4 проверить все смежные места — их как правило очень мало
5 в качественном коде баги возникают достаточно редко, для каждого повторить 1..5

Как правило, разница между А и Б настолько велика, что окупает усилия по улучшению кода.

Единственный нюанс, это выбор момента, когда нужно улучшать код Одноразовый код однозначно улучшать не стоит. Код в который придется лазить постоянно, улучшать нужно постоянно.

Здравствуйте, LaptevVV, Вы писали:

LVV>Из жизни, а не из книжек.

Мне TeX нравится. Ну а так я не очень строго отношусь к коду, всегда готов с ним работать

Здравствуйте, Ikemefula, Вы писали:

I>>>Очень мало контор уделяет внимание качеству кода.
D>>А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д.

I>Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.
А потом просят добавить новые фичи, но только в одну из веток. В результате возникают флажки, виртуальные функции, а конце скрещивание ежа и ужа.

Здравствуйте, Ikemefula, Вы писали:

I>Теперь вопрос — является ли стоимость изменения критичной для клиента который платит за продукт решающий его проблемы ?

Боюсь, что стоимость изменений станет критичной для исполнителя, потому как клиенту на это по фигу, как и на объяснения исполнителя, что "там все плохо". О затратах на правки багов я даже не заикаюсь. Как правило, баги долго разыскиваются, но легко правятся. У меня в одном из проектов был случай: нашел проблему буквально за пару минут, но чинил примерно неделю. Наследование a-la Sheridan и некоторые другие мелочи.

Здравствуйте, Privalov, Вы писали:

P>Боюсь, что стоимость изменений станет критичной для исполнителя, потому как клиенту на это по фигу, как и на объяснения исполнителя, что "там все плохо". О затратах на правки багов я даже не заикаюсь. Как правило, баги долго разыскиваются, но легко правятся. У меня в одном из проектов был случай: нашел проблему буквально за пару минут, но чинил примерно неделю. Наследование a-la Sheridan и некоторые другие мелочи.

А что ты делал целую неделю ?

Здравствуйте, ry, Вы писали:

I>>Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
ry>Просто-напросто кончился цикл жизни данного продукта. Но это уже проблемы менеджмента, никак не кода.

Проблемы менеджемента как раз проявляются тотально, в т.ч. и в коде. Если менеджменту насравть на код это ровно тоже самое, что заинтересованность в говнокоде. Есть такое являение: "Пока будут баги, у меня будет работа" Это пораженческие настроение и от такого руководителя/команды надо бежать без оглядки.

И то и другое проявляется в т.ч. в виде говнокода, а у говнкода основной эффект — окончание цикла жизни кода. Повторяю — основной !

I>>Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда
ry>По поводу юзабельности могу сказать следующее: на своей нокии, которая у меня уже 3,5 года, пути доступа к некоторым редко используемым фичам приходится искать (никак не запомню), в моторольских же телефонах такого вроде бы не было никогда. Но это, видимо, проблемы персональных предпочтений. Хотя вот к иФону вообще практически никаких претензий (у меня) — а какого качества там код?

Пока не знаю, айфон год лежал в тумбочке на работе, я им пользовался довольно часто, но себе так и не купил (забухал)

Здравствуйте, denisko, Вы писали:

D>Смотри, упрощенно, чтобы добавить новую фичу ты смотришь куда добавить (n_1 квантов времени), думаешь как (n_2 квантов времени), добавляешь (n_3). Если у тебя аккуратный и относительно понятный код без изысков, то n_3 самое большое, n_1,n_2 довольно малы. Если у тебя очень качественный код созданный ради качества кода, то очень часто n_3 действительно очень мало, а вот додуматься до способа, когда оно мало (n_2), и понять куда приспособить новую фичу (n_1) занимает очень много времени, так что суммарное время добавления может быть больше, чем в первом случае.

Ты, просто не тот код называешь качественным
Необоснованная заумность -- это, как раз недостаток!

Здравствуйте, Ikemefula, Вы писали:

I>Клиент как правило не в курсе, что качество кода может быть разным или, как минимум, не понимает насколько это важно.

Клиент, как правило, не в курсе, что существует вообще какой-то там "код". (с) наблюдение из жизни

Здравствуйте, netch80, Вы писали:

N>>>А зачем рассказывать про хороший код?
N>>>Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует.
LVV>>Требует!
LVV>>Ведь именно так рассуждают журналисты! Поэтому по ТВ — одна чернуха. Как говорил Задорнов: наши новости можно смотреть только под водку и не чокаясь!
LVV>>Хороший код — это пример для новичков — нужно его показывать!

N>Угу. Но вместе с ТЗ, разве не так? А это уже немного другой уровень рассмотрения.
Интересно, что про плохой код обычно кричат без всякого упоминания о ТЗ...

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Kernan, Вы писали:

I>>>Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
I>>>Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда
K>>Ты не прав, P2K платформа была одна из самых качественных и гибких у мотороллы (посмотри сколько телефонов на ней было сделано). Единственный минус, она устарела. С юзабилити у моторов было всё хорошо, всегда всё под рукой и легко найти, в отличии от нокии к примеру.

I>Я често не понимаю, где ты углядел юзабилити у моторов. Что за модель с P2K ? Может я такую знаю.
Легендарный E398, L7 и т.п. их было много.

Здравствуйте, Vlad_SP, Вы писали:

I>>Клиент как правило не в курсе, что качество кода может быть разным или, как минимум, не понимает насколько это важно.

V_S>Клиент, как правило, не в курсе, что существует вообще какой-то там "код". (с) наблюдение из жизни

Бывают наверняка и такие клиенты, мне правда не попадались. Правда почти все клиенты частенько продавливают решения которые дают профит в краткосрочной перспективе. Без учета кода это мягко говоря не самый лучший способ строить бизнес.

Здравствуйте, Ikemefula, Вы писали:

I>А что ты делал целую неделю ?

Говорю же — баг чинил.

На самом деле головняка хватало. Из-за тотального применения наследования там такие эффекты вылезали, что аж не по себе иногда становилось. Ну и размеры методов иногда впечатляли. А иногда весь forkflow вообще в единственный метод запихивали.

Здравствуйте, Kernan, Вы писали:

I>>Я често не понимаю, где ты углядел юзабилити у моторов. Что за модель с P2K ? Может я такую знаю.
K>Легендарный E398, L7 и т.п. их было много.

Популярные девайсы были, да. Только багов было столько, что народ вечно с прошивками возился. Открой любой форум — как прошить, где прошить, какую прошивку брать и тд и тд.
"Не определяется телефон — попробуй почистить контакты"

Нокия того же времени была куда посильнее, уверяю.

Здравствуйте, Privalov, Вы писали:

P>Говорю же — баг чинил.

P>На самом деле головняка хватало. Из-за тотального применения наследования там такие эффекты вылезали, что аж не по себе иногда становилось. Ну и размеры методов иногда впечатляли. А иногда весь forkflow вообще в единственный метод запихивали.

Если это один раз, то сойдёт за развлекуху

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Kernan, Вы писали:

I>>>Я често не понимаю, где ты углядел юзабилити у моторов. Что за модель с P2K ? Может я такую знаю.
K>>Легендарный E398, L7 и т.п. их было много.

I>Популярные девайсы были, да. Только багов было столько, что народ вечно с прошивками возился. Открой любой форум — как прошить, где прошить, какую прошивку брать и тд и тд.
I>"Не определяется телефон — попробуй почистить контакты"
Ни разу такого не видел. Возможно ты имеешь ввиду кастомные прошивки.

I>Нокия того же времени была куда посильнее, уверяю.
Если ты про смартфоны, то да.

Здравствуйте, LaptevVV, Вы писали:

LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Вообще говоря, вброс не очень. Subj для КСВ не годится. Лучше так: "Кто говнокодером еще не был ?" или "Кто не говнокодер ?"

Здравствуйте, Ikemefula, Вы писали:

I>>>Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
ry>>Просто-напросто кончился цикл жизни данного продукта. Но это уже проблемы менеджмента, никак не кода.

I>Проблемы менеджемента как раз проявляются тотально, в т.ч. и в коде. Если менеджменту насравть на код это ровно тоже самое, что заинтересованность в говнокоде. Есть такое являение: "Пока будут баги, у меня будет работа" Это пораженческие настроение и от такого руководителя/команды надо бежать без оглядки.

Я плохо выразился. Под "проблемы менеджмента" имел в виду продуктовый менеджмент, не кода. У всякого продукта есть срок жизни, и всему наступает конец. Будь то программа, дом, дерево, сын или телефон. Телефон — это аппаратно-программный комплекс. И уж коли платформе пришёл кирдык, то сколько и как ни старайся продлить ей жизнь, лучше её вовремя прибить самому, а Моторола протянула с этим.

I>И то и другое проявляется в т.ч. в виде говнокода, а у говнкода основной эффект — окончание цикла жизни кода. Повторяю — основной !
Не согласен. Конечно, код может укорачивать жизненный цикл, но, думается, главным ограничителем жизни является востребованность продукта рынком. А говнокод просто может сыграть злую шутку с его автором при наличии конкурентного продукта (а может и не сыграть).

Здравствуйте, Dym On, Вы писали:

LVV>>Кто может привести примеры прекрасного качества кода?
DO>Прекрасный код это код, который пишу я в текущий момент, все остальное — отстой, включая мой код, который я писал вчера .

Сильно

Здравствуйте, Ikemefula, Вы писали:

I>>>И то и другое проявляется в т.ч. в виде говнокода, а у говнкода основной эффект — окончание цикла жизни кода. Повторяю — основной !
ry>>Не согласен. Конечно, код может укорачивать жизненный цикл, но, думается, главным ограничителем жизни является востребованность продукта рынком. А говнокод просто может сыграть злую шутку с его автором при наличии конкурентного продукта (а может и не сыграть).

I>Говнокод всегда удорожает разработку. Всегда. И всегда это становится причиной окончания цикла жизни кода. Ты можешь хотеть юзать платформу год-два три, но денег больше нет
I>Дорогая разработка софта — значит на разработку железа денег будет меньше. Все очень просто.

Нет, не всё просто.
В начале разработки удешевляет. Всегда. Наверно . А дальше — как кривая вывезет.
На прототипах — всегда дешевле.
На продуктах, предназначенных для внутреннего использования, — в основном дешевле.
На разовых продуктах (например, тесты) — всегда дешевле.

Здравствуйте, Mamut, Вы писали:

I>>1. Количество ревизий у файла превышает все разумные границы ACHTUNG !

M>В случае, если идем от прототипа к работающему коду, да еще с git'ом, то окличество ревизий ожет быть большое

Я забыл еще одну эвристику — продакшн это допиленый прототип.

Неужели гит может заставить тебя на ровном месте вносить изменения в код ?

Здравствуйте, Ikemefula, Вы писали:

I>Прототип это не продакшн. Пока тебе не надо менять готовый код или можно быстро менять готовые куски кода, говнокод рулит. За эту скорость придется заплатить — девелопер перестаёт развиваться, т.к. все эффективные решения обычно требуют многих переделок прежде, чем появится чтото более менее толковое.

Да плевать на девелопера и его развитие (шучу). "Главное — это план, откуда хошь вынь, а сюда положь. Я не шучу." (с)

ry>>На продуктах, предназначенных для внутреннего использования, — в основном дешевле.

I>Дешевле там, где можно допиливать фичи сбоку. Как только надо влазить и править уже готовый код, всё, туши свет — ни качества, ни сроков невозможно гарантировать.

I>Если кода еще мало, то есть шанс один говнокод заменить быстро другим говнокодом. Со временем и этот резерв исчерпывается.

ry>>На разовых продуктах (например, тесты) — всегда дешевле.

I>Тест и разовые продукты это разные вещи Говнокод в тестах вносит хаос еще почище говнокода в продукте.

Видимо, мы с тобой несколько по-разному понимаем, что такое "говнокод". Надо было начинать с определений.
Что такое "говнокод" по моему мнению: это код, полностью удовлетворяющий ТЗ в части функциональности и не содержащий ошибок, влияющих на эту функциональность и его работоспособность, и не удовлетворяющий ТЗ (если таковые есть) в части расширяемости, и/или поддерживаемости, и/или тестируемости и т.д. и т.п.

<Лирическое отступление>
А теперь представь себя владельцем стартапа. Ты заинтересовал инвестора, и он дал тебе денег на разработку. И почти никогда он не даст тебе денег столько, чтобы ты шиковал — возможно, сам ты лично вообще будешь сидеть без денег. Представил? Теперь ответь, только честно, куда ты пошлёшь девелопера с его требованиями/желаниями развиваться. Ты будешь экономить на всём, в частности на качестве кода, лишь бы добиться поставленной цели. Так является ли "говнокод" говнокодом? Да, возможно, потом он будет тормозить разработку, да, возможно, потом ты что-то не дополучишь, но — потом, к тому же не факт. Так что, не всё то — говно, что воняет
</Лирическое отступление>

Здравствуйте, LaptevVV, Вы писали:

LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

Для начала хорошо бы определить критерии хорошего качественного кода.

I>>>1. Количество ревизий у файла превышает все разумные границы ACHTUNG !

M>>В случае, если идем от прототипа к работающему коду, да еще с git'ом, то окличество ревизий ожет быть большое

I>Я забыл еще одну эвристику — продакшн это допиленый прототип.

Для продакшна поправка принимается


I>Неужели гит может заставить тебя на ровном месте вносить изменения в код ?

Нет конечно. Просто с гитом эти изменения можно легко и быстро заливать куда угодно. Шустрый он зараза.

Здравствуйте, Mamut, Вы писали:

I>>Неужели гит может заставить тебя на ровном месте вносить изменения в код ?

M>Нет конечно. Просто с гитом эти изменения можно легко и быстро заливать куда угодно. Шустрый он зараза.

То есть, ожидаемые, то есть, разумные, границы для гита будут повыше ? Правильно ?

Здравствуйте, Ikemefula, Вы писали:

I>7. разделение проекта на несколько солюшнов
I>8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка

после этих пунктов возникают серьёзные сомнения, что кроме лабы в институте автор этих строк написал хоть что-то.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, ry, Вы писали:

ry>>А теперь представь себя владельцем стартапа. Ты заинтересовал инвестора, и он дал тебе денег на разработку. И почти никогда он не даст тебе денег столько, чтобы ты шиковал — возможно, сам ты лично вообще будешь сидеть без денег. Представил? Теперь ответь, только честно, куда ты пошлёшь девелопера с его требованиями/желаниями развиваться.

I>Если стартап это не "накидал-отдал-забыл" то никуда посылать не надо.
Да я не посылку имел в виду, а то, что ты наймёшь самого дешёвого разработчика, способного справиться с поставленной задачей в установленный срок и с обусловленным качеством.

>>Ты будешь экономить на всём, в частности на качестве кода,

I>Ни в коем случае. Говнокод _замедляет_ и _удорожает_.
Участвовал в стартапах?
Я вот, например, практически год был без зарплаты, работая по 10-14 часов в день почти без выходных.

>>лишь бы добиться поставленной цели. Так является ли "говнокод" говнокодом? Да, возможно, потом он будет тормозить разработку, да, возможно, потом ты что-то не дополучишь, но — потом, к тому же не факт. Так что, не всё то — говно, что воняет

I>Из за таких рассуждений многие проекты ко второй-третьей версии уходят со сцены имея неплохой функционал, просто потому что не могут развиваться.
К сожалению, не имею статистики, а потому не могу ни возразить, ни опровергнуть

Здравствуйте, ry, Вы писали:

IT>>Для начала хорошо бы определить критерии хорошего качественного кода.
ry>Качественным кодом является код, полностью удовлетворяющий ТЗ и внутренним документам (например, внутрифирменному стандарту кодирования) подрядчика/заказчика.
ry>Пойдёт?

Нет. ТЗ к качеству кода вообще не имеет никакого отношения. Внутренняя документация способна регулировать лишь малую часть проблем качества кода, а слишком зарегулированный код становится сам по себе проблемой.

Ещё идеи будут?

Здравствуйте, IT, Вы писали:

IT>>>Для начала хорошо бы определить критерии хорошего качественного кода.
ry>>Качественным кодом является код, полностью удовлетворяющий ТЗ и внутренним документам (например, внутрифирменному стандарту кодирования) подрядчика/заказчика.
ry>>Пойдёт?

IT>Нет. ТЗ к качеству кода вообще не имеет никакого отношения. Внутренняя документация способна регулировать лишь малую часть проблем качества кода, а слишком зарегулированный код становится сам по себе проблемой.

IT>Ещё идеи будут?

У меня нет. Вот тут на работе поспорили с мужиками по поводу процесса и результатов. Почему-то я остался в одиночестве (в гордом ). Для всех важен процесс типа: в спорте важно принимать участие, а не победа; в труде важен процесс труда, его интересность, а не результат. Для меня, наоборот, только победа, только результат, а интересность только в качестве бонуса к труду, но никак не в качестве самоцели. Исходя из таких приоритетов я и дал определение.

Здравствуйте, ry, Вы писали:

I>>Если стартап это не "накидал-отдал-забыл" то никуда посылать не надо.
ry>Да я не посылку имел в виду, а то, что ты наймёшь самого дешёвого разработчика, способного справиться с поставленной задачей в установленный срок и с обусловленным качеством.

Конечно. Только задача, сроки и качество диктуются проектом. Если это не "накидал-отдал-забыл", то сам понимаешь, что качество кода играет роль.

I>>Ни в коем случае. Говнокод _замедляет_ и _удорожает_.
ry>Участвовал в стартапах?

А что ты называешь стартапом ? Проект с нуля, собственный продукт или что ?

Если с нуля, то да.

ry>Я вот, например, практически год был без зарплаты, работая по 10-14 часов в день почти без выходных.

Здравствуйте, LaptevVV, Вы писали:

LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.
Я сейчас работаю в проекте, где поддерживается достаточно высокое качество кода.
Не идеальное, но хорошее.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, LaptevVV, Вы писали:

LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.

IT>Для начала хорошо бы определить критерии хорошего качественного кода.

Все просто, вот минимальные необходимые требования:
— Наличие единообразного стиля (соглашение о наименованиях, форматировании конструкций, модулей).
— Единообразие проектных подходов, наличие одинаковых узнаваемых паттернов на большинство решаемых кодом задач. То есть не должно быть так что в разных частях кода одна и та же задача решается разными способами.
— Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.

По поводу достаточных требований люди целые книжки пишут. А по мне для работы того что выше обычно хватает.

Здравствуйте, Ikemefula, Вы писали:

I>>>Если стартап это не "накидал-отдал-забыл" то никуда посылать не надо.
ry>>Да я не посылку имел в виду, а то, что ты наймёшь самого дешёвого разработчика, способного справиться с поставленной задачей в установленный срок и с обусловленным качеством.

I>Конечно. Только задача, сроки и качество диктуются проектом. Если это не "накидал-отдал-забыл", то сам понимаешь, что качество кода играет роль.
Конечно, играет, но, повторюсь, потом. Я и был нанят в тот стартап из-за плохого качества кода, созданного студентами, но свою роль (огромную и положительную) тот код сыграл.

I>>>Ни в коем случае. Говнокод _замедляет_ и _удорожает_.
ry>>Участвовал в стартапах?

I>А что ты называешь стартапом ? Проект с нуля, собственный продукт или что ?
Это был не мой проект.
Я был не с нуля. Вернее, я участвовал в запуске того стартапа, его начальных изысканий, физической реализуемости. И потом уже, спустя некоторое время, был приглашён туда для подготовки к сертификации (с точки зрения работоспособности софта, а не именно сертификации) разработанного продукта, так как софтовая часть падала в любой непредсказуемый момент.
А что называю стартапом? Да любой проект, разрабатываемый с нуля, будь он хоть собственным, хоть чужим.

Здравствуйте, Testator, Вы писали:


IT>>Для начала хорошо бы определить критерии хорошего качественного кода.

T>Все просто, вот минимальные необходимые требования:
T>- Наличие единообразного стиля (соглашение о наименованиях, форматировании конструкций, модулей).
T>- Единообразие проектных подходов, наличие одинаковых узнаваемых паттернов на большинство решаемых кодом задач. То есть не должно быть так что в разных частях кода одна и та же задача решается разными способами.
Эти требования засовываются во внутрифирменные стандарты.

T>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.
А эти в ТЗ неплохо укладываются, если, конечно, заказчик согласится.

T>По поводу достаточных требований люди целые книжки пишут. А по мне для работы того что выше обычно хватает.

Здравствуйте, Ikemefula, Вы писали:

>>Ты будешь экономить на всём, в частности на качестве кода,
I>Ни в коем случае. Говнокод _замедляет_ и _удорожает_.

Я лично понимаю, о чём говорит ry. Где-то видел такой термин — "технический долг". Можно залезть в такой долг,
но его придётся дальше отдавать. Можно на какое-то время не проводить лечения кода, и стартапы часто так и делают.
Но всегда приходит момент, когда надо не наворачивать слои вторичного продукта, а производить лечение (начиная с рефакторингов), и главное — вовремя это сделать и добиться, чтобы это сделали (оплатили).

>>лишь бы добиться поставленной цели. Так является ли "говнокод" говнокодом? Да, возможно, потом он будет тормозить разработку, да, возможно, потом ты что-то не дополучишь, но — потом, к тому же не факт. Так что, не всё то — говно, что воняет :)
I>Из за таких рассуждений многие проекты ко второй-третьей версии уходят со сцены имея неплохой функционал, просто потому что не могут развиваться.

Не потому что не могут развиваться, а потому, что им не дали возможность развиваться — продолжили гнать фичи.

Здравствуйте, Ikemefula, Вы писали:

Не буду хвалится мега-мини-проектами в которых я участвовал, но прокомментирую эти пункты со своей колокольни.

I>На всякий, шоб ссылаться, признаки проблемного кода

I>1. Кривой дизайн/микродизайн (непонятное, много мест для изменения, много сущностей и тд)
Когда я пришел в новый проект, то этот проект мне казался непонятным, в нем было много мест для изменения, много новых сущностей. В общем я ругался на кривой дизайн. Но когда понял что к чему (прошел месяц-полтора), оказался вполне нормальный проект. Хотя "старики" ругались на некоторую кривизну. Где правда?

I>2. Дублирование (в любом виде: от строчек, функций, классов до параллельных механизков вроде трёх версий контроллера ) ACHTUNG !
Копирование кусков кода с похожих решений считается. Доводить код до состояния реюзабельной библиотеки нет ресурсов.

I>3. Простыни (длинные файлы/классы/функции/конфиги/имена/цепочки и тд)
I>4. Высокая вложенность конструкций
I> а Несколько классов в одном рукописном файле
I> б уровень вложенности блоков >= 3 ACHTUNG !
I> в вложенные конструкции вроде сложных запросов linq(на пол-экрана и более)
I> г несколько операторов в одной строке или одной конструкции, например условие цикла из десятка логический условий
3 и 4 пункт — тут надо найти оптимальное решение. Улучшение одного параметра ухудшает другой параметр.

I>И разные эвристики ACHTUNG !

I>1. Количество ревизий у файла превышает все разумные границы ACHTUNG !
Это правда, чаще всех меняемый файл проекта обычно содержит самый проблемный код.

I>2. Появления кучки странных багов после небольшого фикса ("добавил картинку — пропал грид")
Слишком расплывчатая эвристика.

I>3. Комментарии в файле (sic!)
Если кратко(?) и по существу(?), а не поздравление с днем рождения, то претензий не имею.

I>4. Велосипеды. Например самопальное кеширование без грамотных юнит-тестов == рассадник багов.
I>5. Глотание исключений
4-5. Без комментариев все зависит от проекта.

I>6. Десятки сборок по пять классов на каждую
I>7. разделение проекта на несколько солюшнов
3,4 пункты предыдущей секции.

I>8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка
зависит от проекта, с таким же успехом можно сказать msbuild в топку.

I>9. мануал или т.н. курс молоджого бойца для работы с проектом
То есть молодые бойцы должны терроризировать стариков глупыми вопросами и коммитами не совместимыми с жизнью проекта?
Не объяснимые "черные ящики" в коде проекта, думаю, это не хорошо. Не все молодые бойцы реверс-инженеры с рождения. Русский язык проще понимается, чем противоречивый синтаксис с семантикой некоторых языков программирования.

Здравствуйте, netch80, Вы писали:

N>Я лично понимаю, о чём говорит ry. Где-то видел такой термин — "технический долг". Можно залезть в такой долг,
N>но его придётся дальше отдавать. Можно на какое-то время не проводить лечения кода, и стартапы часто так и делают.
N>Но всегда приходит момент, когда надо не наворачивать слои вторичного продукта, а производить лечение (начиная с рефакторингов), и главное — вовремя это сделать и добиться, чтобы это сделали (оплатили).

Проще отделить качество кода от целей проекта. Тогда сюда вписывается в т.ч. и метафора долгов.

Здравствуйте, Ikemefula, Вы писали:

I>Ты пойми простую вещи, качество кода и цели проекта это разные вещи и не нужно смешивать эти понятия.

I>У (не)качественного кода вполне характерные признаки и цели проекта здесь ни при чем.

I>Если у тебя в целях проекта быстрый выпуск версии и ты решил пожертвовать качетсвом, то пожалуйста, сколько угодно. Но это не сделает код качественным А из твоего определения следует ровно обратное.

I>Разделение этих двух понятий даёт полезное свойство — качество кода может соответсвтвовать целям проекта, а может и не соответствовать. То есть появляется дополнительная точка контроля — девелоперу можно внятно объяснить, что не так с его кодом.

I>И если вдруг тебе придется искать аналогии, то далеко ходить не надо — стерильный инструмент используется в хирургической, а вот на кухне или в столовой добиваться хирургической чистоты это безумие.

Вот теперь абсолютно с тобой согласен. Только заметь, как далеко мы с тобой ушли от "говнокода".

Здравствуйте, ry, Вы писали:

ry>Здравствуйте, Testator, Вы писали:


IT>>>Для начала хорошо бы определить критерии хорошего качественного кода.

T>>Все просто, вот минимальные необходимые требования:
T>>- Наличие единообразного стиля (соглашение о наименованиях, форматировании конструкций, модулей).
T>>- Единообразие проектных подходов, наличие одинаковых узнаваемых паттернов на большинство решаемых кодом задач. То есть не должно быть так что в разных частях кода одна и та же задача решается разными способами.
ry>Эти требования засовываются во внутрифирменные стандарты.

Бывает кстати внутрифирменные стандарты применяются с таким безумным фанатизмом, что в итоге получается бестолковый монстр, который использовать невозможно. По мне главное чтоб какой-то стиль вообще был, общий для всего кода.

T>>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.
ry>А эти в ТЗ неплохо укладываются, если, конечно, заказчик согласится.

Если хотя бы что-то из того что выше упущено, код получается говно, т.е. некачественный И не важно куда чего там засовывается или укладывается. Заказчик он как пациент в больнице. Слушать его жалобы конечно надо, но принимать решения все равно должен лечащий врач

Здравствуйте, Testator, Вы писали:

T>Бывает кстати внутрифирменные стандарты применяются с таким безумным фанатизмом, что в итоге получается бестолковый монстр, который использовать невозможно. По мне главное чтоб какой-то стиль вообще был, общий для всего кода.
Это проблемы менеджмента, но я не встречал особого фанатизма, скорее, наоборот.

T>>>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.
ry>>А эти в ТЗ неплохо укладываются, если, конечно, заказчик согласится.

T>Если хотя бы что-то из того что выше упущено, код получается говно, т.е. некачественный И не важно куда чего там засовывается или укладывается. Заказчик он как пациент в больнице. Слушать его жалобы конечно надо, но принимать решения все равно должен лечащий врач
А если больной не в состоянии оплатить то лечение? Ну или не хочет по любой причине: не понимает необходимости или понимает его бесполезность. Тогда подрядчик может это делать за счёт внутренних ресурсов, если оные есть. Либо утереть руки.

Здравствуйте, fin_81, Вы писали:

I>>1. Кривой дизайн/микродизайн (непонятное, много мест для изменения, много сущностей и тд)
_>Когда я пришел в новый проект, то этот проект мне казался непонятным, в нем было много мест для изменения, много новых сущностей. В общем я ругался на кривой дизайн. Но когда понял что к чему (прошел месяц-полтора), оказался вполне нормальный проект. Хотя "старики" ругались на некоторую кривизну. Где правда?

Много мест для изменения это достаточно простой признак. Больше — хуже, меньше — лучше. Много сущностей — точно такой же признак. Понятно-непонятно это с учетом целевой аудитории(команда/организация и тд). Всем понятно — хорошо. Не всем — плохо. Опять таки все просто.

I>>2. Дублирование (в любом виде: от строчек, функций, классов до параллельных механизков вроде трёх версий контроллера ) ACHTUNG !
_>Копирование кусков кода с похожих решений считается. Доводить код до состояния реюзабельной библиотеки нет ресурсов.

Поверь, "код не является реюзабельной библиотекой" это ни разу не симптом говнокода.

I>>3. Простыни (длинные файлы/классы/функции/конфиги/имена/цепочки и тд)
I>>4. Высокая вложенность конструкций
I>> а Несколько классов в одном рукописном файле
I>> б уровень вложенности блоков >= 3 ACHTUNG !
I>> в вложенные конструкции вроде сложных запросов linq(на пол-экрана и более)
I>> г несколько операторов в одной строке или одной конструкции, например условие цикла из десятка логический условий
_>3 и 4 пункт — тут надо найти оптимальное решение. Улучшение одного параметра ухудшает другой параметр.

Оптимальное искать надо, но можно избегать вложенности и простыней при этом не будет.

I>>2. Появления кучки странных багов после небольшого фикса ("добавил картинку — пропал грид")
_>Слишком расплывчатая эвристика.

Ну, как есть

I>>3. Комментарии в файле (sic!)
_>Если кратко(?) и по существу(?), а не поздравление с днем рождения, то претензий не имею.

            //       __________________
            // _____/ AddFileToMRUList \___________________________________________________

или

        /// Gets filter string for designs files
        /// </summary>
        /// <returns>The filter string.</returns>
        private string GetDesignFilesFilter()

или

              else{  
                   //Revert cancelled
                   SetCanceled();
                   }

I>>6. Десятки сборок по пять классов на каждую
I>>7. разделение проекта на несколько солюшнов
_>3,4 пункты предыдущей секции.

Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится.

I>>8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка
_>зависит от проекта, с таким же успехом можно сказать msbuild в топку.

Можно. Но это всего лишь симптом. Все эвристики это только симптомы.

I>>9. мануал или т.н. курс молоджого бойца для работы с проектом
_>То есть молодые бойцы должны терроризировать стариков глупыми вопросами и коммитами не совместимыми с жизнью проекта?

Бывает так, что старики пишут нечто понятное только им самим а мануал просто маскирует эту проблему.

_>Не объяснимые "черные ящики" в коде проекта, думаю, это не хорошо. Не все молодые бойцы реверс-инженеры с рождения. Русский язык проще понимается, чем противоречивый синтаксис с семантикой некоторых языков программирования.

А еще мануал вытесняет живое общение.

Здравствуйте, ry, Вы писали:

I>>И если вдруг тебе придется искать аналогии, то далеко ходить не надо — стерильный инструмент используется в хирургической, а вот на кухне или в столовой добиваться хирургической чистоты это безумие.

ry>Вот теперь абсолютно с тобой согласен. Только заметь, как далеко мы с тобой ушли от "говнокода".

Здравствуйте, fin_81, Вы писали:

_>Много мест для изменения — это факт по результатам багфикса, или прогноз для исправления бага (добавления функциональности). Если прогноз, то это тут много вопросов: разобрался ли человек в проблеме, решаема ли задачи для данной архитектуры/дизайна. При этом вопрос кривизны дизайна зависит от того для чего был сделан именно такой дизайн. В общем один субъективизм, нет конкретики.

Для чего ни делай, а большое количество мест для изменений это всегда влечет обилие багов, хочешь ты этого или нет.

>Качество кода — это субъективная характеристика, уровня нравится не нравится. Чем больше человек участвует в создании и оценке кода, тем меньше он нравится этому коллективу. Качество кода можно объективно судить только на основе какого то стандарта. Если нет стандарта, то все оценки субъективны. Кому-то нравится, кому то нет. Если стандарта нет роль стандарта обычно выполняет ведущие программисты или кто-там-еще-стоит-повыше. Полный субъективизм, который сложно распространить на другие проекты.

I>>Оптимальное искать надо, но можно избегать вложенности и простыней при этом не будет.
_>Вложенность => 3: проект-модуль-файл — предел вложенности исчерпан. Все проекты плохие. А солюшены подавно.

Ага.

I>>

I>>            //       __________________
I>>            // _____/ AddFileToMRUList \___________________________________________________
I>>

_>Красиво, мне нравится.

Пользуйся, а я по возможности такое вычищаю, потому что этот комент затрудняет чтение деталей

I>>или

I>>

I>>        /// Gets filter string for designs files
I>>        /// </summary>
I>>        /// <returns>The filter string.</returns>
I>>        private string GetDesignFilesFilter()
I>>

_>Возможно такие требования — обязательный комментарий для автодокументирования. Иначе метод не попадет в документацию и никто не узнает о его существовании.

Это мусор и он затрудняет чтение кода.


I>> else{
I>> //Revert cancelled
I>> SetCanceled();
I>> }
I>>[/ccode]
_>Нормально, главное чтоб комментарий и выполняемые действия не противоречили друг другу.

Это лишний комментарий, ничего нового он не говорит и затрудняет чтение

I>>Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится.
_>Тут много вопросов: сперва надо узнат почему так разделили, может это специально сделано, чтоб любители рефакторить не поломали/испортили чужой код, в котором он не разбирается.

Спасибо, К.О. И при всем этом рефакторинг как правило не проводится должным образом, такие вот наблюдения.

I>>Можно. Но это всего лишь симптом. Все эвристики это только симптомы.
_>Тогда почему такие конкретно идиоматические приставки к вполне хорошим инструментам. То есть эвристики еэто субъективность в квадрате.

Приставки потому что инструменты эти мне не нравятся, т.к. они большей частью применяются неправильно маскируют проблему.

I>>Бывает так, что старики пишут нечто понятное только им самим а мануал просто маскирует эту проблему.
_>А как же первый пункт про понятность дизайна.

Цитирую себя "Понятно-непонятно это с учетом целевой аудитории(команда/организация и тд). Всем понятно — хорошо. Не всем — плохо."

_>>>Не объяснимые "черные ящики" в коде проекта, думаю, это не хорошо. Не все молодые бойцы реверс-инженеры с рождения. Русский язык проще понимается, чем противоречивый синтаксис с семантикой некоторых языков программирования.

I>>А еще мануал вытесняет живое общение.
_>Субъективизм в кубе. Дефицит общения вне рабочее время?

Общение по проекту. Это не субъективно, это факт — если проблемы не обсуждаются, они чаще всего никогда и не решаются.

_>Не все хорошо импровизируют, проще читать по бумажке, объясняя непонятные моменты.

Проще, в ущерб эффективности.

_>Повторюсь, нет смысла говорить качестве кода при отсутствии стандартов (общепринятых принципов)

Бред, с таким подходом эти самые стандарты и принципы никогда не появятся.

Здравствуйте, LaptevVV, Вы писали:

LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Когда я сейчас пишу свой код, то я знаю, что через полгода я скажу что этот код — *гуан. Потому так и есть, просто я сейчас еще не знаю что в нем не так.

Я вижу страшный код на работе, но это мне наверное не повезло.

Я видел хороший код в опенсурсе, например в LLVM.
В то же время в опенсурсе есть очень сомнительный код, например в Lua, с кучей макросов и однобуквенными переменными.

Здравствуйте, Ikemefula, Вы писали:

_>>Повторюсь, нет смысла говорить качестве кода при отсутствии стандартов (общепринятых принципов)

I>Бред, с таким подходом эти самые стандарты и принципы никогда не появятся.

Общепринятых принципов нет, потому что они решают проблему только в пределах одного проекта. В другом проекте эти "принципы" не помогут, чаще портят. Одним нужна скорость в килостроках в минуту, другим — математическая доказанность. У одних код — это заодно и документация, у других код — это интерпретация формул в строгого доказательства какой-то теоремы. Для большинства код это средство для создания продукта. И качество кода — это один из параметров для получения какого-то профита в виде денег или в виде общественного признания, и редко как способ показать как качественно (по разумению кодера) пишется код.

Здравствуйте, Dym On, Вы писали:

DO>Прекрасный код это код, который пишу я в текущий момент, все остальное — отстой, включая мой код, который я писал вчера .

Прекрасный код — это код, который ты напишешь завтра.

Здравствуйте, Testator, Вы писали:
T>... Заказчик он как пациент в больнице. Слушать его жалобы конечно надо, но принимать решения все равно должен лечащий врач

У Стаута хорошее место есть: "Фред настаивал, что имеет право знать, какова дальнейшая программа и участвовать в обсуждении плана действий, но в конце концов был вынужден согласиться с Вулфом, что, нанимая специалиста, человек сохраняет за собой единственное право — уволить его".

Vi2>Прекрасный код — это код, который ты напишешь завтра.
Завтра я напишу совершенный код .

Здравствуйте, LaptevVV, Вы писали:

LVV>Я довольно давно на РСДН.
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
LVV>Как правило, посты следующего содержания:
LVV>

LVV>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.

LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
LVV>Кто может привести примеры прекрасного качества кода?
LVV>Из жизни, а не из книжек.

Используем опенсорс библиотеку, качество кода — посредственное (хотя не совсем так, но долго расказывать). Переходим на новую(аналог) сейчас, качество кода — выше всяких похвал. Хотя она более низкоуровневая (простите за коламбур), но удивительно стройная и логичная, у авторов — многому можно поучится(область voip). Еще использую stl, boost — тут на любителя. Мне например asio, multi_index, spirit — нравятся, но порог вхождения — не низок. soci — не все нравится. google::bufproto — очень не плоха. Для клиента юзаем .net. Сейчас делаем на qt(для линуха и мака), очень нравится.

Нет, много хорошего кода, и в опенсорсе, и в МС, и в другом. Только мне ваш вопрос, напомнил о моей "проблемме" — все время рефакторю код, и не потому что он плох, он работает, и за год, ни одного бага, но рефакторю из любви к красивому, и тут нать, баги ... Как от этой привычки избавиться?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

I>>>7. разделение проекта на несколько солюшнов
I>>>8. наличие мега-тулов для сборки, вроде антов-нантов, говномавенов и прочей дури, многоступенчатая сборка

B>>после этих пунктов возникают серьёзные сомнения, что кроме лабы в институте автор этих строк написал хоть что-то.

I>Скажи честно, ты где то увидел у меня нечто вроде "разделение проекта на несколько солюшнов есть необходимый и достаточное условие говнокода" ?
ессно, что ты не называл это "необхожимым и достаточным", но зачем же ты перечислил эти пункты?
оособенно радуют анты-нанты — это пять.

I>Твой скептицизм выдаёт с головой неумение решать задачи диагностики.
конечно, ты угадал.

Здравствуйте, Ikemefula,

I>А еще мануал вытесняет живое общение.
а как же распределённые команды?
ждать в Саратове, пока проснётся НЙ?

I>>>Неужели гит может заставить тебя на ровном месте вносить изменения в код ?

M>>Нет конечно. Просто с гитом эти изменения можно легко и быстро заливать куда угодно. Шустрый он зараза.

I>То есть, ожидаемые, то есть, разумные, границы для гита будут повыше ? Правильно ?


Да. Естественно, если на один файл на продакшне 1000 изменений в день типа «ой, поправил запятую», то гнать программиста с таким кодом взашей Это если утрируя, конечно.

Здравствуйте, Testator, Вы писали:

T>- Наличие единообразного стиля (соглашение о наименованиях, форматировании конструкций, модулей).
T>- Единообразие проектных подходов, наличие одинаковых узнаваемых паттернов на большинство решаемых кодом задач. То есть не должно быть так что в разных частях кода одна и та же задача решается разными способами.
T>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.

Единообразие это хорошо, если в меру. Но говорит это лишь о единообразности, а не о качестве

Здравствуйте, ry, Вы писали:

ry>Я могу. Рассказать. Не показать.
ry> На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.

Это скорее тот самый случай, когда не "благодаря", а "вопреки". Эволюция — штука забавная.

Здравствуйте, landerhigh, Вы писали:

ry>> На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.

L>Это скорее тот самый случай, когда не "благодаря", а "вопреки".

Не очень понимаю, почему вопреки. Если посмотреть на код любой функции, файла, компоненты, то, конечно, эстет иногда может и ужаснуться от качества кода. При том, что откровенное дерьмо туда не попадёт — принятый процесс разработки не допустит этого. Но если посмотреть на код целиком, то есть увидеть за ним архитектуру и оценить управление этим кодом (то есть посмотреть на код, архитектуру и управление совместно), то это не может не вызвать восхищения.

L>Эволюция — штука забавная.
А эволюция? Я давно уже не видел моторольских продуктов. И осталось ли в их коде хоть что-то от Р2К платформы

Здравствуйте, Vlad_SP, Вы писали:

V_S>Здравствуйте, Ikemefula, Вы писали:

I>>Очень мало контор уделяет внимание качеству кода.

V_S>И это правильно. Клиент платит за продукт, решающий его проблемы, а не за мифическое "качество кода". Поэтому качество кода и находится на соответствующем месте в иерархии ценностей компании... что тут удивительного?
V_S>Есть, безусловно, некоторое количество компаний, которые продают исходники. Вот тут "качеству кода" уделяется внимание, — ну, так этот код и есть их продаваемый продукт. Нет?
Z не про клиентов. Я о программистах и программах. Качество кода важно при разработке.
Чем лучше код, тем проще работать...

Здравствуйте, LaptevVV, Вы писали:

LVV>Я о программистах и программах. Качество кода важно при разработке. Чем лучше код, тем проще работать...

Это верно. Однако — если говорить о сферической разработке в вакууме, когда сам процесс разработки и есть самоцель. В реальности же над программистами стоят менеджеры, у которых цель — выпустить продукт, за который клиенты заплатят деньги, в условиях жестко ограниченных сроков и бюджета, и еще более жестко ограниченных человеческих ресурсов...

Здравствуйте, pzhy, Вы писали:

P>Используем опенсорс библиотеку, качество кода — посредственное (хотя не совсем так, но долго расказывать). Переходим на новую(аналог) сейчас, качество кода — выше всяких похвал. Хотя она более низкоуровневая (простите за коламбур), но удивительно стройная и логичная, у авторов — многому можно поучится(область voip).

Чорд (tm). Надеюсь, Вы не про беспомощный osip?

P>Нет, много хорошего кода, и в опенсорсе, и в МС, и в другом. Только мне ваш вопрос, напомнил о моей "проблемме" — все время рефакторю код, и не потому что он плох, он работает, и за год, ни одного бага, но рефакторю из любви к красивому, и тут нать, баги ... Как от этой привычки избавиться?

Ничего не понял. Расшифруйте.

Здравствуйте, Abyx, Вы писали:

A>Когда я сейчас пишу свой код, то я знаю, что через полгода я скажу что этот код — *гуан. Потому так и есть, просто я сейчас еще не знаю что в нем не так.

Ну дык ёлы-палы, братуха (tm)

A>Я вижу страшный код на работе, но это мне наверное не повезло.
A>Я видел хороший код в опенсурсе, например в LLVM.

Только собирается он доооолго.

A>В то же время в опенсурсе есть очень сомнительный код, например в Lua, с кучей макросов и однобуквенными переменными.

Если речь про код самого интерпретатора, то там уже область применения весьма специфическая и писать в таком стиле полезнее, чем разворачиваться походным маршем колонной по три мысью по древу.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Testator, Вы писали:

T>>- Наличие единообразного стиля (соглашение о наименованиях, форматировании конструкций, модулей).
T>>- Единообразие проектных подходов, наличие одинаковых узнаваемых паттернов на большинство решаемых кодом задач. То есть не должно быть так что в разных частях кода одна и та же задача решается разными способами.
T>>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.

IT>Единообразие это хорошо, если в меру. Но говорит это лишь о единообразности, а не о качестве

А я и не писал о достаточных условиях, только о необходимых. Вот к как контр-пример типичные признаки говнокода:
— В проекте используется куча разных нотаций. Названия переменных, функций, классов ни о чем не говорят, их друг от друга не отличить.
— В каждом подпроекте своя реализация примитивов всяких строк, контейнеров. Повсеместный копипаст с минимальными заплатками. Изменение/добавление фичи требует перелопачивания кучи файлов.
— Проект делается под узкие текущие требования. При любом изменении в них проще переделать все заново чем пытаться перекроить тонны спагетти.

Здравствуйте, fin_81, Вы писали:

_> Качество кода можно объективно судить только на основе какого то стандарта. Если нет стандарта, то все оценки субъективны.

Тут мыщьх сослался на стандарт, в котором все показатели оцениваются экспертами. То есть в принципе это субъективно. Но практика показывает, что таки эксперты со стажем могут иметь существенные различия в отдельных частностях, но в общем очень неплохо сходятся. Иначе бы вообще не было общего подхода;)

_> Полный субъективизм, который сложно распространить на другие проекты.

Таки практика показывает, что адекватно распространяется.

I>>Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится.
_>Тут много вопросов: сперва надо узнат почему так разделили, может это специально сделано, чтоб любители рефакторить не поломали/испортили чужой код, в котором он не разбирается.

Вот это некорректно. Чтобы "любители рефакторить" ничего не поломали, придуманы тесты. Это касается и посторонних, и автора текущего кода: во всём одновременно разбираться таки невозможно. А если есть способ проверить корректность результата после своего изменения, то нет проблемы в чужом вмешательстве, если этот чужой зачем-то развивает код, а не просто ерунду творит.

Здравствуйте, Privalov, Вы писали:

P>Наследование a-la Sheridan и некоторые другие мелочи.

это как?
давай детали!

Здравствуйте, blackhearted, Вы писали:

B>>>после этих пунктов возникают серьёзные сомнения, что кроме лабы в институте автор этих строк написал хоть что-то.

I>>Скажи честно, ты где то увидел у меня нечто вроде "разделение проекта на несколько солюшнов есть необходимый и достаточное условие говнокода" ?
B>ессно, что ты не называл это "необхожимым и достаточным", но зачем же ты перечислил эти пункты?

Не поверишь, потому что они являются симптомами. Например если в файл за год у тебя сто коммитов, в ём полно каментов, при этом сам файл зависит от сборки которая в другом солюшне который подкомпиливается нантом, то уверяю — в этом файле 100%-ный говнокод !

Здравствуйте, Mamut, Вы писали:

I>>То есть, ожидаемые, то есть, разумные, границы для гита будут повыше ? Правильно ?

M>Да. Естественно, если на один файл на продакшне 1000 изменений в день типа «ой, поправил запятую», то гнать программиста с таким кодом взашей Это если утрируя, конечно.

Гнать взашей это как минимум !

Здравствуйте, Ikemefula, Вы писали:

I>Есть варианты :
I>1 сделать билд в один шаг, т.е. удалённый разраб скачивает код, запускает сборку хоткеем в IDE и работает
I>2 обложить костылями (говнанты,гономавены) и тд. Вот типичный расклад в этом случае http://rsdn.ru/forum/humour/2651979.1.aspx

Автор: --
Дата: 11.09.07

Непонятно, почему ты эту ситуацию пытаешься связать с "костылями" в виде Ant, Maven. По-моему, ничего общего в проблематике.
Сама по себе ситуация подобного рода типична, вопрос в том, как её лечить. С нашим текущим подходом в этом случае было бы следующее: по результатам такого взлёта девелопер должен был бы 1) оформить подробный лог такого взлёта, 2) создать тикет с ним, 3) ссылку на тикет запихнуть во внутреннее Wiki в соответствующую секцию (если нет, создать). Вероятнее всего, в этом случае старший девелопер сказал бы "раз так, опиши это не в виде лога, а в виде HOWTO, в вики в настройке рабочей среды" и по крайней мере проблема была бы документирована и известен шаг решения; а ещё вероятно исправление — не сразу, но постепенно, по мере нахождения сил на это.

I>3 написать мануал, после пары месяцев все сведётся к п.2 с той разницей, что мануал будет устаревшим и времени будет уходить больше чем в п.2

Непонятно, что ты имеешь в виду под мануалом, но всё-таки рабочая обстановка должна создаваться полностью автоматизированно, а все другие варианты — только промежуточные перед этим.

Здравствуйте, neFormal, Вы писали:

F>Или так: код, который не совершает следующих грехов:

F>Гордыня — код понятен даже джуниору (если он понял задачу)
F>Зависть — код не дублирует уже существующий код
F>Чревоугодие — код не пожирает все возможные ресурсы себе в угоду
F>Блуд — код не содержит бессмысленных конструкций просто ради кода
F>Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать
F>Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль
F>Уныние — код написан не на выброс

Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?

Здравствуйте, neFormal, Вы писали:

P>>Наследование a-la Sheridan и некоторые другие мелочи.

F>это как?
F>давай детали!

Шеридан тут жог глаголом и показал образец, где всё наследовалось от всего

Здравствуйте, fin_81, Вы писали:

I>>Бред, с таким подходом эти самые стандарты и принципы никогда не появятся.

_>Общепринятых принципов нет, потому что они решают проблему только в пределах одного проекта. В другом проекте эти "принципы" не помогут, чаще портят. Одним нужна скорость в килостроках в минуту, другим — математическая доказанность. У одних код — это заодно и документация, у других код — это интерпретация формул в строгого доказательства какой-то теоремы. Для большинства код это средство для создания продукта. И качество кода — это один из параметров для получения какого-то профита в виде денег или в виде общественного признания, и редко как способ показать как качественно (по разумению кодера) пишется код.

То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов.

Здравствуйте, Ikemefula, Вы писали:

F>>Гордыня — код понятен даже джуниору (если он понял задачу)
F>>Зависть — код не дублирует уже существующий код
F>>Чревоугодие — код не пожирает все возможные ресурсы себе в угоду
F>>Блуд — код не содержит бессмысленных конструкций просто ради кода
F>>Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать
F>>Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль
F>>Уныние — код написан не на выброс

I>Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?

справа их описание..
лично для тебя:
Гордыня — не усложнять без надобности
Зависть — не дублировать существующий код/функционал
Чревоугодие — следить за расходом ресурсов
Блуд — не словоблудствовать, писать достаточно кратко
Гнев — думать о том, кто это будет использовать/поддерживать, а не ненавидеть его заранее
Алчность — не тащить весь доступный функционал в каждый(или единственный) модуль, сокращать зависимости
Уныние — не писать на выброс

Здравствуйте, neFormal, Вы писали:

F>это как?
F>давай детали!

Собственно, вот

Автор: Sheridan
Дата: 31.03.11

. Жаль, картинка почему-то не открывается.

Здравствуйте, netch80, Вы писали:

N>Непонятно, почему ты эту ситуацию пытаешься связать с "костылями" в виде Ant, Maven. По-моему, ничего общего в проблематике.
N>Сама по себе ситуация подобного рода типична, вопрос в том, как её лечить. С нашим текущим подходом в этом случае было бы следующее: по результатам такого взлёта девелопер должен был бы 1) оформить подробный лог такого взлёта, 2) создать тикет с ним, 3) ссылку на тикет запихнуть во внутреннее Wiki в соответствующую секцию (если нет, создать). Вероятнее всего, в этом случае старший девелопер сказал бы "раз так, опиши это не в виде лога, а в виде HOWTO, в вики в настройке рабочей среды" и по крайней мере проблема была бы документирована и известен шаг решения; а ещё вероятно исправление — не сразу, но постепенно, по мере нахождения сил на это.

I>>3 написать мануал, после пары месяцев все сведётся к п.2 с той разницей, что мануал будет устаревшим и времени будет уходить больше чем в п.2

N>Непонятно, что ты имеешь в виду под мануалом, но всё-таки рабочая обстановка должна создаваться полностью автоматизированно, а все другие варианты — только промежуточные перед этим.

Если рабочая обстановка автоматизирована, то не ясно, зачем нужно описывать HOWTO , секции в WIKI и документировать проблемы

Здравствуйте, netch80, Вы писали:

N>Мнэээ... то есть надо не совершать ни один из этих грехов, а именно:
N>* усложнять без надобности
N>* дублировать код и функционал
N>* игнорировать траты ресурсов
N>* писать развесисто и бессмысленно
N>* игнорировать, ненавидеть и презирать пользователя
N>* развешивать зависимости
N>* писать так, чтобы нельзя было развивать

N>Я правильно понял?

да, всё верно

N>Или всё-таки надо совершать все эти грехи?

ну, если очень хочется

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, Ikemefula, Вы писали:

F>>>Гордыня — код понятен даже джуниору (если он понял задачу)
F>>>Зависть — код не дублирует уже существующий код
F>>>Чревоугодие — код не пожирает все возможные ресурсы себе в угоду
F>>>Блуд — код не содержит бессмысленных конструкций просто ради кода
F>>>Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать
F>>>Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль
F>>>Уныние — код написан не на выброс

I>>Чет я не понял формулы. Слева грехи а справа их описание или же справа описано как не совершать эти грехи ?

F>справа их описание..

Если справа описание, то не ясно, как грехом может считаться например код который не пожирает все возможные ресурсы себе в угоду

F>лично для тебя:

Я поправил:

F>Гордыня — усложнять без надобности
F>Зависть — дублировать существующий код/функционал
F>Чревоугодие — распылять все доступные ресурсы ресурсов
F>Блуд — словоблудствовать, писать невнятно, пространно
F>Гнев — заранее ненавидеть того кто будет использовать код
F>Алчность — тащить весь доступный функционал в каждый модуль, плодить зависимости
F>Уныние — код на выброс

Здравствуйте, Ikemefula, Вы писали:

I>Я поправил:

— Не вари козлёнка в молоке матери его…
— Подожди-ка… А, я понял! Это значит: «Не ешь мясное вместе с молочным?»
— Да ты пиши, что я тебе говорю: «Не вари козлёнка в молоке…»
— Ага, теперь я догадался! Надо иметь отдельную посуду для мяса и молока.
— Послушай, что ты несёшь? Я же тебе ясно сказал: «Не вари козлёнка…»
— Всё, ну, теперь я, наконец, всё понял! После мясного, прежде чем есть молочное, надо подождать шесть часов…
— Да делайте, что хотите!!

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, fin_81, Вы писали:

_>> Качество кода можно объективно судить только на основе какого то стандарта. Если нет стандарта, то все оценки субъективны.
N>Тут мыщьх сослался на стандарт, в котором все показатели оцениваются экспертами. То есть в принципе это субъективно. Но практика показывает, что таки эксперты со стажем могут иметь существенные различия в отдельных частностях, но в общем очень неплохо сходятся. Иначе бы вообще не было общего подхода
Субъективизм кончается там, где невозможно написать по другому: синтаксис языка, статический анализ кода, "предупреждения компилятора как ошибки". Если возможно, почему нельзя написать так как хочется, зачем мне думать про мифическое качество кода? Качество кода — это из разряда преждевременной оптимизации. А вот _стандарты_ качества — это уже предметный разговор. А есть ли стандарты качества кода?

_>> Полный субъективизм, который сложно распространить на другие проекты.
N>Таки практика показывает, что адекватно распространяется.
"Адекватно" — это субъективный термин. Участвовал в трех разных проектах во всех проектах разный стиль кодирования, проекты приносили "адекватный" доход предприятию (и мне) и имели "адекватный" по качеству код, который по началу вводил в ступор своей "непонятной безобразностью". Месяц-полтора и код уже вполне "адекватный" по качеству.

Самый качественный код который писал это самая первая моя строка — рисование круга по центру экрана на бейсике zx-spectrum. Это был шедевр, потому что я боялся того, что компьютер взорвется если я нарисую круг, который вылезет за границы экрана. Я читал два дня документацию на импортном языке, чтобы узнать разрешение экрана, координаты центра и радиус круга который влезет на экран. Это и есть Качество кода, когда у тебя есть время для изучения проблемы, ты можешь предварительно промоделировать все граничные условия не на продакшн коде. Не всегда есть время для этого, суровый рынок не терпит трусов, которые боятся писать некачественный код.

I>>>Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится.
_>>Тут много вопросов: сперва надо узнат почему так разделили, может это специально сделано, чтоб любители рефакторить не поломали/испортили чужой код, в котором он не разбирается.

N>Вот это некорректно. Чтобы "любители рефакторить" ничего не поломали, придуманы тесты. Это касается и посторонних, и автора текущего кода: во всём одновременно разбираться таки невозможно. А если есть способ проверить корректность результата после своего изменения, то нет проблемы в чужом вмешательстве, если этот чужой зачем-то развивает код, а не просто ерунду творит.

Тесты придуманы не для "любителей рефакторить", тесты придуманы для того чтобы контролировать качество продукта, для того чтобы контролировать способность удовлетворять требованиям пользователя. Тесты плоско-параллельны к качеству кода который как бы улучшается в результате переделывания. Если меняется чужой участок кода путем рефакторинга, то думаю понимание кода не улучшается. И разделение на задачи, решения и прочие модули — это способ разделения/распараллеливания сложной задачи, где важное значение имеет невмешательство в чужой код. Тут уже проблемы не качества кода, а адекватности архитектуры и процесса совместной разработки. Стандарты качества кода — это скорее всего следствия процесса разработки. Пока единства процессов разработки не заметно, каждый день придумывают всякие агилы, тдд и рупы и тп. И каждый пытается доказать что его процесс самый "адекватный и качественный".

Здравствуйте, Ikemefula, Вы писали:

I>То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов.
Раз нет единых стандартов качества кода, то про абсолют качества говорить сложно. Все зависит от обстоятельств.
У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?

Здравствуйте, fin_81, Вы писали:

I>>То есть, правильно я тебя понял, говорить про качетсво нельзя в принципе ? Ни принципов, ни стандартов.
_>Раз нет единых стандартов качества кода, то про абсолют качества говорить сложно. Все зависит от обстоятельств.

Интересно, а как же появились стандарты да еще в те времена когда не было стандартов и говорить про какие то абсолюты было сложно ?

_>У нужны ли стандарты качества кода? Какие проблемы они решают кроме субъективно-эстетических?

Например финансовые. Если ты наговнокодил, в следующей версии к N часам на фичи надо добавить M (M ~ N) часов на исправление твоего говнокода, что бы фичи стали хотя бы теоретически реализуемыми.