10 способов облажаться в программировании

[MaSe]

http://habrahabr.ru/blogs/development/94112/#habracut" onclick="window.open(this.href);return false;

Недавно по наследству от грязного, вонючего контрактора (который утверждал, что его знания и умения так хороши, чтоб не трогать его пока, он не закончит проект) мне досталось веб-приложение. К сожалению, мы поверили ему на слово. На первый взгляд большинство функционала веб-приложения работало как надо. Однако, как только клиент начал использовать приложение в реальных условиях, – весна показала, кто где срал оно начало барахлить. Контрактор исчез после оплаты (умри репутация!), а я остался, чтобы попытаться починить то, с чем пока мучился клиент.
Я решил описать некоторые из тех ошибок, с которыми столкнулся. Это ошибки, которые, каждый хороший программист давно уже должен уметь избегать… но, очевидно, что некоторым людям нужно о них напоминанать.

#10 — Не храните настройки в конфигурацонном файле

Когда вы пишете масштабируемые приложения, такая информация, как параметры соединения с базой данных и адрес SMTP сервера, будет использоваться во всем приложении. Чтоб наверняка защитить ваше приложение от дальнейшей поддержки, переопределяйте эти параметры каждый раз, когда они вам нужны. Вместо того, чтоб вынести их в файл конфигурации (Web.config или любой другой), просто разбросайте их по всему проекту. Тот, кому в дальнейшем достанется ваше приложение, будет благодарить вас за плутание в тысячах строк кода, чтоб всего лишь изменить имя SMTP сервера. Куда веселей, когда следующий программист находит имя сервера только в 14 из 15 мест, а то, последнее 15-ое место где-то в глубине кода заставляет приложение работать неправильно. Иногда полезно строить название параметров из непонятно как слепленных строк. Активное партнерство нового разработчика и недовольного клиента будет способствовать укреплению их взаимоотношений. И если не вы, то кто создаст предпосылки для этой тесной дружбы?

#9 — Не храните переменные в [любой] памяти

Одно из преимуществ баз данных – это то, что они хранят информацию и позволяют получить доступ к ней всякий раз, когда вы в ней нуждаетесь. Чтобы убедиться, что ваше приложение ну просто ужасней некуда, обращайтесь к базе данных каждый раз, когда вам нужен хоть небольшой кусок информации. Чем чаще вам нужна эта информация, тем лучше – создавайте все новые и новые соединения с базой данных. Общая информация о пользователе системы – больше всего подходит для этого. Не пытайтесь сохранить информацию о пользователе, вроде «isAdmin», присвоив значение какой-то переменной и используя ее на протяжении всего текущего запроса. Соединяйтесь с базой данных каждый раз, когда вам нужно что-либо узнать о пользователе. В конце концов, клиент заплатил за эту базу данных, и мы должны выжать из нее максимум возможного!

#8 — Используйте хитрые плагины

Если у клиента нестандартные требования, например, форматирование таблиц которое не может сделать ваш WYSIWYG редактор (colspan – это трудно), вы определенно должны найти в интернете редкий неподдерживаемый плагин без исходного кода, которые выполнит за вас работу. Чтоб написать такой же самостоятельно – вы потратите почти целый час; лучше потратить три часа на поиск плагина, который делает примерно, но не совсем то, что вам требуется. +1 в карму, если вы сможете найти плагин, который не делает то, что вам нужно, но предлагает 15 МБ + возможностей, которые вам не нужны, однако которые нельзя убрать. +2 в карму, если документация для этого плагина написана на языке, который вы не знаете.

#7 – Никогда не удаляйте функциональность

В ходе разработки больших приложений есть моменты, когда функциональность над которой вы работали, уже не требуется. Чтоб оставить тупики и лабиринты для тех, кто будет в дальнейшем работать над этим приложением, не удаляйте эту ненужную функциональность. Можно даже в случайном порядке закомментировать некоторые небольшие куски, или даже сотни строк этого кода, но не удаляйте его. Представьте себе часы приятного препровождения будущей команды этого приложения, когда они будут распутывать клубок вашего кода и обнаружат, что он вообще не нужен! Если вы сможете сделать это так, чтоб выглядело так, что код вроде бы как нужен, а на самом деле – нет, ваш преемник побоится сам удалять такой код… Вот это будет весело! Ах, опять же бонус… если ваш проект использует средства контроля версий и несколько серверов, убедитесь, для каждого сервера и системы управления версиями — версии файлов разные (как исходники, так и бинарники). Так никто не узнает, какая версия в продакшен, а кому неохота поиграть в русскую рулетку на продакшен сервере?

#6 — К черту производительность

Большие приложения, как правило, используются для работы с большими объемами данных. Конечно, во время разработки вы создадите 20 или около того тестовых записей. Бьюсь об заклад, что нет ни малейшей необходимости беспокоиться о том, что происходит, когда у вас 25 записей, или даже 1000! Очевидно, если разбить данные на страницы — все будет прекрасно работать и производительности всегда будет отличной. Так что, если приложение компилируется, смело отдавайте его заказчику!

#5 — Запихивайте основную логику/функциональность в циклы

