Недавно по наследству от грязного, вонючего контрактора (который утверждал, что его знания и умения так хороши, чтоб не трогать его пока, он не закончит проект) мне досталось веб-приложение. К сожалению, мы поверили ему на слово. На первый взгляд большинство функционала веб-приложения работало как надо. Однако, как только клиент начал использовать приложение в реальных условиях, –
Я решил описать некоторые из тех ошибок, с которыми столкнулся. Это ошибки, которые, каждый хороший программист давно уже должен уметь избегать… но, очевидно, что некоторым людям нужно о них напоминанать.
#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. Кто хочет добавить еще пару пунктов?
