Определение понятия «быдлокод»

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

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

> гигабайты

И сколько ресурсов было на это потрачено? И ты предлагаешь потратить их заново, на то же самое?

бизнес-логика описывается

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

дата-таблице

jqGrid надо юзать ;-)

Или билд-система

Вот с билд системы и начнём. Постепенно, по частям.

Сразу получишь имя

Я предпочитаю деньги.

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

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

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

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

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

невозоможно. Они - самый лучший работодатель по 2010 году. Да и не стоит вопрос у менагеров о наборе. Скорее - о сокращении, с сегодняшними то экономиями :(

> Вот с билд системы и начнём. Постепенно, по частям.

да никто не даст вам начать (тот проект был на одной из моих предыдущих работ). Там билд-система была не приподъёмна. Люди месяцами не могли ничего сделать, даже если хотели ипростить. Так как сличком много фирм и людей с разными стилями его делали. И конечно все добавляли свои зависимости и усложняли билд-систему каждый день. А переписывать многолетний проект (3*20=60 человеко лет минимум) да ещё котрый крутится на продакшене никто не намерен.
Короче, всё часто гораздо более запущено.

> А переписывать ... никто не намерен

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

Только лично я говорю совсем о другом, и мне уже скучно снова объяснять, о чём.

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

Бред.

Я вообще не понимаю, ты такой тооонкий тролль или я не догоняю преимуществ копипасты кода в 20 одинаковых функций «на будущее».

>Бред.

Я вообще не понимаю, ты такой тооонкий тролль или я не догоняю преимуществ копипасты кода в 20 одинаковых функций «на будущее».

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

программист php, который пишет на питоне и выдает перлы,

Зажмурим бесстрашные очи :)

15 лет недостаточно, чтобы понять, что сопровождать 20 функций намного проще, чем одну, а maintenance превращается в nightmare?