небыдлокод - это код, на который приятно смотреть. он легко читаем, красив, и содержит все необходимые обработчики исключений и отлова нестандартных ситуаций. ах да, то, что он работает согласно ТЗ - это по умолчанию :)
вот я вчера весь день писал быдлокод на GWT и мне стыдно :(

тот который закрытый

ну и еще можно добавить, что он четко структурирован и выполнен согласно канонам и заветам шаблонов ООП программирования и проектирования. да, у меня ООП головного мозга :)

govnokod.ru молчит, не дает ответа

Правильно. Стыдись!

> Правильно. Стыдись!

я все перепишу!1 мне главное сейчас собрать все это чтобы оно начало работать как надо. а потом, если время еще останется - буду красоту наводить.

> небыдлокод - это код, на который приятно смотреть. он легко читаем, красив, и содержит все необходимые обработчики исключений и отлова нестандартных ситуаций. ах да, то, что он работает согласно ТЗ - это по умолчанию :)

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

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

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

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

Дык. Это жизнь. Точно так же как нет никакого оправдания войнам, голоду, лени, лжи и всему тому, с чем человечество какбэ борется как с пороками, вне зависимости от религий, оболочек и иного обрамления. Но надежда есть. Хотя бы оглядываясь назад, на прогресс, и сравнивая уровень проблем (и методы их решения) в прошлом с проблемами сегодняшними.

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

> И это большое искусство - бороться со сложностью, находить симметрии, прятать несущественное, поддерживать простоту.

настоятельно рекомендую ознакомиться с концепцией GRASP и прочитать, например, вот это - http://ru.dleex.com/details/?15668

Быдлокод - код который содержит в себе достаточно не логичные операции. Например программист php, который пишет на питоне. Он не знает особенностей архитектуры этого языка, и выдает такие перлы, которые python-программисту покажутся смешными. Хотя сам код будет рабочим.

> настоятельно рекомендую ознакомиться с концепцией GRASP и прочитать, например, вот это - http://ru.dleex.com/details/?15668

Как подметил кто-то умный - паттерны - это костыли для компенсации недостатков ООП. В соседнем топике как раз критикуется ООП, а паттерны - прямое следствие его (не будем повторять тот топик).

Думаете я не читал Буча, Гамму? У меня их есть, так же как и 3х томник-каталог паттернов от жабы до паттернов создания своих грамматик от создателя антлр.
И все эти флайвейты, MVC, адаптеры, фактори, фасады, декораторы - в большинстве своём это всё костыли. А создатель антлр просто демонстрирует испльзование своего продукта.
Для прошлых интервью я вынужден был большинство из них знать, но на практике - и до прочитывания всех этих книг всё делал так же (так как по-иному ты просто не реализуешь - если действительно думаешь о будущем и работаешь ручками), т.е. ничего нового для себя не открыл.
Я могу написать сколько угодно подобных паттернов, которых нет в книгах, которые создадут новых сущностей ещё на пару книг. Сложность будет ещё больше нарастать - по мере накопления различных паттернов, комбинаций использования итд.

> Как подметил кто-то умный - паттерны - это костыли для компенсации недостатков ООП. В соседнем топике как раз критикуется ООП, а паттерны - прямое следствие его (не будем повторять тот топик).

паттерны проектирования как раз таки и предназначены для решения проблем которые ты описал.

И все эти флайвейты, MVC, адаптеры, фактори, фасады, декораторы - в большинстве своём это всё костыли.

а что некостыли? последовательный asm-код? :)
большинство перечисленных техник и паттернов и предназначены именно для структурирования больших и комплексных программ.

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

Быдлокод это.

Быдлокод - это код который:

a) может быть сгенерирован - вместо этого написан руками в очередной раз

b) может быть вынесен в отдельную библиотеку путем обобщения и абстракции - но не был вместо етого его конкретно написали руками в очередной раз

c) изобретены абстракции которые позволяют писать проще и короче (критика языков программирования) - но так не делается по причине неподдерживании языком или таракановым отказом их использовать (непонятны мне эти непонятные лямбды)

d) связан не с решением непосредственной задачи, а с обходом ограничений использованых решений (архитектурная ошибка) - прмеры паттерны EJB: jdbc4reading, transfer object, etc.

но!

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

>ну и еще можно добавить, что он четко структурирован и выполнен согласно канонам и заветам шаблонов ООП программирования и проектирования.

Шаблоны ООП - это метод быдокода по стандртам:)

> Шаблоны ООП - это метод быдокода по стандртам:)

зопесал в блокнотик :)

