Тази книга описва необходимите стъпки за модернизирането на остаряло приложение. Дава добро описание на понятието “legacy”, както и защо трябва да бъде модернизирано. Самите стъпки са добре подбрани, макар че ми се искаше примерното приложение в книгата да придобие още по-завършен вид. В крайна сметка крайният резултат доста наподобява това, което представляват повечето модерни MVC frameworks, но в по-опростен вариант. Истинската полза от изброените стъпки е това, че се разбира защо е необходимо да се предприемат, обяснени са подробно, както и след всяка глава има въпроси и ситуации, които могат да възникнат. Това, което ми липсва, обаче са неща, които са споменати в книгата като възможно развитие, но изрично е посочено, че няма да бъдат описвани и са дадени препратки към други материали по темата. Това са неща като testing frameworks, data mapper / active record database patterns, domain driven design. Липсва ми и отделна глава относно конфигурация на приложението за различни среди (само се споменава), както и error handling. Има и неща, които са излишни и идват в малко повече (споменават се почти във всяка глава): как и какво точно да търсим в кода на целия проект когато се заменят разни структури; кога да направим commit и да известим QA отдела; кога да искаме помощ или какво да кажем на operations отдела за промени по конфигурацията на сървъра и др. Като най-полезни мога да определя четири от стъпките, които виждам доста често, че се пренебрегват при разработката на приложения или просто не са усвоени: 6. dependency injection, 7. tests, 16. dependency injection container.
Накратко главите/стъпките представляват следното:
1. Въведение какво представляват “legacy” приложения; аргументи и бизнес нужда от това да се модернизират; защо трябва да приложим refactor с малки стъпки вместо цялостен rewrite; даден е пример с приложение изградено с отделни page scripts, много include-и, липса на класове.
2. Предварителна подготовка: как и защо да вкараме кода под version control; коя PHP версия да използваме; избор на програма за разработка; стил на подреждане на кода и защо това е важно.
3. Първата реална стъпка от процеса по модернизиране – използването на Autoloader; къде да си държим класовете; споменават се autoloading стандартите PSR-0 и PSR-4.
4. Събирането на всички класове, използвани в приложението на едно място. Както и създаването на статични класове от функции.
5. Заменяне на обекти вкарани с “global” с такива вкарани като зависимости през конструктора на класове или функции. целта е класовете да извършват конкретни, изолирани от външни обекти функции, които да могат лесно да се тестват с unit тестове.
6. Подобно на предишната стъпка, но тук дават пример с изнасяне на обекти създавани с “new”, както и използването на Factory класове, а не директно инстанцииране.
7. Кратко въведение в писането на тестове. една от основните стъпки по модернизацията на приложението тъй като на тези тестове се разчита за проверка дали всичко работи нормално след всяка една стъпка.
8. Преместване на SQL заявки от кода в Gateway класове; използване на PDO за абстракция при връзка с базата; споменава SQL injection уязвимост и как да се предпазим, използвайки bind на параметри и prepared statements.
9. Създаване на domain обекти или модели (тук се използват Transactions за по-лесна трансформация), които използват gateway-ите от предишната глава за работа с базата и в тях остава единствено бизнес логиката на приложението.
10. Изнасяне на всичкия изходен код (html, json) във view файлове. споменава се защита от XSS уязвимости.
11. Създаването на controller-и като част от Model-View-Controller шаблона.
12. Процес на премахване на всички останали include извиквания в класовете.
13. Отделяне на публичните ресурси в отделна директория и настройка на уеб сървъра за използването на front controller за достъп до вътрешните скриптове/контролери; споменават се рисковете от това всички файлове да се намират в document root директорията на уеб сървъра.
14. Продължение на предишната стъпка – създаване на routes файл описващ всички адреси достъпващи приложението и кой controller/action да използват.
15. Премахване на останалата повтаряща се логика.
16. Създаването на dependency injection container – място, в което са събрани всички създавания на обекти. Продължение на inversion of control техниката. Много мощен инструмент, който позволява да се използват различни начини на взимане на обект – нова инстанция, преизползване на вече създадена, както и автоматично вкарване на зависимости в класове.
17. Съвети за продължаване на подобренията, включително конвертиране към използването на framework.
Плюсове:
+ ясно аргументира нуждата от модернизиране или постоянно подобряване на приложенията
+ показва конкретни стъпки как да се постигне
+ показва добри практики при разработката на приложения
+ показва как приложението да остане стабилно и работещо, докато се правят големи промени, чрез използването на тестове
+ показва различни design patterns за организация на кода
Минуси:
– липсват важни стъпки
– някои от стъпките не са развити достатъчно подробно
– често се повтаря маловажна информация
Оценка: 3/5
Като цяло съм леко разочарован тъй като съм видял доста препоръки за книгата, а очаквах малко повече. Препоръчвам я за разработчици, които не са имали досег с различни модерни frameworks.