Вынес несколько вещей для себя из текущего проекта.

• ACL имеет смысл только тогда, когда предполагается изменение или назначение ролей. Если роли заранее известны и не предполагается их динамически менять – фпень.
• Старые отточенные куски кода имеют гораздо большую ценность по сравнению с новыми придуманными концепциями, даже если они не совсем вписываются в общую архитектуру приложения.
• Дебаг сложных кусков кода надо делать пошагово и поэтапно, исключая вариант вдумчивого и тяжелого взгляда на код в попытках понять, где косяк.
• Концепт корпоративных сайтов нихрена не меняется со временем. Меняются только технологии.
• Сопрягать два разношерстных скрипта общим размером по мегабайту реально, только если каждый из них написан с минимумом заморочек.

Таки да, если бы я три года назад нахреначил систему комментариев на AJAX, меня бывшее им в то время начальство подвесило бы за интересное место.

Уж сколько раз твердили миру, что человеку нравится та и только та работа, которая у его получается. Однако есть и такая неотъемлемая штука, как стремление к развитию; впрочем есть отдельные личности, которые будут хорошо и без особых возражений делать тупую рутинную работу, но сейчас мы не о них.

Проект нельзя начинать без достаточных ресурсов. Замечательно подмечено, на мой взгляд. Сейчас в нашей организации два с четвертью программиста, из которых я в лучшем случае составляю 0.75 из-за неполной ставки, один верстальщик-интерфейсник и один менеджер-мутант. Задача: за полгода дойти до релиза охренительно огромной системы обучения. С учетом того, что эти же полгода я буду большей частью заниматься учебой, а остальные товарищи не особо сильны в проектировании, в те редкие дни когда я буду заниматься работой, я скорее всего буду только вносить в намеченные планы кардинальные коррективы и практически все время тратить на объяснение, почему это так, а не иначе. Внимание, вопрос: а зачем я вообще тогда буду жопу рвать?

Любой проект без энтузиаста мертв. Наш менеджер-мутант вообще занимается непонятно чем, выполняя роль передатчика между непосредственным заказчиком и нашей командой. При этом помимо этого нового проекта у нас в работе до сих пор находится старый, на который мы уже месяц как должны были положить огромный болт, плюс всякая разная мелкая шушера, которая только отвлекает от полета мысли. Видимо надо ставить себе цель организовывать нашу работу так, чтобы заказчик загорелся желанием поскорее от нас избавиться. Какой уж тут нафиг энтузиазм, когда никто нихрена не делает.

Если у меня появляются силы для того, чтобы писать в блог, это может означать только то, что меня никто не отвлекает на разную ерунду и что на работе я не устал. Сегодня я правда не устал на работе, потому что праздник х)

Часа полтора позанимался своим форумом, о котором слава богу никто не знает – красота, все что написано – работает, что не написано – уже вертится в голове. Сегодня не столько писал, сколько рефакторил то, что было написано до того. Утомительное занятие, но код определенно становится более понятен. Пока что дублированные части кода я решил выносить в хелперы, считаю что подход правилен: если мне покажется что какой-то из хелперов претендует на звание целого класса – перевернуть его до такого состояния не составит труда. Впрочем едва ли это случится.

А еще завтра я читаю мини-лекцию на тему TDD. Не могу сказать что я себя причисляю к касте Test Infected, но разделяю гордость оных по поводу более быстрой и качественной разработки таким методом. Я понимаю откуда берется это преимущество, но в упор не могу представить себя работающим подобным образом. Мой полет мысли как правило выходит на практически общесистемный уровень, в итоге мозг долго-долго грузится и выплевывает такие шедевры, которые потом очень трудно рефакторить в основном из-за т.н. ‘dependency hell’ между модулями. Поэтому я сейчас и взялся насильно внедрять в свой процесс фазу рефакторинга: не нравится как написано? или считаешь, что это может помешать дальнейшему развитию? бери и исправляй. И уж тем более избавляйся от дублированного кода настолько, насколько это возможно. Документирование тоже большой плюс, стараюсь тратить на него не меньше 30% времени. Посмотрим что из этого получится.

Последнее время довелось изрядно попрактиковаться со связкой Kohana + Doctrine, и этот опыт меня весьма порадовал. Приложения пишутся действительно очень и очень быстро – на порядок быстрее, чем я мог написать до того. Конечно, есть и свои сложности, например leftJoin в DQL это фактически не присоединение какой-то левой таблицы, а присоединение именно той таблицы, которая описана в отношении, которое и запрашивается у джойна. То есть мы как бы присоединяем к основному объекту отношение. Все возможные отношения описываются в файле базы – это логично. С другой стороны, это даже еще более логично: не будет соблазна сджойнить то, что сджойниванию не подлежит.

Интересный косяк вылез при трехкратном джойне в запросе: все просто повисло и вылетела штука о превышении лимита памяти %) Сначала забил, потом опять где-то такая же фигня вылезла, начал разбираться – непонятно! А песец подкрался с той стороны, с какой его не ждали, но догадывались: если страницу обработать не удается, кохана тупо трейсит все исключения и выводит в браузер. Но поскольку doctrine это ну очень серьезный ORM, то трейсы его связей очень многочисленны и поэтому нехило грузят ядро коханы и память, в результате именно на выводе ошибки php хавает все положенные ему 128 метров и мирно вываливается. Аминь. Ушел в ядро коханы и закомментарил трейсинг, чтобы не лишиться хотя бы минимальных сообщений об ошибках – все заработало как часы с потреблением памяти меньше 6 мегабайт. Очень доволен собой.

А еще к четвергу готовлю лекцию по TDD. Ололо.

Други мои, откуда вы взяли, что обращение к модели напрямую из контроллера – это ненормально? Откуда вы взяли, что если у меня в проекте торчит модель по чистому паттерну Active Record, то это должно исключать наличие любых Query Builder-ов? Да, возможно в CodeIgniter с его извращенным представлением о моделях это и необходимо, но в той связке Kohana + Doctrine, которую я использую, это не является обязательным – можно писать так, как хочется, главное, чтобы работало. НО, если получается очень много одинакового кода, можно подумать о том, как чисто и безболезненно оформить его в виде дополнительных логических единиц – приватных методов в текущем контроллере, если один и тот же код существует в нескольких методах одного контроллера, или вообще в хелпер или библиотеку, если этот код не имеет большого числа параметров, но используется в нескольких контроллерах. Это же так просто: надо просто делать так, чтобы было лаконично, просто для понимания, работало и при этом не было дублирующегося кода. Всего четыре правила!