elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
О программном коде
elizarov
Лучший программист не тот, кто пишет больше кода, а тот, кто решил поставленную перед ним задачу наименьшим количеством кода. Из двух программ решающих одну и ту же задачу лучше та, которая короче. Хороший рефакторинг уменьшает количество кода в проекте. Код имеет наилучший дизайн, если для внесения в него новой функциональности нужно произвести изменения в наименьшем количестве мест кода.

UPDATE: Пост исключительно о программном коде. Упоминание программиста было лишним.

  • 1
Рома, а что ты скажешь о команде, которая перед каждым серьезным изменением проводит рефакторинг и ревью кода, после чего изменения вносятся минимальным количеством изменений кода. Только вот на рефакторинг уходят недели.

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


Edited at 2009-04-20 08:48 pm (UTC)

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

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

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

Если команду можно просто разогнать, то нет смысла обсуждать, как у них там рефакторинг проходил.

Мне рассказывали что в МГУ на военной кафедре учат, что "очевидно, что чем меньше строк в программе, тем быстрее она работает" ;)

> Из двух программ решающих одну и ту же задачу лучше та, которая короче
"Короче" лучше заменить на проще, имхо разумеется
а то вместо
pulbic String doSomeThing(final String myParam) {...}
можно получить
pulbic String d(String p) {...}



Естественно, "короче" требует определения. В данном случае, это философская концепция как и "проще".

(Deleted comment)
Я в чем-то согласен что "короче" == "проще", но на самом деле всё несколько сложней.

Исходники хорошей программы можно распространять через твиттер

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

Я встречал людей, которым нравится чтобы было поменьше кода, пусть даже ценой сложных языковых конструкций. А встречал и таких, которые предпочтут больше кода, лишь бы читался на одном дыхании даже в пятницу вечером. Оба подхода хороши пока разумны.

В моём мироощущении объём кода и качество программы не связаны.

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

  • 1
?

Log in

No account? Create an account