Так получилось, что пока я учился в школе и университете я постоянно пилил какие-то проекты. О наиболее странных косяках в них я и хочу вам рассказать.
webMCRex
webMCRex - это мой первый продукт, ушедший в массы. За три года разработки в нем накопилась уйма мест, за которые стыдно до сих пор.
Класс-прослойка для БД
В те далекие времена PHP 5.4 появилось deprecation warning для стандартного соеднения через mysql_connect()
, что привело к рождению кода такого вида:
1 | class DB { |
Это - грубейшее нарушение принципа открытости-закрытости из небезызвестного SOLID. Я сам не любитель следовать каким-либо паттернам, но тот же SOLID без необходимости нарушать не имеет смысла. Упуская сомнения в необходимости сего деяния, это - просто отвратительный подход. Увы, этот класс практически без изменений перебрался и в базу званий Метростроя, и в IssueTracker. На тот момент, правда, я плохо понимал принцип работы наследования в PHP, но если и реализовывать это так, то надо было реализовывать через интерфейс и два дочерних класса.
1 | interface DBProvider { |
Использование глобальных переменных
В webMCR изначально довольно много инфы было доступно в глобальном пространстве.
webMCRex дописывался процедурно и очень активно работал с глобальными переменными, добавив много новых, своих…
Это был плохой подход: нередко код имел доступ к тому, к сему не должен или случайно перезаписывал глобальные переменные.
Много, ОЧЕНЬ много логики в шаблоне
Это скорее не об какой-то безопасности, а просто о красоте кода.
Все-таки шаблон - это место для вывода информации, а не для выполнения логики.
Однако, в webMCRex иногда присутствовал, например, перебор по результатам mysql запроса.
Не фатально, но некрасиво.
WorldsOfCubes
Появившись на полгода раньше webMCRex, проект пережил многое. Изначальная его идея - это реализовать по сути что-то типа OpenID для комплексов серверов и дать игроку возможность иметь один аккаунт для всех серверов. Увы, проект был изначально провален как из-за очень позднего старта, так и из-за низкой выгоды присоединения к нему.
Безопасность через неясность
Было тонкое дело, которое я не знал как разрешить: как сделать токен, который будет всегда валиден, но при этом однозначно указывал, на согласие конкретного пользователя зайти на конкретный проект. Для этого токен генерировался из никнейма и секретного ключа проекта, на который он хочет зайти.
1 | $token = md5(md5($player . $proj['security_key'])); |
Путь слабоумия и отваги сладок…
Metrostroi
Сайт Метростроя был первым моим проектом, который был написан почти полностью с нуля.
Совпадения токенов авторизации у разных пользователей
Авторизация была реализована на специальных токенах, которые генерировались как рандомная строка из 128 символов вот так:
1 | $sessionID = Base::randString(128); |
Токен обновлялся при каждой перезагрузке страницы, что давало немалую вероятность совпадения токенов у разных пользователей.
Со временем ситуация ухудшалась, токен перестали обновлять при перезагрузке страницы, но это полностью не исправило проблему.
Решено было довольно просто:
1 | $sessionID = $player->steamid . "_". Base::randString(100); |
Вывод - не ждите рандома от рандома
Непрофессионализм и рофлы в коде
Когда все начиналось, я, честно говоря получал удовольствие от работы.
Именно тогда появились в коде рофлы типа переменных $tox1n_lenvaya_jopa
, $typical_ple
или такие вот проверки:
1 |
|
Да, это все непрофессионально. Не стоит так делать.
Так это… К чему это я…
Мой путь всегда был полон стыдного кода. И работа над тем кодом дала хороший опыт что лучше не делать.
Нельзя бояться сделать что-то не так - любой говнокод даст опыт.
Важно со временем перестать его писать. А это уже непросто.
Увы, даже среди опытных программистов есть те, которые отгружают говнокод цистернами. И вот это уже плохо.