программистское: о красивом коде

[avva]

Прочитайте вот это, коллеги.

Там - Горькая Правда.

A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious. The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today. This is a bitter pill to swallow, because programming attracts and rewards the intelligent, and its culture encourages intellectual arrogance.

(но стоит прочитать полностью)

Comments

[liksu.livejournal.com]

А можно вариант на русском? :)

[gaius-julius.livejournal.com]

если придерживаться такой концепции, то... представление разработчика о красоте со временем меняется.

[andrzejn]

А ведь Вернор Виндж говорил. А ведь Виндж предупреждал!

Без сверхинтеллектов ничего не получится.

[plakhov.livejournal.com]

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

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

[averros.livejournal.com]

На что есть наш пролетарский ответ: Keep It Simple, Stupid!

[plakhov.livejournal.com]

Это только начало.

Потом выясняется, что в похожих ситуациях мы вынуждены писать одно и то же. Почти copy-paste (а иногда и не "почти"). Досадно, но оказывается, что таких ситуаций примерно миллион.

Чтобы писать такие места быстрее и с меньшим числом опечаток, мы объединяем часто встречающиеся последовательности и выносим общую функциональность в отдельные сущности (функции, классы, макросы, шаблоны, generic'и, или даже тьфу-тьфу не дай бог аспекты).

И тут выясняется, что каждый такой конструкт первого порядка хочется потом fine-тюнить. Потому что вот в этом интерфейсе теперь надо показывать пункты не выпадающим списком, а плоским. А вот эта надпись должна быть полупрозрачной. Что значит "нельзя"? Какая-такая "архитектура"?

Появляется некоторый язык настройки этих сущностей второго рода. Аггрегация вместо наследования, декораторы, общие интерфейсы вместо общего предка.

Тут в проект приходит новый программист, и...

[oxfv.livejournal.com]

Remarkable how your comment adheres to what you're preaching in it and how plakhov's response is a great illustration of going astray.

[plakhov.livejournal.com]

к. - с. т.?

[sleeping-death.livejournal.com]

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

[e2pii1.livejournal.com]

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

[sleeping-death.livejournal.com]

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

[plakhov.livejournal.com]

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

1) Я не совсем понял, откуда возникает противопоставление "beauty vs straightforwardness and conventionality". Дизайн imo красив именно тогда, когда не переусложняет систему неоправданно, и не дает возможности "глупо ошибиться". Собственно, когда соблюден баланс coupling vs cohesion, и хороша система раннего обнаружения ошибок (строгая типизация, testability и тп).
2) Но этого совсем недостаточно; надо еще и формулировать требования к системе в такой форме, и таким способом, чтобы излишняя сложность не была заложена в самих исходных требованиях.

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

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

С добрым утром!

[plumqqz.livejournal.com]

Вообще-то это издревле формулируется как "на всякого мудреца довольно простоты".

Re: С добрым утром!

[cmm.livejournal.com]

да-да, в Святом Писании уже всё давно сказано.

Re: С добрым утром!

[plumqqz.livejournal.com]

Ну вот - сами же все знаете.

[msh.livejournal.com]

Представляются инженеры Тойоты, рыдающие над чертежами нового автомобиля "the human mind can not grasp the complexity of a compact car, much less the Lexus SUV we build today"

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

[avva.livejournal.com]

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

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

[msh.livejournal.com]

Различные варианты фразы "ты чо тут, самый умный?" меня не обижали даже в средней школе ;-)

Сложность проблемы от декомпозиции не съеживается, а скорее наоборот, раздувается. Просто ее становится возможным grasp. Вот и все. Остается декомпозицию из магического слова превратить в обыденный инструмент software development

Опять же, автомобилестроение прошло этот путь в обозримом прошлом - от какого-нибудь гениального
August Horch, в одиночку проектировавшего автомобили, до современных платформ и компонентов

[sply.livejournal.com]

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

[cmm.livejournal.com]

> 18-й век уже окончился

в программировании — от силы тринадцатый: по каким именно границам декомпозицию производить не всегда понятно,
а большая часть процессов недалеко ушла от камлания.

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

[stas]

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

[cryinstone.livejournal.com]

Да, верная статья.
Написанная видавшим жизнь прагматиком, этаким Экклезиастом software engineering:)

[malaya-zemlya.livejournal.com]

А книжка, которая Beautiful Code, очень хорошая. Рекомендую.

(Приятно и то, что по крайней мере три автора работают прямо под боком :)

[pollak.livejournal.com]

Все так, но началось это еще задолго до компов и прог. Я бы сказал - ну паровоз, это уже вполне неинтилигибельно. Я уверен, например, что много раз в истории ранних железных дорог было так - паравоз ломается и НИКТО включая лучшего инженера, его проектировавшего - не понимает почему.

Ну это все Лем хорошо описал.