Comments 20
Все читают теги!
Не сказать, чтобы автор был неправ, но… Это констатация очевидных фактов. И, увы, код от их очередного прочтения едва ли улучшится.
В третьем пункте главное не начать заводить по отдельному классу на каждый чих :)
Тогда уже по два класса. Chih extends AbstractChih
implements ChihInterface use ChihTrait :)
Давеча на работе встречал. Масштабы изменены в целях понятности и конспирации.
AbstractChihFactory<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
HumanChihFactory<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
AnimalChihFactory<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
AbstractBigChih<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
AbstractSmallChih<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
HumanBihChih<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
AnimalBigChih<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
HumanSmallChih<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>,
AnimalSmallChih<X extends ChihProcess, AbstractChihResult<ChihProcess, Y extends ChihProcess, Z extends ChihProcess>>
Прямое следование второму совету может привести к функциям/методам, в которых большую часть кода выполняет анализ флаговых параметров для выбора того или иного нюанса поведения. Потому нужно ввести ещё правило — не бойтесь разъединять код, который однажды объединили по причине того что он был одинаковый в нескольких местах, а потом оказалось, что должен немного отличаться.
<offtop>
Знаю команду одного очень успешного it-проекта, которая неожиданным образом следует принципу DRY: копипастят код исключительно друг друга (и друг на друга ссылаются в случае проблем со свежескопированным кодом).
</offtop>
По сути, основной принцип один: нужно писать код, соответствующий общей идеологии проекта, и, по возможности, поддержка которого не вызывает желание убить автора. Бывают скрипты, которые нужно написать быстро, которые используются одним способом, и требования к которым не меняются годами. Бывают задачи типа «максимально быстро запилить эксперимент/прототип, чтобы не жалко было выбросить». В таких случаях рабочий императивный говнокод вида «поток сознания» вполне пригоден и полностью соответствует идеологии задачи, и, более того, нередко хорошо поддаётся рефакторингу.
Знаю команду одного очень успешного it-проекта, которая неожиданным образом следует принципу DRY: копипастят код исключительно друг друга (и друг на друга ссылаются в случае проблем со свежескопированным кодом).
</offtop>
По сути, основной принцип один: нужно писать код, соответствующий общей идеологии проекта, и, по возможности, поддержка которого не вызывает желание убить автора. Бывают скрипты, которые нужно написать быстро, которые используются одним способом, и требования к которым не меняются годами. Бывают задачи типа «максимально быстро запилить эксперимент/прототип, чтобы не жалко было выбросить». В таких случаях рабочий императивный говнокод вида «поток сознания» вполне пригоден и полностью соответствует идеологии задачи, и, более того, нередко хорошо поддаётся рефакторингу.
Правда в хорошем коде есть одна засада. Чем сильнее вы прогрессируете как программист, тем выше становятся ваши требования к хорошему коду и тем сложнее эти требования вам удовлетворить.
Очень забавно: вначале вы осознали проблемы своего кода, после этого повысили к нему требования, а потом потратили кучу времени, чтобы научиться эти требования удовлетворять.
Очень забавно: вначале вы осознали проблемы своего кода, после этого повысили к нему требования, а потом потратили кучу времени, чтобы научиться эти требования удовлетворять.
А теперь ждем, когда весы качнутся в другую сторону и появится статья с доводами писать рабочий код и быстрее запускать его в продакшн, а рефакторинг и лучшие практики оставить, когда появятся на это ресурсы.
Первый принцип описан у Брукса в Мифическом человеко-месяце.
Проблема в том, как донести это до программистов. Мне не раз доводилось работать с людьми, считающих свой код самодокументированным.
Проблема в том, как донести это до программистов. Мне не раз доводилось работать с людьми, считающих свой код самодокументированным.
Попробую донести эти пункты до моих кодогенераторов, это очень важно для них.
И да, очень плохо, что читая ассемблерный вывод компилятора мы не видим правила хорошего тона, именования переменных, и паттерны.
Вообще непонятно как компилятор работает без Agile и Scrum.
Что-то в этом есть неправильное.
Имхо принцип, при котором программы пишутся не для клиентов, не для работоспособности, а для читающих код — это как раз ключевой момент в переходе от объективных характеристик к субъективным оценкам. Т.е. базирующихся не на истине, а на консенсусе.
Алан Кей писал, что современное программирование — это не инжиниринг а поп-культура.
Мы же не инженеры, это скучно, мы же Художники, ага, с большой буквы.
Вот так вот художниками и останемся, и остальных тоже хотим сделать художниками.
Если красивый код важнее, чем работоспособный — значит что-то у нас не то.
За последние пять лет не видел тимлида не проводящего регулярно ревью стайлинга. И при этом ни один из них (!) не знал про существование uncrustify — специально спрашивал.
Сапожники без сапог, ага.
Увеличивая разницу в требованиях к человеку и к программе — мы ликвидируем всякую возможность заменить человека программой в ближайшем будущем.
Может это выгодно авторам таких статей?
Платят ведь неплохо…
И да, очень плохо, что читая ассемблерный вывод компилятора мы не видим правила хорошего тона, именования переменных, и паттерны.
Вообще непонятно как компилятор работает без Agile и Scrum.
Что-то в этом есть неправильное.
Имхо принцип, при котором программы пишутся не для клиентов, не для работоспособности, а для читающих код — это как раз ключевой момент в переходе от объективных характеристик к субъективным оценкам. Т.е. базирующихся не на истине, а на консенсусе.
Алан Кей писал, что современное программирование — это не инжиниринг а поп-культура.
Мы же не инженеры, это скучно, мы же Художники, ага, с большой буквы.
Вот так вот художниками и останемся, и остальных тоже хотим сделать художниками.
Когда устранили великое Дао, появились «человеколюбие» и «справедливость». Когда появилось мудрствование, возникло и великое лицемерие. Когда шесть родственников в раздоре, тогда появляются «сыновняя почтительность» и «отцовская любовь». Когда в государстве царит беспорядок, тогда появляются «верные слуги».
Если красивый код важнее, чем работоспособный — значит что-то у нас не то.
За последние пять лет не видел тимлида не проводящего регулярно ревью стайлинга. И при этом ни один из них (!) не знал про существование uncrustify — специально спрашивал.
Сапожники без сапог, ага.
Увеличивая разницу в требованиях к человеку и к программе — мы ликвидируем всякую возможность заменить человека программой в ближайшем будущем.
Может это выгодно авторам таких статей?
Платят ведь неплохо…
Невероятно трудно
но в то же время легко
На самом деле, это настолько просто, что сводится к трем правилам
Проблема в том, что это очень трудно
Код Шредингера — настолько простой, что невероятно трудный.
Еще слышал одно правило для написания кода (к сожалению забыл кто автор, по-моему кто-то из классиков):
Пишите код так, как будто его будет сопровождать маньяк-психопат, который знает, где Вы живете.
Три правила хорошего борща.
В последнее время я видел мало действительно хороших супов, много посредственных и очень много — плохих. (Много того, что я готовил раньше — особенно, когда я только начинал — относится к последним, увы.) Читая случайные статьи в интернете и профессиональные книги, я пришел к выводу, что варить хороший суп — легко. Невероятно трудно, но в то же время легко. На самом деле, это настолько просто, что сводится к трем правилам.
1. Варите суп не для кастрюли, а для себя.
2. Не кладите одни и те же ингридиенты два раза.
3. Каждый ингридиент должен выполнять одну задачу.
Соблюдая их постоянно, вы будете варить очень хороший суп. На любой плитке и в любой кастрюле. Проблема в том, что это очень трудно. Все они требуют дисциплины, а для двух последних в большинстве случаев нужны еще и продолжительные размышления.
В последнее время я видел мало действительно хороших супов, много посредственных и очень много — плохих. (Много того, что я готовил раньше — особенно, когда я только начинал — относится к последним, увы.) Читая случайные статьи в интернете и профессиональные книги, я пришел к выводу, что варить хороший суп — легко. Невероятно трудно, но в то же время легко. На самом деле, это настолько просто, что сводится к трем правилам.
1. Варите суп не для кастрюли, а для себя.
2. Не кладите одни и те же ингридиенты два раза.
3. Каждый ингридиент должен выполнять одну задачу.
Соблюдая их постоянно, вы будете варить очень хороший суп. На любой плитке и в любой кастрюле. Проблема в том, что это очень трудно. Все они требуют дисциплины, а для двух последних в большинстве случаев нужны еще и продолжительные размышления.
Sign up to leave a comment.
Три правила хорошего программирования