Я довольно давно на РСДН.
И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода.
Как правило, посты следующего содержания:
Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.
Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
Кто может привести примеры прекрасного качества кода?
Из жизни, а не из книжек.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
, по крайней мере.
LVV>Кто может привести примеры прекрасного качества кода? LVV>Из жизни, а не из книжек.
Давно было, код не сохранился. Но представь себе код на древнем Basic, где нет ни одной строчки спагетти. Я к тому проекту на заключительных этапах присоединился, и в одиночку пару лет потом поддерживал.
Здравствуйте, LaptevVV, Вы писали:
LVV>Я довольно давно на РСДН. LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода. LVV>Как правило, посты следующего содержания: LVV>
LVV>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.
LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы... :)
А зачем рассказывать про хороший код?
Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует.
LVV>Кто может привести примеры прекрасного качества кода? LVV>Из жизни, а не из книжек.
Я могу их из своей практики привести хоть тысячу, но не вижу смысла. Во-первых, что это прекрасный код — то есть выполняет ровно свою задачу, чёток, понятен и пригоден к развитию — пойму только я и коллеги, остальные в лучшем случае пожмут плечами. Во-вторых, он соседствует в одном и том же проекте с кошмарами, которые нельзя выбросить только потому, что они доведены до достаточно рабочего состояния. В-третьих, такой код часто требовал больше усилий, чем надо бы (есть у меня в подчинённых, например, перфекционист, который никогда не может выдержать сроки).
Так что я (повторюсь) устроил бы тут голосование. Дать пяток уровней качества — от кошмара до идеала — и вопрос типа "то с чем вы работаете сейчас — к чему ближе?"
Здравствуйте, netch80, Вы писали:
N>А зачем рассказывать про хороший код? N>Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует.
Требует!
Ведь именно так рассуждают журналисты! Поэтому по ТВ — одна чернуха. Как говорил Задорнов: наши новости можно смотреть только под водку и не чокаясь!
Хороший код — это пример для новичков — нужно его показывать! LVV>>Кто может привести примеры прекрасного качества кода? LVV>>Из жизни, а не из книжек. N>Я могу их из своей практики привести хоть тысячу, но не вижу смысла. Во-первых, что это прекрасный код — то есть выполняет ровно свою задачу, чёток, понятен и пригоден к развитию — пойму только я и коллеги, остальные в лучшем случае пожмут плечами. Во-вторых, он соседствует в одном и том же проекте с кошмарами, которые нельзя выбросить только потому, что они доведены до достаточно рабочего состояния. В-третьих, такой код часто требовал больше усилий, чем надо бы (есть у меня в подчинённых, например, перфекционист, который никогда не может выдержать сроки).
1. Ну, можно ведь не просто код, а небольшие пояснения дать, и объяснить в чем красота. А иначе КАК учиться хорошему кодированию?
2. Не выдерживание сроков может говорить о том, что сроки просто занижены. Расчитаны на написание быдлокода, а не качественного кода. И никто об этом не задумывается. N>Так что я (повторюсь) устроил бы тут голосование. Дать пяток уровней качества — от кошмара до идеала — и вопрос типа "то с чем вы работаете сейчас — к чему ближе?"
Возможно, но я пока не могу четко сформулировать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода. LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы... LVV>Кто может привести примеры прекрасного качества кода? LVV>Из жизни, а не из книжек.
Я могу. Рассказать. Не показать.
Несколько лет был на поддержке кода пользовательского интерфейса моторольских телефонов. Когда только вообще впервые увидел моторольский код, ужаснулся, но не от качества (что я понимал тогда в этом), а от его объёма — и понял, какой же фигнёй занимался до этого. И только ленивый не ругался на его качество. То ли под воздействием таких разговоров, то ли в силу возрастающего профессионализма я стал считать, что могу писать код лучше. Ещё некоторое время спустя я увидел (стал различать), что это не то чтобы плохое качество кода, а заплатка тут, заплатка там, и местами вообще заплата на заплате. Но такова была политика (процесс разработки) Моторолы. На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.
Здравствуйте, LaptevVV, Вы писали:
N>>А зачем рассказывать про хороший код? N>>Для этого есть статистика (кстати, поэтому я рекомендовал бы провести голосование по этому поводу), а обсуждения по делу посвящены проблемам, а не тому, как всё хорошо. Поэтому о плохом говорят, а хорошее такого не требует. LVV>Требует! LVV>Ведь именно так рассуждают журналисты! Поэтому по ТВ — одна чернуха. Как говорил Задорнов: наши новости можно смотреть только под водку и не чокаясь! :) LVV>Хороший код — это пример для новичков — нужно его показывать!
Угу. Но вместе с ТЗ, разве не так? А это уже немного другой уровень рассмотрения.
LVV>1. Ну, можно ведь не просто код, а небольшие пояснения дать, и объяснить в чем красота. А иначе КАК учиться хорошему кодированию? LVV>2. Не выдерживание сроков может говорить о том, что сроки просто занижены. Расчитаны на написание быдлокода, а не качественного кода. И никто об этом не задумывается.
Он сам называл сроки. Ладно, это тема отдельная.
N>>Так что я (повторюсь) устроил бы тут голосование. Дать пяток уровней качества — от кошмара до идеала — и вопрос типа "то с чем вы работаете сейчас — к чему ближе?" LVV>Возможно, но я пока не могу четко сформулировать.
Здравствуйте, LaptevVV, Вы писали:
LVV>Я довольно давно на РСДН. LVV>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода. LVV>Как правило, посты следующего содержания: LVV>
LVV>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.
LVV>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, LaptevVV, Вы писали:
LVV>>Я довольно давно на РСДН. LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода. LVV>>Как правило, посты следующего содержания: LVV>>
LVV>>Перекинули на старый проект... Проект разрабатывали примерно ... человек в разное время, документация есть, но скудная. И главное — это ужасное качество кода.
LVV>>Не верю, что весь код — отстой. Иначе мы тут с вами не сидели бы...
I>Очень мало контор уделяет внимание качеству кода.
А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д. Если качество кода ставится во главу угла, то во-первых, получается процесс ради процесса, а во-вторых, если на входе и есть что-то, то оно настолько сделано через задницу, что использовать его всем кроме автора (или небольшой групп ы авторов) соверешенно невозможно, причем модификацию и поддержку тоже необходимо осуществлять исключительно через задницу.
Здравствуйте, denisko, Вы писали:
I>>Очень мало контор уделяет внимание качеству кода. D>А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д.
Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.
>Если качество кода ставится во главу угла, то во-первых, получается процесс ради процесса, а во-вторых, если на входе и есть что-то, то оно настолько сделано через задницу, что использовать его всем кроме автора (или небольшой групп ы авторов) соверешенно невозможно, причем модификацию и поддержку тоже необходимо осуществлять исключительно через задницу.
"модификацию и поддержку тоже необходимо осуществлять исключительно через задницу" — собственно качество кода и необходимо для устранения этой проблемы
Здравствуйте, Ikemefula, Вы писали:
I>Очень мало контор уделяет внимание качеству кода.
И это правильно. Клиент платит за продукт, решающий его проблемы, а не за мифическое "качество кода". Поэтому качество кода и находится на соответствующем месте в иерархии ценностей компании... что тут удивительного?
Есть, безусловно, некоторое количество компаний, которые продают исходники. Вот тут "качеству кода" уделяется внимание, — ну, так этот код и есть их продаваемый продукт. Нет?
Здравствуйте, ry, Вы писали:
ry>Несколько лет был на поддержке кода пользовательского интерфейса моторольских телефонов. Когда только вообще впервые увидел моторольский код, ужаснулся, но не от качества (что я понимал тогда в этом), а от его объёма — и понял, какой же фигнёй занимался до этого. И только ленивый не ругался на его качество. То ли под воздействием таких разговоров, то ли в силу возрастающего профессионализма я стал считать, что могу писать код лучше. Ещё некоторое время спустя я увидел (стал различать), что это не то чтобы плохое качество кода, а заплатка тут, заплатка там, и местами вообще заплата на заплате. Но такова была политика (процесс разработки) Моторолы. На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.
Ага, продавался пока не сдулся. Я всегда думал, что у моторолы вакханалия в коде, но теперь это можно сказать подтвердилось.
Похоже, все фичи они имплементили посредтсвом изучения, что позволяет код, а что нет Про пользователя думать было некогда
Здравствуйте, Vlad_SP, Вы писали:
I>>Очень мало контор уделяет внимание качеству кода.
V_S>И это правильно. Клиент платит за продукт, решающий его проблемы, а не за мифическое "качество кода". Поэтому качество кода и находится на соответствующем месте в иерархии ценностей компании... что тут удивительного?
Клиент как правило не в курсе, что качество кода может быть разным или, как минимум, не понимает насколько это важно.
V_S>Есть, безусловно, некоторое количество компаний, которые продают исходники. Вот тут "качеству кода" уделяется внимание, — ну, так этот код и есть их продаваемый продукт. Нет?
Нет. Стоимость последующих изменений напрямую зависит от качетсва кода. Я занимался несколькими длинными проектами, которые пришлось буквально воскрешать.
Все такие проекты останавливаются в основном из за того, что стоимость изменений становится слишком высокой.
Выход один — вложить кучу денег и начать новый проект или вложить кучу денег и воскресить.
Качество кода позволяет увеличить цикл жизни кода — внимание — в разы за счет снижения стоимости разработки.
Теперь вопрос — является ли стоимость изменения критичной для клиента который платит за продукт решающий его проблемы ?
Здравствуйте, 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
Как правило, разница между А и Б настолько велика, что окупает усилия по улучшению кода.
Единственный нюанс, это выбор момента, когда нужно улучшать код Одноразовый код однозначно улучшать не стоит. Код в который придется лазить постоянно, улучшать нужно постоянно.
Здравствуйте, Ikemefula, Вы писали:
I>>>Очень мало контор уделяет внимание качеству кода. D>>А вот интересно, нужно ли оно вообще? По-моему опыту, дольше всего живут и лучше всего модифицируются приложения написанные довольно аккуратно, но _без_ излишнего внимания к качеству кода, реюзабельности, оопшности и.т.д.
I>Аккуратно это как ? Устраняешь дублирование и внезапно получается не только реюзабельность, но оопшность и функциональщина.
А потом просят добавить новые фичи, но только в одну из веток. В результате возникают флажки, виртуальные функции, а конце скрещивание ежа и ужа.
Про пользователя думать было некогда 
Одноразовый код однозначно улучшать не стоит. Код в который придется лазить постоянно, улучшать нужно постоянно.
