Перевод, вольный. Очень.
12 признаков того что вы ущербный программер и не знаете об этом...
Вам вообще встречались программеры-приматы не осознающие своей ущербности. Ну такие, считающие себя достаточно продвинутыми. Могут выдать на гора подборку из цитат которые они слышали от каких-то гугу. Точно знают много правил создания "правильного" кода. Правда при этом их собственный код серьезно страдает отсутствием всех этих знаний которые у них предположительно есть. Что, никого такого не знаете? Да ладно, знаете, все эти упертые теоретики не понимающие практики. Звучит знакомо?
Вот несколько признаков подобных программеров:
1. Джава это наше все!.
Вам непонятна нужда в других языках программирования. Нет, ну почему нельзя все написать на Джаве?? Вас не колышет то что на Python или Ruby некоторые куски кода длиной строк в 10 делают то же самое на что уйдет несколько страниц кода на Джава? Кстати, вы убеждены что новые фичи языка в следующем релили по любому это исправят.( на месте Джавы мог бы быть каждый, просто поклонники Джавы кажется подобному подвержены сильнее других на данный момент)
Ну разумеется "Джава это наше все" это признак ущербного программера. Поскольку все правильные программеры знают что "с++ это наше все", ага.
ЗЫ: просто я в основном сталкиваюсь с с++ программистами....
2. Будь "Enterprise" или здохни.
"Enterprise" чертовски серьезная вещь. "Enterprise" для вас это не просто слово."Enterprise" это способ жизни,"Enterprise" это ваша философия, ваш путь к просветлению. Все что может быть написано, установлено или обновлено с минимальными затратами - детские игрушки. К тому же понятное дело нерасширяемые. Ну а пока большенство работы в вашем офисе делается с помощью Excel spreadsheets. Ничего, подождут пока вы не закончите свой монументальный "enterprise" проект по налаживанию документооборота.
...за что я не люблю с++ библиотеки...мысль развивать пока не буду.
3. За функции длиной больше 20 строк нужно расстреливать!
(ну может 30 строк. Или 10. Не принципиально)
Уж извините. Но иногда длинные функции это как раз то что нужно для решения проблемы. Короткие функции конечно обычно проще понять. Но порой алгоритм действительно проще выразить одной длинной функцией. И не нужно усложнять код сокращая длину функций чтобы соответствовать произвольным стандартам.
прим. - Китайская стена вещь длинная. Но простая. Но длинннааааяяяя...
4. Patterns?Patterns:!Patterns->Patterns(Patterns:....
Если в функции используется меньше трех паттернов - функцию нужно переписать. До достижения положенного минимума...
Те кто выискивает возможности применить шаблоны просто добавляют в код ненужную сложность. Наоборот, перед применением в коде очередного шаблону нужно подумать и попытаться обойтись без него, более простыми средствами. Поскольку каждый шаблон увеличивает сложность. Но разумеется шаблоны в коде могут быть, никто их у вас не отнимет.
(прим. мысль хотя и ясна но вот обоснована не ахти.)
5. Посдчет CPU инструкций - моя прелесть! И только язык который дает возможность работать на достаточно низком уровне имеет право на существование.
Тут даже переводить не буду. Ибо мотивация этого "антипаттерна" сама по себе ущербна. В оригинале (если тут может быть оригинал) похожий принцип звучал так: "все беды от преждевременной оптимизации". Здесь же слово "преждевременная" вообще убрали из контекста. Получилось в результате еще хуже чем было...
6. Много точек выхода из функции - зло.
Такое часто можно услышать. Время от времени на множественные точки выхода даже объявляются крестовые походы. Под знаменем написано - "если точка выхода одна то код легче оптимизировать". Кому легче? И чем? Анализировать легче код который сам по себе прост. И если множественные возвраты из функции добавляют простоты - да пользуйтесь на здоровье.
автор забыл про goto...
Кстати забавно что в обсуждении привели следующий пример правильного использования множественных возвратов из функции (переписываю на псевдокоде):
something foo(object a,object b)
{
if(!a.initialized) return "foo";
if(!b.initialized) return "foo";
return a.bar()+b.bar()
}
приматы... не понимаете проблемы не пишите.
return (a.initialized && b.initialized)?a.bar()+b.bar():"foo";, ага...
7. Ваши пользователи идиоты. Клинические.
Вам даже сложно поверить в то какие они имбицилы. Они постоянно забывают как делать в вашей программе простейшие вещи. Постоянно используют вашу программу неправильно. И это приводит к ошибкам. Главное тут помнить что идиоты именно пользователи. А не разработчики которые были не в состоянии написать нормальную программу.
RTFM moron...знакомая фраза, правда?
8. Вы пишете много кода. И гордитесь этом.
Продуктивность оно конечно хорошо. Но увы, продуктивность и количество написанных строк кода слабо между собой коррелируют. Пользователи никогда не скажут "Хм, продукт багнутый, разобраться как его использовать нереально, но зато посмотрите! сколько кода". К тому же извержение тонны кода приводит к тому что другие разработчики тратят кучу времени чтобы разобраться с этими мутными потоками кода. Про поддержку в будущем можно думаю даже не упоминать.
все правильные менеджеры знают что платить программистам нужно построчно.
9. Copypaste - так создается отличный код!
Вы стойко отстаиваете свое право на "copypaste", оправдывая это странными аргументами по типу "декомпозиция связей" и "уменьшение зависимостей". Поддержка и отладка багов вторичны. Вы не кривя душой называете это "рационализацией".
10. Обработка ошибок это просто! Перехвати все исключения, запиши в логи и продолжим...
Это не обработка ошибок. Это игнорирование ошибок. Семантически это эквивалентно “on error next” в VB. То что вы занесли ошибку в програмные логи не значит что вы ее хоть как-то обработали. Обработка ошибок вообще непростое дело. Если вы точно не знаете как обработать (именно обработать) ошибку - пусть она идет дальше. Может и обработают.
Ошибка! Подача топлива резко увеличилась! Запись об этом будет занесена в бортовой журнал. Последней. Продолжаем процесс воспламенения поданного топлива...
11. Ни строчки кода без UML диаграммы.
Наибольший энтузиазм в UML моделировании проявляют как правило те кого врядли можно назвать даже хорошим кодером. Но при этом они хотят чтобы их считали программными архитекторами. К средствам моделирования кода в основном аппелируют те кто свято верят что все кодирование можно сделать путем манипуляции маленькими квадратиками на экране (прим. по сути это верно. только не квадратиками а символами:). Все эти диаграммы это не есть дизайн. И никогда не будет дизайном. И не заменит код.
12. Ваш код убил билд или важные данные.
Иногда вы пишете код которые как вы полагаете должен переписать файлы приложения. Но все идет не так и в результате часть данных пользователя убита.
Все пишут такой код. Иногда. Все иногда попадают в категорию ущербных программеров. Важно в ней не оставаться.
Комментариев нет:
Отправить комментарий