Здравствуйте, 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>Твой скептицизм выдаёт с головой неумение решать задачи диагностики.
конечно, ты угадал.
I>>>Неужели гит может заставить тебя на ровном месте вносить изменения в код ?
M>>Нет конечно. Просто с гитом эти изменения можно легко и быстро заливать куда угодно. Шустрый он зараза.
I>То есть, ожидаемые, то есть, разумные, границы для гита будут повыше ? Правильно ?
Да. Естественно, если на один файл на продакшне 1000 изменений в день типа «ой, поправил запятую», то гнать программиста с таким кодом взашей Это если утрируя, конечно.
Здравствуйте, Testator, Вы писали:
T>- Наличие единообразного стиля (соглашение о наименованиях, форматировании конструкций, модулей). T>- Единообразие проектных подходов, наличие одинаковых узнаваемых паттернов на большинство решаемых кодом задач. То есть не должно быть так что в разных частях кода одна и та же задача решается разными способами. T>- Масштабируемость, учитывающая большинство вероятных направлений развития. Добавление новых возможностей, которые по логике запланированы на будущее, не должно стремиться по сложности к бесконечности.
Единообразие это хорошо, если в меру. Но говорит это лишь о единообразности, а не о качестве
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
LVV>Кто может привести примеры прекрасного качества кода?
курим ГОСТ 28195–99. кстати, международный. а еще есть гост на качество колбасы. все гостировано.
LVV>Из жизни, а не из книжек.
без книжек не получится. без книжек все слишком субъективно. свой код я считаю отстойным, но у коллег он нареканий не вызывает. вот и определи -- говно это или мармелад в шоколаде.
кстати, учиться по книжкам и чужому коду -- плохая идея ИМХО. у меня код нашпигован глобальными переменными, но от этого он только выигрывает, т.к. глобальные переменные используются так, что решают больше проблем, чем создают и любое другое решение (из числа известных) устраняя проблемы, свойственные глобальным переменным, привносит другие.
это я к тому, что руководство "не используйте глобальные переменные" нужно понимать с умом, т.е. пока вы не совсем понимаете, что именно вы делаете и как оно работает, то, действительно, от глобальных переменных лучше воздержаться. но... если бы дети слушались родителей, то так бы и ходили в шкурах. так что эксперементировать, нарушая запреты, все-таки полезно. ходи против правил и смотри, что из этого получается.
в этом смысле разглядывание исходников "качественного" кода только вредит. типа, ага! тут и глобальные переменные и даже goto есть!!!
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, ry, Вы писали:
ry>Я могу. Рассказать. Не показать. ry> На моей памяти рефакторинг проводился всего один раз. И только потом я осознал, насколько велико было качество дизайна (архитектуры), кода и управления им и восхитился. Ведь столько лет этот код жил, развивался, поддерживался совместно различными командами из Индии, Америки, Бразилии, России и др. и успешно продавался.
Это скорее тот самый случай, когда не "благодаря", а "вопреки". Эволюция — штука забавная.
Здравствуйте, Dym On, Вы писали:
Vi2>>Прекрасный код — это код, который ты напишешь завтра. DO>Завтра я напишу совершенный код .
Его уже написал Макконнелл.
Здравствуйте, 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>>Основной эффект такого разделения это затруднение рефакторинга. Т.е. устранить дублирование не получится. _>Тут много вопросов: сперва надо узнат почему так разделили, может это специально сделано, чтоб любители рефакторить не поломали/испортили чужой код, в котором он не разбирается.
Вот это некорректно. Чтобы "любители рефакторить" ничего не поломали, придуманы тесты. Это касается и посторонних, и автора текущего кода: во всём одновременно разбираться таки невозможно. А если есть способ проверить корректность результата после своего изменения, то нет проблемы в чужом вмешательстве, если этот чужой зачем-то развивает код, а не просто ерунду творит.
Здравствуйте, IT, Вы писали:
LVV>>И как-то не припомню, чтобы был хоть один пост о хорошем качестве кода. IT>Для начала хорошо бы определить критерии хорошего качественного кода.
1. Единообразие подходов
2. Сложность вхождения не выше сложности задачи
3. Отсутствие ненужной избыточности
Или так: код, который не совершает следующих грехов:
Гордыня — код понятен даже джуниору (если он понял задачу) Зависть — код не дублирует уже существующий код Чревоугодие — код не пожирает все возможные ресурсы себе в угоду Блуд — код не содержит бессмысленных конструкций просто ради кода Гнев — в коде заложено удобство использования, а не ненависть к тем, кто будет поддерживать Алчность — код не тащит весь доступный функционал в каждый(или единственный) модуль Уныние — код написан не на выброс
Здравствуйте, blackhearted, Вы писали:
B>>>после этих пунктов возникают серьёзные сомнения, что кроме лабы в институте автор этих строк написал хоть что-то.
I>>Скажи честно, ты где то увидел у меня нечто вроде "разделение проекта на несколько солюшнов есть необходимый и достаточное условие говнокода" ? B>ессно, что ты не называл это "необхожимым и достаточным", но зачем же ты перечислил эти пункты?
Не поверишь, потому что они являются симптомами. Например если в файл за год у тебя сто коммитов, в ём полно каментов, при этом сам файл зависит от сборки которая в другом солюшне который подкомпиливается нантом, то уверяю — в этом файле 100%-ный говнокод !
Здравствуйте, Mamut, Вы писали:
I>>То есть, ожидаемые, то есть, разумные, границы для гита будут повыше ? Правильно ?
M>Да. Естественно, если на один файл на продакшне 1000 изменений в день типа «ой, поправил запятую», то гнать программиста с таким кодом взашей Это если утрируя, конечно.
Если нам не помогут, то мы тоже никого не пощадим.
.
