?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Next Entry
Понятность - корень всей оптимизации
nyaload
_winnie
Проблема понятной и простой программы в том, что в ней легко видны все недостатки. Архитектурные, эффективности по памяти/времени. Напишешь что-нибудь простое, а потом второй программист с огненным взглядом сходу разберётся в нём, и "улучшит".

Не, правда улучшит. Уберёт лишнюю аллокацию, уберёт лишнее копирование файла, напишет кастомный поиск за log(log(N))*log(N), повысит эффективность на 10%, добавит локализацию, заменит goto на виртуальные функции, сделает более универсальным через политики-интерфейсы-XML, заменит print "<font color='red'>" на могучий фреймворк с CSS и шаблонами. А может автор-джедай специально, сжав зубы, выдержал искушение написать свой оптимизированный алгоритм вместо линейного поиска. И предпочел плохую репутацию использующего goto, потому что именно в этом месте оно позволило разместить код на половине экрана, а не в трёх файлах.
Или предпочел загрузку по требованию hash_map<Filename, Resource> вместо мозгосрывающего упаковщика ресурсов.

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

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

Похожая ситуация была описана в "Мифическом человеко-месяце", это описывалось как "эффект второй системы". Это когда есть первый вариант системы, и делается вторая версия. Но теперь-то автор знает, "как правильно" и "что может понадобиться". Поэтому делается запутанный монстр, который никому не понятен.

Немного абсурда: Итак, что бы код оставался простым, надо делать делать его сложным. Тогда его никто не сможет оптимизировать. Варианты: Perl, бинарники без исходников, pure C с указателями, Ocaml/Haskell/LISP, ...
Кстати, pure C и Ocaml/Haskell/LISP - тут уже меньше доли шутки.

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





  • 1
(Deleted comment)
Да, это само собой. Но есть всякие ситуации, когда до оригинального автора не добраться или он сам не помнит что к чему через три года, или "автор" это коллективное творчество за которое любой конкретный человек не возьмёт ответственность.


в последнем случае не о каких преднамеренных действиях первоначального автора по написанию простого кода речи быть не может :)

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

Edited at 2010-11-27 06:11 pm (UTC)

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

Не сильно полезный совет. когда одних уж нет, а те далече. :)
Тем более, что сами авторы кода уже через месяц не помнят всех тонкостей работы своих творений. А через годы -- тем более. Ну и разбираться пусть и в своём старом коде, но не за зарплату, энтузиастов мало. В лучшем случае услышишь совет "ну там всё вроде было просто, сам разберёшься".

Вот меня часто мучит такой вопрос, когда натыкаюсь на очередную "странность" в коде. То ли предыдущий автор был глуп и очевидной вещи не сделал. То ли предыдущий автор был гораздо умнее меня и имел веские причины делать именно так, а не иначе; я же в силу природной ограниченности и узкого кругозора этих самых причин не вижу.

Вот именно для таких мест и существуют комментарии.
//так надо
//потому что то-то и то-то
//глаза слипаются

Комментарии? Ха-ха-ха три раза. Автору же всё было "и так очевидно". :)

Я всегда стараюсь комментировать такие места в своём коде. Понять их неочевидность совсем не сложно. Вопрос желания делать код поддерживаемым.

Реальность, конечно, не идеальна, но, к счастью, не на 100% плоха.

(Deleted comment)
Да, я верю что это значит нечто больше, чем кидание бюллетеня в избирательную урну.

Edited at 2010-11-27 06:13 pm (UTC)

Это всего-навсего значит, что модератор топика может соблаговолить сделать характерное движение рукой и нажать на кнопку с красным крестиком. :)

Мы уже наспамили бессмысленными сообщениями больше чем этот несчастный бот!
(я уже всё нажал, и забанил, и сообщил, но на крестик забыл нажать, теперь уже не буду)

ни в одном из наших бессмысленных сообщений нет ссылок, доставляющих боту его трудовую копеечку
в отличие от
:)

сужу по себе:

* для простоты и понятности кода могу написать первый вариант, но обязательно обозначу места, которые можно соптимизировать и прокомменчу почему я так сделал (функция запускается один раз при запуске программы и не должна выполняться сколько-нибудь долго, поэтому вместо мега-оптимального варианта реализован простой, но максимально понятный и легко поддерживаемый; при этом мегаоптимальный реализуется сильно сложнее и непонятнее простого варианта, т.к. если они сравнимы по этим показателям - всегда идёт мегаоптимальный)

* иногда вообще непонятно, куда будут расти функциональные спецификации (далее ФС) - а они будут расти, мы то знаем ;-) - в таких случаях пишу наиболее generic, но простой вариант (он же, как правило, и наименее эффективный вариант). В этом случае оптимизация происходит уже на стадии устаканивания функциональных спецификаций.

* когда понятно, куда могут расти ФС, я делаю реализацию, которая ровно на 1 шаг делает больше, чем нужно прямо сейчас. Это очень часто помогает, в случае когда вы таки угадали, либо же, когда ФС изменились не совсем так, как вы планировали, но(!) благодаря вашей прозорливости, теперь это реализовать куда проще, чем если бы вы заточились на вариант "то, что нужно прямо сейчас".

Стоит отметить, что последние два правила работают, видимо, только на больших проектах, т.к. на маленьких ФС не успевают меняться сколько-нибудь заметное количество раз за время жизни проекта.

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

Code ownership зло? :)

  • 1