Теперь я быдлокодер…
На позапрошлой работе я был авангардным экспериментатором, спасибо Мозилле и госзаказам, зато теперь у меня есть возможность почувствовать себя быдлокодером. Почему я пишу быдлокод? Дело тут не в невежестве, а то я бы просто не понимал, что творю. Думаю, тут три причины. Во-первых, неопытность в применяемых конкретных фреймворках. Во-вторых, безумная спешка разработки, которая, как меня уверяют, ещё катастрофически недостаточна. В-третьих, исходная кривость фирменной библиотеки классов, фреймворков и самого языка. Вот на тему последнего пункта и я хочу рассказать пример.
В некоем дорабатываемом мной классе определяется скалярное строковое свойство. Не замышляя ничего худого, я пытаюсь им воспользоваться в одном из методов и обнаруживаю, что там уже лежит массив! Что за чёрт?
Оказывается, в базовом классе фреймворка это свойство предполагается (по неким разумным причинам) массивом. Обнаруживая, что в нём лежит скаляр, фреймворк втихомолку пихает его в массив и перезаписывает этим массивом. По-моему, основание говорить о кривости фреймворка, а? Порядочный фреймворк в моём представлении кинул бы исключение или хотя бы предупреждение.
В общем в свойстве оказывается массив. В чём тогда смысл инициализировать его скаляром? Видимо какому-то моему предшественнику хотелось упростить запись. А чтобы и дальше пользоваться скаляром он прописал в промежуточном фирменном классе (который наследуется от базового и от которого наследуются соответствующие классы в проектах) код, перехватывающий этот скаляр, пока фрейморк с ним ещё ничего не сделал и записывающий его в новое свойство с других, хотя и похожим именем. Очаровательно, не правда ли? В результате в классе наличествуют два более не связанных между собой свойства, отражающих по идее одну сущность (хорошая подлянка для того, кто надумает её динамически менять), а в конкретных классах инициализируется одно свойство, а значение затем берётся из другого.
По-моему, тут следовало действовать прямо наоборот: инициализировать (и затем использовать) своё свойство, а в фирменном конструкторе записывать его в стандартное, в подобающем виде массива. А чтобы избежать их рассинхронизации, закрыть их от модификации и осуществлять доступ сугубо через сеттер/геттер. А ещё лучше - вовсе не связываться; записан в стандартном классе массив, ну так и работать с массивом.
Я не виню своего предшественника, я не знаю (и знать не хочу), кто это - халтурщик, надеюсь, уже отсутствующий в фирме, или хороший программер. Полагаю, у него были те же причины, что и у меня. О том, что этот код писался в ещё более бешеном темпе, чем я его разбирал, свидетельствует и совершенно немыслимая ошибка в том же фрагменте: там используются две стандартных функции для работы с массивами, но… без аргумента; его просто забыли прописать. У меня ум за разум зашёл, когда я пытался постичь, зачем так написано и как оно может работать. Последнее и есть, по-моему, свидетельство кривости языка: ему следовало ругнуться, видя заведомо бессмысленную конструкцию. Тем более, что я чуть ли не первым делом включил строгий режим отслеживания ошибок.
А происходит такое плачевное положение дел из-за состояния рынка: клиенты не способны оценить качество продукта, не задумываются о его будущем функционировании, поддержке и развитии, заставляя разработчиков соревноваться, кто сделает нечто похожее на его ожидание дешевле и быстрее. Ну, а дешевле и быстрее, конечно, и получается чёрт знает что, накапливающее баги и ужасающее своего создателя.
P. S. На самом деле, всё ещё хуже, чем мне показалось. Если написать в объявлении своего класса даже не $_primary_key="имя", а $_primary_key=array("имя"), неугомонный фреймворк не оставит сие свойство нетронутым. В некоторый момент (в методе _setupPrimaryKey()) он из каких-то своих побуждений перенумерует этот массив с единицы. То есть до этого момента к имени первичного ключа нужно обращаться как $this->_primary_key[0], а после - $this->_primary_key[1]. Ну не ужас ли? У него семь пятниц на неделе, у этого фрейворка! Кстати, создать модель для таблицы, не имеющей уникального ключа, эта вражина не даёт в принципе. Даже если апдейтить таблицу не предполагается и ключ на практике никогда не потребуется.