Про индусов
Если вы программист, или какое-то отношение к ним имеете, то вы наверно встречали индусов, а точнее “индусов”. А именно тех еб^Wнехороших людей, которые пишут совершенно отвратный код. Так о чем это я. Короче, устал я от ковыряния кривоработающих компонентов своих проектов – будь это что-то рабочее или “быдлокодерское” (фрилансерское). А устал именно от того, что эти компоненты написаны тяп ляп и постоянно убиваешь кучу времени на то, что фиксишь баги в этих компонентах или адаптируешь их под себя. Я бы сказал немеряно времени, бывает, что сильно больше, чем реализация чего-то непосредственно касамеого самого проекта.
Например, коврял тут плагин для modx’a – DirectResize. Насколько я понял, этот плагин был написан французом, но блять, как написан. Плагин занимается тем, что уменьшает добавленные фотки на страничке, находящиеся в указанной директории на сервере, и делает из них тумбы заданного размера. Также по возможности он интегрируется с lightbox’ом, что в принципе мне и нужно было. Провозился я с ним из-за того, что эта сцуко не хавала картинки, у котороых в src был абсолютный путь. Т.е http://bla.com/assets/images/bla/bla.jpg не хавались (узнал я это через час после курения всяко разных доков и форумов), а нужно было писать assets/images/bla… Но нигде об этом не было написано. Ну что ж нам не привыкать, лезем в код и видим:
, где lien_img – содержимое аттрибута src, а lien_base – собственно каталог с чем с ранивать. Очевидно, при таком расскладе получаем, что картинка может иметь только относительный адрес, а вот сцуко редактор (TinyMCE в том числе) переписывал src с относительного в абсолютный. Блять, не ужели сложно было добавить лишний strpos, чтобы сначала проверить, есть ли в абсолютном адресе тот каталог, который нужно проверить, и потом тупо обрезать substr’ом абсолютную часть (если это реально надо)?!
Чувак набацал код, который работает только в одном случае, и не работает в другом. При чем, варианта всего два (ну три с натяжечкой, если еще рассматривать случай сильно “глубоких” каталогов). Сложно блин было это учесть? Даже ладно. Пусть не учел, но какого х*я он не упомянул об этом в доке?
Все это мелочи конечно, но когда подобное встречаешь чуть ли не каждый день – надоедает.
Меня вот учили и книги, и учителя, и преподаватели всегда рассматривать всякие критические случаи – первое, что надо делать при тестировании программ. Поэтому изначально, дабы не находить скрытые ошибки в уже написанном коде при тестировании, я стараюсь все сначала спроектировать и зарываюсь в самые дебри и детали. С одной стороны это плюс конечно, а с другой и довольно большой минус. Минус в том, что если проект большой, то я на нем долго зависаю обдумывая его. Это из разряда, что человек в сознании может держать 7+-2 объекта. А у меня наверно происходит overflow и я начинаю жестко тупить и тормозить
Для решения этой проблемы человечество придумало разные способы – одно из самых надежных, работающих и простых – деление задачи на поздачи. Т.е от более крупного переходят к более мелкому. Уже наверно как полгода, я учу себя использовать такой подход, вроде бы даже немного успешно. Хотя привычки дают о себе знать. Да и стиль у меня такой мышления – дедуктивный – сначала должен понять как работает что-то в целом, понять все взаимосвязи, всё всё всё, а только потом уже разбираю всё по-отдельности. Я думаю, что хороший подход, но нужно умело этим пользоватся.
Естественно я не супер пупер кодер, косяки у меня случаются тоже, но я стараюсь чтобы их не было.
PS: Никак не могу найти кошерную тему для блога, особенно адапатированную к 2.3 и виджетам. А то уж больно нравится tag cloud.

Leave a Comment