Незнам дали мога да обявя себе си за хейтър, но определено след всеки изминал ден ставам все по-критичен що се стигне до обектно-ориентирана архитектура и качество на код. Често ми се налага да реагирам остро в дискусиите си с нисши форми на разум, като най-често оставям клетите и изгубени в заблуда души сами да се опарят от собственото си невежество, като тихичко накрая им шушна „Нали ти казах?“. В течение на времето започнах да забелязвам едни и същи тъпи грешки, които всички задружно допускат, че даже не им прави впечатление. Реших да събера есенсията от тези грешки като представя 5-те най-големи и непростими грехове на PHP програмистите.

1. Логика в контролерите

Контролерите не са мястото, където трябва да пишете логиката си. Контролера работи с модели, които съдържат логика.

Обичайните признаци за тази грешка е присъствието на SQL заявки в контролерите, обработка на файлове, изчисления и други операции, чието място не е в контролера.

Обичайното извинение на грешниците е:

„Ами аз нямам време да се занимавам с някакви си там модели, клиента чака!“

А когато ти се наложи глупако, да използваш същата логика в друг контролер, какви ще ги вършиш? Ще копираш код ли?

Като съвет, който бих дал на всеки прегрешил е да разпределя логиката си в модели, с които също трябва да се внимава (един модел трябва да върши само една задача или област от много сходни задачи). За най-добрите практики в разпределянето на логиката всеки заинтересован може да прочете Patterns Of Enterprise Application Architecture.

2. Използване на Unix Timestamp в MySQL

В MySQL съществуват два много удобни формата за запазване на date/time стойности. Единият е TIMESTAMP, а другият е DATETIME. За съжеление множеството от програмисти никога не са ползвали тези времеви типове, а записват времеви стойности в INT поле като Unix Timestamp.

Защо Unix Timestamp е лош избор в MySQL?

Защото е грозен. Ето, казах го! Unix Timestamp е грозен формат (да, да… знам колко е гъвкъв, фундаментален, знам, че може да го преобразуваш в какъвто формат искаш, бла-бла-бла). Не е четим от човешки същества, и в MySQL съществуват легални алтернативи. Също така в комбинация с PHP функциите date() и mktime() нещата могат лесно да излезят извън контрол с големи грешки заради несъответствия в настройките на времевите зони на PHP и MySQL.

Както споменах по-горе, в MySQL съществуват два времеви типа TIMESTAMP и DATETIME. И двата формата запазват дата и време, но TIMESTAMP е зависим от времевата зона. Тук можете за да прочетете за разликите между двата типа.

Моят съвет е винаги да използвате DATETIME/TIMESTAMP когато трябва да съхранявате дата и час. Тези формати разрешават употребата на MySQL времевите функции, които са мощни и удобни. Не забравяйте да индексирате (и то правилно) ако правите селекция по времево поле.

3. Коментиране на код

„Този код може би ще ни потрябва в по-късен етап, нека да го закоментираме“ – из разсъжденията на един грешник

Хора, използвайте системи за контрол на версиите (git, hg, svn). Няма нищо по-грозно от това да видиш закоментиран код, оставен за поколенията.

4. Неправилно наследяване

Често се натъквам на много нелогично наследяване. За пример имаме система и програмиста е решил, че всеки негов клас ще наследява някакъв абстрактен и много велик клас. Нека наречем този клас AbstractPieceOfShitModel. Често в този клас ненадейно е попаднала логика за работа с база данни и какви ли не други несъответстващи си методи.

Лошото е, че наследяването на този клас присъства навсякъде, дори когато даденият модел няма връзка с база данни. Програмиста просто наследява този AbstractPieceOfShitModel за всеки случай.

Вината не е изцяло на обикновените програмисти. Вина имат водещите PHP фреймуъркове (с изключение на Zend разбира се, Praise Hail To Our Saviour Zend Framework) като CodeIgniter, CakePHP, Yii и всичките, които налагат идеята, че има някакъв вид универсален скелет на модел, който могат всички класове да ползват чрез наследяване. Няма универсален скелет на модел (ако сте запознати с философията на Test-Driven Development, ще разберете защо). Това освен да ви върже ръцете и ограничи креативността няма как да помогне.

5. Работа с Windows

Ако си PHP програмист – трябва да работиш с Linux (всъщност това важи за всички освен за .net-аджиите. Те просто нямат избор).

Линукс като работна среда дава много предимства на PHP програмистите. Ето само малка част от тях:

  • Лесна конфигурация на PHP, Apache(или който и да е друг сървър), MySQL и т.н.
  • Обвивката на Линукс (shell) предоставя възможност за писане на мощни скриптове, които да помогнат в процеса на разработка
  • Лесна инсталация на LAMP (Linux-Apache-MySQL-PHP/Perl/Python) и лесно обновяване. В Windows почти всеки играе с XAMPP или подобен пакет
  • Много разширения и библиотеки за PHP се срещат като пакети в Ubuntu/Debian. Това значително ускорява процеса на разработка.

Заключение

Разбира се нещата, които ме дразнят са далеч повече, но това са главните 5, за които всеки трябва да си даде сметка.