5-те най-големи грехове на PHP програмистите

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

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *


*