> паттерны проектирования как раз таки и предназначены для решения проблем которые ты описал.

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

а что некостыли? последовательный asm-код? :)

если бы я знал универсальное решение - написал бы книгу, как говорится - «знал бы прикуп - жил бы в Сочи».
(как решение для своих проектов - организую процедурный последовательный и линейный пайплайн, делаю всё просто, не создавая лишних объектов, передавая один контекст и др решения)

> Плохой стиль кодирования?

кодирования

кодирования

ЭЭэээ.

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

++

интересно, а на Common Lisp можно наваять говномакросов, которые будут генерить говнокод в compile time?

паттерны проектирования как раз таки и предназначены для решения проблем

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

о великий гуру, яви же нам свет истины и скажи же нам, как надо правильно?

Главное - проводить рефакторинг до коммита, а не после.

>я все перепишу!1
ну да пациент. у вас ООП.

Программирование - это и есть искусство построения костылей вокруг недостатков и ограничений ОС/либ/компилятора/языка/железа/legacy/прочая. В идеальном мире, конечно, эти костыли не нужны, там любой теоретик может написать программу.

Обобщим в первый критерий быдлокода - быдлокод можно легко сократить на порядок, просто переписав его правильно.

Пример из жизни: 20 классов бизнес-объектов, никаких ORM, понимаешь, всё вручную. Для каждого объекта пишется куча методов типа GetById, FindParent и т.п. Лёгким введением общего интерфейса со свойством Id количество кода сокращается в 20 раз (по числу переписывания одного и того же кода).

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

Цитата вспомнилась.
«Controlling complexity is the essence of computer programming.»
(с) Brian Kernigan

>Пример из жизни

не всё так просто.
Потом говорят: теперь чтобы вытащить того парента - надо делать такой-то джойн (так как схема поменялась). Если это раздельные простые функции с запросами - просто меняешь запрос в нужной функции и всё.
Если же всё объединено - пошли ifы для стринга запроса и тут сложность стуканёт в невозможности поддерживать тот унифицированный запрос.

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

дык Керниган - наш человек :)

А вот для этого и нужны паттерны, ООП, и т.п.

А переписывание проекта практически никогда не нужно. Как раз потому, что идея о переписывании учитывает только идеалистичную картину, а реальное программирование - это установка подпорок. И переписывание означает кучу новых, неизвестных, подпорок. Про это у Спольски хорошо было написано: http://www.joelonsoftware.com/articles/fog0000000069.html

«The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed.»

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

> Потом говорят

структура программы должна меняться соответственно

Ну видишь, всё именно очень просто.

Если это раздельные простые функции с запросами - просто меняешь запрос в нужной функции и всё.

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

Но так как в реале обходятся дешёвым грязным фиксом (из-за того что надо сделать вчера и дёшево) - то код превращается в быдлокод

А от этого ничто не спасёт. 2 из 3.

> Это если не рефакторить

А что, не рефакторить было в условиях? Или у тебя рефакторить == переписывать?

В том то и дело, что «простым шевелением» области определения (т.е. требований) - одна функция может рассыпаться на 20 функций (для минимизации сложности + времени выполнения, с какими-то там субъективными и приемлемыми коэффициентами), и проще будет поддерживать те однордные и ясные функции (даже если они могут показаться копипастой), но одновременно с этим - в той же окрестности области определения - будет выгодно наоборот - иметь в той функции простой IF. А поменяются требования в третью сторону - будет выгоднее сделать код в хранимой процедуре. итд. Т.е. при изменении области определения - минимум сложности программы (при приемлемой скорости, или при минимуме её) - крайне неустойчива.

А если таких классов несколько тысяч и программу делало много человек в течение года или больше - то изменение сотен подбных классов провоцирует программистов автоматизировать процесс изменений. После неправильного нахождения минимума (это искусство!) - сложность начинается скапливаться где-то каскадно. И никто не возьмётся фиксить это так как простая фигня не будет фиксится и за неделю времени. Надо переписывать. А как - если программа эволюционировало в нечно сложное, не поддающиеся охвату даже самых гениальных программистов?
Короче, много я видел проектах, плюхающихся в подобной сложности, где народ приходит и уходит. И когда-то это перепишут. И начнётся всё снова.
Нет ещё стандартов поддержки и разгребания сложности любого порядка. Особенно когда многпточность. Потому что программа - многомерная сущность, а человек может охватить только несколько измерений и 7+-2 объекта одновременно.

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

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

Кажется Столлман верно подметил, что программа без оригинального девелопера имеет нулевую стоимость.

> не решаться делать большие перестройки

