Mea Culpa - отличная статья программиста, который любил наворачивать сложность и сделал супергибкую систему.
I spent those decades debugging the Frankenstein. In the OS crash debugger. In hex. Because wasn’t it oh so clever and efficient to build a radically new kind of database with extreme reliability requirements as a highly multithreaded kernel extension to the OS?
Ну и вывод
That experience taught me a lot about what really matters in programming. It is not about solving puzzles and being the brightest kid in the class. It is about realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention.
И всегда лучше учиться на чужих ошибках, да.
Спасибо maniac'у за ссылку.
Atom feed
11 коммент.:
По ссылке прочитал статью про программиста, который на заре карьеры сделал говносистему от которой все страдали, и только через 20 лет приобрёл достаточно опыта чтобы переделать её в нормальную.
Сколь угодно технически сложный программный продукт можно сделать хорошим.
Для этого необходимо одновременно быть the brightest kid in the class, и осознавать зачем нужны simplicity, conventions, hard work, responsibility, etc.
Будучи только brightest kid - получится то что у автора статьи в начале карьеры, т.е. over-engineered система которую почти невозможно отладить и очень сложно модифицировать. Будучи только hard working - невозможно решать нетривиальные проблемы, при решении тривиальных получается индийский код. Оба крайних варианта одинаково плохие.
soonts, вы производите впечатление такого же максималиста, как и mr. Edwards в начале своей карьеры (без обид).
Для большинства задач вполне хватает чужого опыта и, соответсвенно, умения находить готовые решения.
"Brightest kid" - это, насколько я понимаю, "отличник во всем", что в программировании только повредит. Лучше быть узким специалистом и делать свою маленькую (или средненькую) работу в команде хорошо.
Будучи только "hard working" (старательным), можно вполне зарабатывать себе на жизнь и не волноваться о завтрашнем дне. И индийского кода в промышленных масштабах обычно хватает для решения большинства задач, хотя я не могу сказать, что это правильная стратегия (от обратного утверждения тоже воздержусь).
Вы назвали два крайних варианта, но не заметили, что ваш вариант тоже крайний - "все и сразу".
>индийского кода в промышленных масштабах обычно хватает для решения большинства задач
Вы вероятно работали только в одной области? Web-разработка? ERP? Внедрение?
IT проекты в этих областях обычно состоят только из тривиальных задач, если не брать 2% граничных случаев (разработка поискового движка, работа в Microsoft в команде Dynamics AX, внедрение чего угодно в масштабах General Electric - примеры граничных случаев в этих 3 областях).
К счастью для любителей писать Indian-style говнокод, рынок таких IT систем огромен.
Если алгоритмы предметной области нетривиальны - необходимо быть "the brightest kid" чтобы сделать хоть что-нибудь. Пример тривиального - формирование и печать отчёта по данным из RDBMS, примеры нетривиальных - распознавание образов, моделирование физики, численные оптимизации.
Если имеются неудобные ограничения вроде "игра должна работать 60 FPS пропуская максимум 1 кадр из 200", "вся обработка должна уложиться в 1 минуту на деталь", "сервер с 16 ядрами должен обрабатывать 100 mbit/sec данных с загрузкой CPU не выше 90%", "у серийной железки будет 32kb EPROM для кода, 256kb RAM и 4kb NAND" - индийский код не взлетит, умение находить готовые решения скорее всего не поможет.
К счастью для любителей писать over-engineered говнокод, рынок IT продуктов подразумевающих такие проекты тоже довольно большой.
>тоже крайний - "все и сразу".
Так бывает.
С чего вы с автором статьи взяли, что два обсуждаемых параметра являются зависимыми?
Более того, думаю почти любого распиздяя можно научить писать требования, проектировать критичные вещи перед программированием, сочинять каменты по делу составляющие 15-20% от общего числа строк, рефакторить вместо копирования кода, везде где возможно использовать Microsoft-библиотеки вместо OpenSource или тем более вместо разработки собственных, и другими способами демонстрировать старательность. Причём приобретённые бесценные навыки почти никак не отразятся на интеллекте распиздяя.
P.S. Пару раз знакомые студенты спрашивали меня, как стать хорошим программистом. Совет который я им давал - поработайте в диаметрально разных областях IT. Один из эффектов - появится понимание, для каких задач можно нанимать "индусов", для каких не стоит.
Ну что же: лучше поздно, чем никогда. Прозрел-таки человек на старости лет. KISS! Типа "будь проще".
Именно поэтому над такими Яркими Личностями (AKA brightest kids) должны стоять менеджеры и техлиды, которые будут возвращать их периодически с небес на землю и говорить - куда копать и как потратить энергию в мирных целях.
А то ведь и вправду, стадо котов получается, лабающих мегабайты кода во имя своих идеалов, не имеющих малейшего представления - а для кого и что они пишут.
Статья больше похожа на лозунг "Лучше быть здоровым и богатым, чем бедным и больным". Лозунг о простоте продекларирован и все. А как этой простоты достичь? И как вообще понять, достаточно ли просто какое-то решение или нет?
У меня иногда бывает так: делаешь code review и код мне не нравится. Говоришь, что можно сделать проще. А человек не понимает. "Куда уже проще?", спрашивает. К счастью, зачастую я знаю, что именно можно переделать. Но бывают и случаи, когда интуиция подсказывает, что можно проще. Однако долго приходится вникать в тему, чтобы высказать конкретные рекомендации.
2Евгений Охотников:
Статья больше похожа на лозунг "Лучше быть здоровым и богатым, чем бедным и больным". Лозунг о простоте продекларирован и все.
Там описан клинический случай, по-моему.
У меня иногда бывает так: делаешь code review и код мне не нравится. Говоришь, что можно сделать проще. А человек не понимает. "Куда уже проще?", спрашивает. К счастью, зачастую я знаю, что именно можно переделать. Но бывают и случаи, когда интуиция подсказывает, что можно проще. Однако долго приходится вникать в тему, чтобы высказать конкретные рекомендации
Code review - процесс тонкий, тут много замешано на психологии. И кому-то проще одно, кому-то другое.
>Там описан клинический случай, по-моему.
Это от обстоятельств зависит :) На одной из моих прошлых работ два очень толковых мужика писали собственную Real-Time OS, поскольку тогда руководство считало, что это может себя окупить.
> И кому-то проще одно, кому-то другое.
Так в том-то и дело. Разговоров о том, что решения должны быть простыми, много. А конкретных рекомендаций об оценке (хотя бы оценке) этой простоты практически и нет (по крайней мере в популярном изложении я не встречал).
Более того, поскольку мировозрение у разработчиков с возрастом меняется, то и оценка сложности так же будет изменяться. Сейчас молодые горячие C++ники любят трехэтажные шаблоны использовать. Для них это просто. А чуть постареют, подустанут от программирования и свой же собственный ранее простой код будет казаться им сложным и непонятным. И появится где-нибудь в блоге описание очередного клинического случая... :)
Do the simplest thing that could possibly work. -- один из принципов XP.
2dan:
Do the simplest thing that could possibly work. -- один из принципов XP.
Это очень похоже на бритву Оккама.
Лет 5 назад я как-то у одного девелопера на форуме видел в подписи: "if it is hard to write it should be hard to read". И это было серьезно, он так и думал. К счастью, сейчас таких людей становится меньше (или мне просто везет?)
Отправить комментарий