Здравствуйте, Аноним, Вы писали:
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.
Это невозможно, потому что нет чётких критериев. Более того, критерии у всех не просто разные, а прямо противоположные. Наверное, потому что программисты люди увлекающиеся, и не могут без крайностей.
Например, в теории простой, понятный, не очень медленный код, который справляется с ошибками чуть лучше, чем нужно заказчику, и имеет некоторый задел на будущее (в плане добавления функциональности), использует общеупотребительные библиотеки вместо собственных или эзотерических, считается хорошим.
Но для многих программистов это будет говнокод. Не отловлены все возможные ошибки и не перехваченные все возможные исключения — говнокод. Не использованы все возможные оптимизации и инструкции процессора — говнокод. Не использована новомодная библиотека или мало шаблонов С++ — говнокод. Слишком много шаблонов С++ — говнокод.
Соответственно, у нас есть два состояния кода.
1. "Это говнокод.".
2. "Это же говнокод. Тут всё надо переписать".
Всё было бы ничего, если бы эта категоричность и нежелание вникнуть в чужие решения, не выливались в переписывание вполне рабочих систем, вместо постепенного улучшения.
Самое крупное переписывание (7-и значные долларовые суммы up to date), которое я видел лично, было вызвано неприятием функционального программирования на шаблонах С++ а ля mpl/Loki. В результате получено менее технологичное решение (без автоматической кодогенерации кода БД по декларативному xml описанию), так к тому же до сих пор и не внедрённое, так что затраты ещё вырастут.
Здравствуйте, 11molniev, Вы писали:
1>На мой взгляд код 7-zip и nginx хороший.
Nginx — образец проблем, которые получаются, если делать всё вручную. Например, большинство директив в файле конфигурации не понимают переменные (нельзя сказать error_log /path/$some_var_depending_on_host/whatever.log) — казалось бы, должен быть некий централизованный механизм, но нет, парсер каждой директивы сам занимается разбором аргументов, причем полностью в ручном режиме, даже без грамматики. Я уверен, что приделать любую новую фичу к nginx — всё равно, что искать иголку в стоге заряженных граблей, нацеленных в ноги (или это не то сравнение?). Один if чего стоит, с миллионом подлых глюков.
А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно. А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
Ну, то что я скажу сильно обидит многих профЭссионалов со светлыми идеалами. ))) И мне это нравится! — Понятие говнокод придумали люди, которые просто не умеют читать чужой код. Да и за частую, таким людям позарез надо хоть чем-то поддерживать своё ЧСВ, а больше как бы и не чем. За очень редким исключением, говнистость определяется лишь несоответствием с некой идеальной картины мира сидящей в голове у конкретного, самого лучшего в мире разраба. Причём зачастую код самого этого разраба этой идеальной картине не соответствует, но конечно же не по вине самого разраба, а лишь по причине непреодолимых обстоятельств.
В общем, то что код 'пахнет', это не характеристика кода, это характеристика того кто 'нюхает'.
RO>Nginx — образец проблем, которые получаются, если делать всё вручную. ... Я уверен, что приделать любую новую фичу к nginx — всё равно, что искать иголку в стоге заряженных граблей, нацеленных в ноги (или это не то сравнение?).
Кстати забавный момент! Из того что популярные продукты, типа того же NGIX'a трактуются как говнокод, ИМХО, есть интересное следствие — идеально сферический код в вакууме нужен разве что такому же идеальному и сферическому разрабу, обитающему ровно в том же вакууме, и польза от такого кода ровно такая же — сферическая. В реальности приносит пользу именно то, что называется у сферического разраба говнокодом. Может таки надо думать о пользе кода, а не о идеальности его формы? ))))
Например преобразование YUV -> RGB написано с ошибками в десяток процентов, работает на порядок медленнее чем аналоги. Выполняет ли он свою функцию ? Да , выполняет. Его подробно не тестировали и использовали в программе конвертере ибо результат был похож на ожидаемый. Ударит ли по качеству ? обязательно ударит , но возможно не сразу.
Но для другого програмиста все эти баги и недоработки будут очевидными , и это однозначно говнокод. И конечно ошибка програмиста в первую очередь в том что он не использовал готовые доступные решения.
M>Например преобразование YUV -> RGB написано с ошибками в десяток процентов, работает на порядок медленнее чем аналоги. Выполняет ли он свою функцию ? Да , выполняет. Его подробно не тестировали и использовали в программе конвертере ибо результат был похож на ожидаемый. Ударит ли по качеству ? обязательно ударит , но возможно не сразу.
Ну тогда говнокод не характеристика а состояние, и зависит не от программиста а от процесса. Собственно любой код кроме не написанного — говнокод, в какой-то момент времени. )))
M>Но для другого програмиста все эти баги и недоработки будут очевидными , и это однозначно говнокод.
Что как бы напрямую зависит от состояния того самого другого программиста.
M>Но мы то говорим о качестве кода. А код в котором явные недоработки и баги сложно назвать качественным,
Хм, а с какого момента код становится качественным? Как бы практически в любом коде можно найти недоработки, и баги. И в любом коде можно найти фатальный недостаток. Так что же весь код тогда говно?
M>>Но мы то говорим о качестве кода. А код в котором явные недоработки и баги сложно назвать качественным,
AS>Хм, а с какого момента код становится качественным? Как бы практически в любом коде можно найти недоработки, и баги. И в любом коде можно найти фатальный недостаток. Так что же весь код тогда говно?
Я говорил про ЯВНЫЕ недоработки и баги, а не те которые надо годами искать. А в целом можно ввести метрику количественную при желании.
Я говорю что вы термины пытаетесь размыть. Таким же образом можно говорить что нет некрасивых и красивых женщин , вкусной и невкусной еды и т.п. Какой в этом смысл ХЗ.
AS>>Хм, а с какого момента код становится качественным? Как бы практически в любом коде можно найти недоработки, и баги. И в любом коде можно найти фатальный недостаток. Так что же весь код тогда говно? M>Я говорил про ЯВНЫЕ недоработки и баги, а не те которые надо годами искать. А в целом можно ввести метрику количественную при желании.
Ну, интересно посмотреть на метрику. Кстати, как это не удивительно, но ЯВНЫЕ баги и недоработки, могут вообще не влиять на качество софта. Тут же ведь вопрос в что это за баги и недоработки. ЯВНОСТЬ ещё не означает принципиальной проблемы. )))
M>Я говорю что вы термины пытаетесь размыть. Таким же образом можно говорить что нет некрасивых и красивых женщин , вкусной и невкусной еды и т.п. Какой в этом смысл ХЗ.
Кстати, хорошее сравнение. Ведь очевидно что ЯВНО красивые/некрасивые женщины и вкусная/невкусная еда — существуют, но в процентном отношении ко всей массе — в ничтожном количестве. Остальное где-то по серёдке. Так же и с кодом. Несомненно есть код ущербный (обычно студенческий) и код идеал (наверное есть), вот только в реальности клеймо говнокод к сей градации отношения вообще никакого не имеет. Чисто сугубо личное отношение некого программера к некому коду, обычно определяемое неспособностью прочитать/понять тот самый код и смериться с несовершенством мира.
З.Ы.
ИМХО, идеалист за клавиатурой хуже любого говнокода )))
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Чисто сугубо личное отношение некого программера к некому коду, обычно определяемое неспособностью прочитать/понять тот самый код и смериться с несовершенством мира.
А "говнокод" и есть субъективная оценка понятности и сопровождаемости кода.
Код, который не может поддерживать обычный программер — это говонокод.
Я тут не говорю, о сложных алгоримах, понимание которых требует специальных знаний.
И говонокод увы существует.
Признаки такие:
— плохо документирован, или комментарии вообще вводят с толку
— названия переменных/методов/классов не отражает сути
— код неединообразно форматирован
— нету автоматических тестов
— роли классов не понятны
— границы модулей/компонент размыты или вообще отсуствуют
— отсутствие layers и вообще какой-нибудь разумной инкапсуляции. отовсюду все видно и доступно.
— и т.д.
Как следствие, такой код безумно сложно поддерживать и править в нем баги.
Время добавление новых фич плохо предсказуемо...
Все это кстати вполне можно формализовать используя формальные метрики
и экспертную оценку живых людей. Работы на эту тему ведуться довольно давно.
При желании ты их вполне можешь найти.
Да, какой-нибудь гуру, типа тебя, с лету разберется в любом коде
и быстренько забабахает что надо в нужное время.
Но большинство программеров увы увы...
Короче проблема качества кода реально существует.
Игнорировать ее и даже высмеивать коллег, типа не умеющих читать код, — это не очень разумно
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Может таки надо думать о пользе кода, а не о идеальности его формы?
Странный вопрос. Если тебе поручено реализовать X, то ты будешь думать о пользе X и его роли в русской революции, или о том, как этот X лучше реализовать?
А если окажется, что код 90% повсеместно используемых продуктов — (в лучшем случае) спагетти-код, то вывод «наверное, это и есть залог успеха» не совсем логичен.
On 11.03.2013 21:56, Roman Odaisky wrote:
> А если окажется, что код 90% повсеместно используемых продуктов — (в > лучшем случае) спагетти-код, то вывод «наверное, это и есть залог > успеха» не совсем логичен.
Ну почему же. Ты можешь постратить время на вилизывание кода, а
конкуренты тебе обойдут, а когда ты код "идеально" вылижешь, он никому
не нужен будет.
Здравствуйте, Vzhyk, Вы писали:
>> А если окажется, что код 90% повсеместно используемых продуктов — (в >> лучшем случае) спагетти-код, то вывод «наверное, это и есть залог >> успеха» не совсем логичен. V>Ну почему же. Ты можешь постратить время на вилизывание кода, а V>конкуренты тебе обойдут, а когда ты код "идеально" вылижешь, он никому V>не нужен будет.
Если с самого начала хорошо спроектировать, затраты времени окупятся при первой же необходимости существенно изменить код. Тем более затрат-то: просто хорошо подумать, прежде чем шашкой махать, и не делать глупостей.
Другое дело, если код достался по наследству и он ужасен, но работает. Здесь грызение кактуса может быть и правильным решением...
On 12.03.2013 1:39, Roman Odaisky wrote:
> Если с самого начала хорошо спроектировать, затраты времени окупятся при > первой же необходимости существенно изменить код. Тем более затрат-то: > просто хорошо подумать, прежде чем шашкой махать, и не делать глупостей.
Что ж Господь Бог так человека хреновенько спроектировал-то?
А по сути, мир изменяется не с той скоростью с которой ты ожидаешь. И
как ты собираешься проектировать нечто идеально?
В реальности же то что тебе и другим казалось идеально спроектированным
вчера, сегодня может оказаться жутью — просто требования изменились
кардинально и если хочешь кушать, тебе придется их удовлетворить,
ругаясь и плюясь на свою идеальную в прошлом архитектуру.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Если с самого начала хорошо спроектировать, затраты времени окупятся при первой же необходимости существенно изменить код.
Все попытки "сначала хорошо спроектировать", которые я видел, заканчивались жутким говнокодом. Потому что сначала у тебя просто нет нужного понимания задачи и знания всех ее подводных камней.
А я и не знал, что шизофазия — запрещенное оскорбительное слово.
К сожалению мне пришлось от него отказаться в пользу либ из umfpack.