Значит, надо нанять других людей, которые решатся. Например, меня ;-)

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

Собственно, с понимания работы программы и начинается рефакторинг всякого легаси кода.

Ты, по-моему, теоретик. Ничего во всём это сложного нет.

> функция может рассыпаться на 20 функций (для минимизации сложности

Бессмертное «Эта задача легко решается введением 11-ти дополнительных плоскостей»?

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

Я одного не понял. Почему ты предлагаешь писать программу не под текущие условия, а под «если вдруг» возможные в будущем? Это какой стиль программирования? Точно не YAGNI.

нечно сложное, не поддающиеся охвату

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

И когда-то это перепишут. И начнётся всё снова.

А секрет прост - не надо экономить на программистах. Потому что быдлокодеры не могут переписать быдлокод.

значит ты не видел сложности. Всё относительно.

Например, намешаны все фреймвоки на свете на сервере и JSF, gwt и YUI - на клиенте, с их совершенно разными формами девелопмента. Когда только бизнес-логика описывается томами и только копировать гигабайты этого дерьма долго, не говоря о том что разбираться.

Или билд-система с почти бесконечным числом зависимостей, где просто сбилдить систему может только один человек, который с самого начала, много лет назад, работал ещё с оригинальным девелопером, сделавшим то (на сегоднешний момент уже) дерьмо. Тогда наверное было не так.

Если ты настолько крут - попробуй тогда уж войти в девелопмент ядра или гнома или кде или какого-нибудь opengl - там много работы наверняка. Сразу получишь имя - если сможешь что-то существенно сдвинуть.
Да вон тот же YUI звал девелоперов недавно. Я там постил баги по дата-таблице и надо было их решить, но никто так и не отозвался. Правда именно из-за тех багов и отсутствия поддержки конкурирующий департмент перехватил проект чтобы переписать под оффтопиком на .нете. Но и они упрутся, но уже по другим причинам.
Если бы было так просто..

нет, я не теоретик, я практик.

Я просто оставлю это здесь

http://en.wikipedia.org/wiki/Literate_programming

>Собственно, с понимания работы программы и начинается рефакторинг всякого легаси кода.

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

> Бессмертное «Эта задача легко решается введением 11-ти дополнительных плоскостей»?

рассыпание - это просто для красивой иллюстрации (в стиле топика про ООП).

Ты точно теоретик.

я тебе всего лишь проиллюстрировал - что деление на классы очень не одназначно. И с изменением требований - то деление может поменяться кардинально.

Я одного не понял. Почему ты предлагаешь писать программу не под текущие условия, а под «если вдруг» возможные в будущем? Это какой стиль программирования? Точно не YAGNI.

Если программист не будет учитывать «если вдруг» - то код невозможно будет изменить при изменении требований.

А на самом деле - надо просто делать. Постепенно. По частям.

А секрет прост - не надо экономить на программистах. Потому что быдлокодеры не могут переписать быдлокод.

базара нет :)
кто же спорит?

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

как надо правильно?

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

Попытка определения

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

> Как подметил кто-то умный - паттерны - это костыли для компенсации недостатков ООП. В соседнем топике как раз критикуется ООП, а паттерны - прямое следствие его (не будем повторять тот топик).

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

А то фигпоймичто — программист Вася Пупкин говорит «обертка», имея в виду «декоратор», программист Федя Пипкин говорит «обертка», имея в виду «адаптер», а манагер Миша Сиськин вообще при слове «обертка» думает про конфеты. Возникают недопонимания, испорченный телефон, быдлоправки чужих быдлокоммитов, быдлореверты, насупленные взгляды и прочее контрпродуктивное.

А впрочем это отстой

Пусть будет +1 к легко/трудно читать/поддерживать.

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

Хорошее определение, мне оно нравится.

Это, скорее, свойство, а не определение. Дело в том, что когда мы начнём определять квалификацию программиста, нам потребуется качество его кода. И получится цикл!

Вообще, наверное, можно определить «обратную ремонтопригодность» кода как отношение затрат человекочасов на единичную правку [это, т.е., производная] к затратам на написание аналогичного функционала с нуля. И дальше попробовать строить какие-то модельки даже (Брукс же строил в МЧМ).

> Если программист не будет учитывать «если вдруг»

Я в упор не понимаю, ты реально пишешь код, учитывая все «вдруг»?

http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
http://c2.com/xp/YouArentGonnaNeedIt.html

- то код невозможно будет изменить

Это почему? Высечен в скале что ли?

Только где ж взять столько гениев

Переманить у гугля ;-)