Как мы уже заметили в #6 — мы работаем с большими объемами данных. И неизбежно часто нужно будет пробегать по данным в циклах. Чтоб ваше приложение действительно было трудно поддерживать, вы должны вставлять основные функцонал и/или логику внутрь циклов. Например, вместо того, чтобы сделать запрос к базе данных, закинуть все данные в память и пройтись по массиву данных в цикле, получите все данные за исключением одного поля и пробегитесь в цикле по ним… Затем, в следующем цикле, вы должны опять получить все данные из базы, но на этот раз включить еще одно дополнительное поле. Это будет гарантией того, что ваше приложение ляжет от пяти одновременно работающих пользователей (Re: # 6). Закрепим материал: получите данные> создайте цикл> получите данные> работайте с данными. Уверен, что этот наработка позволит добиться полнейшего идиотизма, поэтому не стесняйтесь использовать сей хитрый прием столько раз – сколько вам захочется.

#4 — НИЧЕГО не документируйте

Всем известно, что документация – это для дебилов. Что я хочу сказать, — либо вы можете прочитать код, либо вы не можете, так? (именно так было мне сказано в одном разговоре) КОНЕЧНО ЖЕ, следующий программист сможет прочитать код. Становится интересно, когда вы абсолютно не пишите комментариев, — что, для чего, почему? Пусть теряются в догадках. Вы таинственны, как ниндзя. Не нужно, чтоб кто-то знал все о том, что вы пытались сделать. Потому что, если вы написали, что собираетесь что-то сделать, а в конечном не делаете это… ну… это просто неудобно.

#3 — Используйте нелогичные имена переменных

Если для работы над приложением нужно много переменных, необходимо выбрать фильм или телешоу в котором достаточно персонажей – вы будете использовать их имена, как переменные. Властелин колец, Звездные войны и Гриффины – отличный выбор. Может быть, вы даже сможете подружиться с переменными. Тогда вам не придется их убивать! Вы можете создать переменные-хамелеоны – и тогда вы сможете обнулять и присваивать им каждый раз что-то новое, когда потребуется переменная для новой функциональности. Они будут расти и развиваться прямо на ваших глазах! Опять же, поддержите гринпис и партию зеленых – используйте минимум переменных!

#2 — Ловите все ошибки — и ничего не делайте с ними

В наше время большинство языков/платформ имеют встроенный механизм обработки ошибок. Если программа падает — она оставляет достаточно подробные сведения через стандартный поток ошибок. Но вы не можете оставить это просто так! Начните с упаковки каждого небольшого кусочка функциональности в try/catch. А потом внутрь… catch вставьте комментарий, вроде "/ / Тут полнейшая лажа".

#1 — Дублируйте функциональность

Если клиент сообщит вам, что им нужно 2 страницы: одна для администратора – где список товаров с кнопкой удалить напротив каждого товара, и одна для обычного пользователя – список без кнопки «удалить», вам обязательно нужно создать 2 отдельные страницы. Вообще-то, если вы можете сделать отдельную страницу для каждой группы пользователей – это еще лучше. Создание отдельной страницы для каждого пользователя — это 100% успех. Сосредоточтесь и серьезно отнеситесь к делу, так как это ваша последняя линия обороны против орды квалифицированных специалистов, которые неизбежно будут недоуменно пытаться улучшить тщательно спроектированный ящик Пандоры внутри вашего приложения.

Это отнюдь не исчерпывающий список. Только на этом проекте я мог бы назвать еще 10 отстойнейших вещей. На этот раз я оставлю 10. Кто хочет добавить еще пару пунктов?

[Ensase]

бред
всё что сказано это общие слова и смысл зависит от контекста
лучше бы дали полезные советы

[Любовь Д]

:) Это как "Вредные советы" Г. Остера для детей :)

[Sani89]

никакой конкретизации. смысл есть а толка мало.

[Count_Raven]

бред
всё что сказано это общие слова и смысл зависит от контекста
лучше бы дали полезные советы

Да это правда жизни. Больше и не надо. Так и есть. Вы просто не работаете в больших городах с давними проектами - там вот такой писец и имеется. Бывало так, что объяснял заказчику: - в текущем состоянии система не способна развиваться, данные хранятся в файлах, а ваши запросы на 1000 человек в минуту (каждый из которых совершает около 50 запросов) с этим несовместимы. Пол года работы, переписка системы с ноля, модульная архитектура, туда-сюда, короче вот как-то это решается. К сожалению, клиент не хочет платить за полностью новый проект, он хочет, чтобы из существующего говна сделали конфетку. Это невозможно, поэтому делается какой-то конвертер-враппер который пытается изображать из себя что-то серьезное. Смешно, что это компании у которых оборот 30-50 миллионов в месяц минимум... Печально, что они такие тупые.

[Ensase]

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

[NIKola]

...А вообще, я очень хочу, чтобы наша профессия со временем стала такой же инженерной дисциплиной, как, например, строительство - вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем - СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности - х*й в голове медицина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему.... И заметьте, никто не кричит "Судостроители пи...сы не хотят переделать речной трамвайчик в ледокол". Ээээх мечты...

[Count_Raven]

...А вообще, я очень хочу, чтобы наша профессия со временем стала такой же инженерной дисциплиной, как, например, строительство - вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем - СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности - х*й в голове медицина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему.... И заметьте, никто не кричит "Судостроители пи...сы не хотят переделать речной трамвайчик в ледокол". Ээээх мечты...

Сцуко убил!

[gil]

суровая правда жизни. если это пересказать заказчику - то услышишь "сайт - это вам не ледокол или здание, чё там переделывать-то?! просто же плюшку добавить маленькую.".

[ToNick]

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

[e2000]

хоть не считаю себя програмером но

ToNick

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