PHP: неправильний шлях

image

У світі PHP-програмування існує набір трендів. Деякі люди активно просувають їх (у книгах і на сайтах) як «сучасний PHP», а інші підходи виставляють як застарілі, дурні або просто неправильні.

Схоже, всі ці люди невтомно намагаються змусити кожного програмувати так, як вони вважають за потрібне. Ця стаття написана, щоб поділитися прагматичним поглядом на PHP-програмування. Поглядом, продиктованим досвідом та практичними наслідками, а не популярними тенденціями, теоріями або академічними догмами. Матеріали, представлені на сайті PHP — The Wrong Way, будуть оновлюватися в міру появи нової інформації. Запрошуємо всіх взяти участь в цьому.

Небезпека екстремізму
З правилами та інструкціями з програмування є одна проблема: вони часто мають сенс тільки в конкретних умовах. Якщо вийти за межі цих умов, то гарне правило перетворюється на жахливе. По суті, будь-хороше правило, доведені до крайності, стає поганим.

Важливо розуміти це, тому що екстремісти від програмування часто неправильно використовували багато принципи і правила розробки, які з'являлися час від часу і пропонувалися різними людьми.

Досвід підказує, що невірне використання основних настанов і правил завжди ускладнює проекти, знижує їх безпеку і призводить до помилкових, а інколи і до катастрофічних результатів.

Принцип KISS, який деякі розшифровують як «Keep It Simple, Stupid», — надзвичайно мудрий і правильний, досвідчені люди закликають наслідувати йому. Але навіть KISS може стати загрозою для проекту, якщо довести його до абсурду. Є таке поняття, як зайва простота, що в нашому випадку призводить до нестачі функціональності.

Неправильний шлях: релігійне слідування правилам та настановам.

Постійне використання фреймворків
Всі PHP-фреймворки загального призначення — відстій!
Расмус Лердорф
У PHP-співтоваристві по-справжньому погана тенденція перетворилася в де-факто стандарт при розробці веб-додатків. Мова йде про використання популярних фреймворків загального призначення.

Це явище широко поширилося. Причина тому — не поліпшення результатів розробки і не правильність виконання якихось операцій з точки зору технологій і архітектури. Просто деякі автори фреймворків захопили за собою співтовариство розробників з допомогою полеміки, спрямованої проти створення додатків з нуля. Характерними гаслами стали «Не винаходити колесо!» і «Не треба все робити самостійно, про це вже подбали більш досвідчені».

Багато хто з сучасних програмістів повністю ігнорують фундаментальні принципи нормального програмування і витрачають купу часу, фантазуючи про нових шарах і рівнях складності, щоб стати розумнішими і крутіше тих, кого вони вважають своїми однолітками.

Цим людям настільки подобається вести інших за собою, ставати своєрідними лідерами думок у PHP-співтоваристві, переконувати всіх використовувати свіжі і «модні» open source інструменти, що вони забувають упевнитися в осмисленості та второпності своїх рад. Фреймворк загального призначення можна порівняти із зібраним на фабриці будинком. Будівництво додатки з допомогою такого фреймворку зробить вас кодером або програмістом в тій же мірі, як зведення заздалегідь зібраних будинків перетворить вас в тесляра.

У цій статті ми розрізняємо фреймворки та бібліотеки за такими ознаками:

  • Бібліотека — це набір багаторазово використовуваного коду. Наприклад, стандартні бібліотеки С або Go. Код бібліотеки можна легко і без обмежень впровадити в проект. Вона складається з маленьких фрагментів, у кожного з них є конкретна функціональність.
  • Фреймворк — це не просто набір багаторазово використовуваного коду: ви не зможете вирізати шматок з фреймворку і вставити його в проект. Ця система допомагає створювати, але в той же час накладає на вас обмеження, властиві самому фреймворку. Крім того, у фреймворку чимало взаємозалежною функціональності: одна частина не зможе працювати без інших.
У світі Python і Ruby створення веб-сайтів з нуля — заняття досить нудне, оскільки ці мови для створення веб-сайтів не призначалися. В результаті фреймворки загального призначення, такі як Django і Ruby on Rails, швидко стали популярними саме для сайтобудівництва на Python і Ruby.

А PHP Расмус Лердорф спочатку створював як набір інструментів, написаних на С, що дозволяють легко і швидко розробляти динамічний HTML. PHP таким замислювався і таким залишився, він сам і є фреймворк.

Весь час свого існування PHP активно розвивався, і сьогодні він може використовуватися для набагато більше різноманітних завдань, ніж будівництво HTML і веб-сайтів. Але неправильно ставитися до PHP як до фреймворку. За своєю природою він не є рівнем абстракції для розробки веб-додатків, який повністю написаний на процедурному С.

Використовувати бібліотеки в проектах абсолютно природно. У комплекті поставки PHP йде набір бібліотек, які можуть розширити ваш код. Наприклад, PDO — маленька бібліотека, що надає узгоджений інтерфейс для звернення до баз даних в PHP.

А ось використання фреймворку поверх PHP — зовсім інша справа.

У цьому випадку ви додаєте рівень абстракції поверх іншого рівня абстракції, який спочатку створювався як базова точка відліку. Додатковий рівень, забезпечуваний фреймворком, може просто організовувати ваш код у заздалегідь заготовлені набори шаблонів. Чи може збільшувати складність з допомогою переплетення сотень або тисяч класів і методів у пекельну кашу залежностей. Але в будь-якому випадку ви додаєте в код новий рівень складності, який абсолютно не потрібний!

Набуття досвіду починається з інтерфейсу. Інтерфейс — це результат базових технологій і певної кількості рівнів абстракції. Чим більше абстракції ви використовуєте, тим менш ефективним стає інтерфейс, тим більше помилок ви закладаєте в додаток. Чим вище абстракція, тим більше деталей і ефективності ви втрачаєте.

Чітко усвідомте: рядків коду в будь-якому проекті повинно бути якомога менше, щоб код став якомога чистіше і читабельний!

Людям не потрібні фреймворки загального призначення. Ні в кого немає спільних проблем, кожен намагається вирішувати дуже специфічні проблеми.
Расмус Лердорф
Деякі компанії теж переймаються суєтою навколо PHP-фреймворків та починають використовувати їх у своїх проектах, що в результаті призводить до катастрофи. Компанії стикаються з тим, що фреймворки загального призначення погано допомагають вирішувати конкретні завдання, до того ж дуже повільно працюють. Фреймворки неможливо масштабувати, і багато компаній намагаються видерти з них шматки у відчайдушній надії змусити працювати те, що спочатку не було потрібно.

Завжди використовуйте прагматичний підхід, при якому:

Дія або політика продиктовані розглядом прямих практичних наслідків, а не теорією або догмою.
Словник англійської мови Collins, повна версія, 12-е видання, 2014
Неправильний шлях: завжди використовувати фреймворк поверх PHP.

Постійне використання шаблонів проектування
У мене сильна алергія на відірвані від життя проекти та шаблони проектування. Пітер Норвиг написав хорошу статтю про те, що шаблони проектування — це лише недоліки вашої мови програмування. Перейдіть на мову краще. І він абсолютно правий. Всі поклоняються шаблонів і тільки й думають: «Ага, я скористаюся шаблоном Х».
Брендан Айх. Coders at work — Reflections on the Craft of Programming
Шаблони проектування — це багаторазово використовувані рішення часто виникаючих проблем в архітектурі додатки. Шаблони — це не закінчений проект, який може бути безпосередньо перетворений в код. Це лише опис, ідея того, як вирішити проблему, для використання в багатьох різних ситуаціях. Об'єктно орієнтовані шаблони зазвичай демонструють зв'язки і взаємодії між класами або об'єктами без визначення фінальних класів або об'єктів програми.

PHP підтримує імперативні, об'єктно-орієнтовані, процедурні та рефлективні парадигми. PHP — це величезний ящик з інструментами, що дозволяє вирішувати найрізноманітніші завдання різними способами, а не тільки одним. PHP — це свобода, швидкі і масштабовані рішення.

Намагаючись поліпшити себе і в особливості свій код, іноді ми зациклюємося на філософії конкретних шаблонів або ідей, при цьому забуваючи мислити практично.

Коли я бачу в своїй програмі шаблони, для мене це сигнал про неприємності. Структура програми повинна відображати тільки вирішувану проблему. Будь-які інші закономірності в коді кажуть (принаймні, мені) про те, що я використовую недостатньо сильні абстракції. Наприклад, що я вручну генерую розширення макросів, які потрібно написати.
Пол Грем
Не можна потрапляти в пастку філософії або ідеї, що стоїть за конкретним шаблоном або рішенням. Наше головне завдання — зробити код як можна більш легким для розуміння, а значить, безпечним і простим у супроводі.

Також не можна забувати про існування антишаблонов. Ці шаблони можуть часто використовуватися, але вони неефективні або навіть контрпродуктивні.

Я думаю, спочатку шаблони були якимись впізнаваними кращими рішеннями частих проблем. Але через деякий час ми виявили, що програми стали в десять разів складніше, ніж потрібно, тому що люди намагаються запхати туди всі шаблони, про які вони читали («Моє додаток добре продумано, тому що по горло навантажено шаблонами»). Так що моє уявлення про цінності шаблонів змінилося.
Підлогу Вітон. Evil Design Patterns
Завжди використовуйте прагматичний підхід, при якому:

Дія або політика продиктовані розглядом прямих практичних наслідків, а не теорією або догмою.
Словник англійської мови Collins, повна версія, 12-е видання, 2014
Неправильний шлях: шукати шаблон для вирішення проблеми.

Постійне використання об'єктно орієнтованого програмування
Проблема ОО-мов у тому, що вони тягнуть за собою все своє неявне оточення. Ви хотіли банан, але при цьому отримали горилу, яка тримає банан, і всі джунглі на додачу.
Джо Армстронг. Coders at work. Reflections on the Craft of Programming
Абстракція — це сила. А що мене справді відвертає і про що я говорив ще в 1990-е, так це CORBA, COM, DCOM, об'єктно орієнтована нісенітниця. В той час кожен стартап пропонував якусь божевільну річ, яка при запуску викликала 200 тисяч методів і виводила «Hello world». Це ж пародія! Вам, як програмістам, не потрібно асоціювати себе з такими речами.
Брендан Айх. Coders at work. Reflections on the Craft of Programming
Багато розробники і компанії сьогодні вважають, що ОВП — єдиний виправданий спосіб розробки. А ті, хто з цим сперечаються, негайно усвідомлюють, що йдуть проти «загальноприйнятої думки» індустрії.

Блоги і форуми, присвячені програмування, сповнені захисників ООП, впевнених в тому, що вони розуміють, про що говорять, хоч якого-небудь стандартного визначення не існує.

Але справа в тому, що так зване об'єктно орієнтоване програмування дуже часто буває надмірно складним!

Ми, фахівці з інформатики і програмісти, повинні залишати забобони осторонь і шукати найкраще рішення для конкретної проблеми.

Сьогодні одне з головних переваг PHP — підтримка імперативної, функціональної, об'єктно орієнтованої, процедурної і рефлективної парадигм. PHP — це величезний ящик з інструментами, що дозволяє вирішувати найрізноманітніші завдання різними способами, а не тільки одним.

Коли ми намагаємося вирішувати різні проблеми в рамках програми з допомогою однієї конкретної парадигми програмування, ми перестаємо мислити творчо і ефективно працювати.

Маленький історичний урок
Один з кращих способів зрозуміти парадигму програмування — подивитися, як вона виникла. У чому причина? Із-за якихось проблем в інших парадигмах знадобився новий підхід? Була проблема практична або академічна? І скільки часу пройшло з моменту створення парадигми?

Неважливо, що говорить людина Х або яке визначення дає людина Y. Важливі історичні передумови виникнення парадигм.

Є два шляхи розробки архітектури. Перший — зробити її настільки простий, щоб, очевидно, недоліків не було. Другий — зробити її настільки складною, щоб очевидних недоліків не було.
Чарльз Ентоні Річард Хоар
Раніше, ще до пришестя ООП, приблизно в кінці 1950-х, для створення багатьох програм використовували мови з упором на неструктуроване програмування. Їх іноді називають мовами першого і другого поколінь. Неструктуроване програмування історично став першою парадигмою. Її активно критикували за спагетті-код.

Є і високо-, і низькорівневі мови, які використовують неструктуроване програмування. Наприклад, BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинний код, ранні системи асемблера (без процедурних метаоператоров), ряд скриптових мов. Програма на неструктурированном мові зазвичай складається з послідовно розташованих команд або виразів, зазвичай по одній на рядок. Рядки або нумеруються, або можуть містити мітки, що дозволяють потоку виконання переходити до будь-якої з рядків (зразок непопулярного вираження GOTO). У 1960-х з'явилося структурне програмування, багато в чому завдяки відомому листа Эдсгера Дейкстра Go To statements considered harmful.

Структурне програмування — це парадигма, поліпшує чистоту, якість і процес розробки за допомогою підпрограм, блокових структур і циклів. Це на противагу простому перепрыгиванию вираження GOTO.

Потім із структурованого програмування виникло процедурне. В його основі лежить концепція «виклику процедури». Це ще одна назва для «виклику функції». Процедури також відомі вам як підпрограми або методи. По суті, це серія обчислень, які необхідно виконати. Будь-яка процедура може бути викликана іншими процедурами або самостійно у будь-який час у ході виконання програми.

Спочатку всі процедури були доступні в будь-якій частині програми як глобальні дані. У маленьких програмах це не проблема, але по мірі ускладнення і збільшення програм невеликі зміни в одній частині починали сильно впливати на багато інші частини. Одна маленька зміна процедури могло призвести до каскаду помилок в купі інших процедур, що залежать від неї.

Виникла нова методика, що дозволяє розділяти дані на різні області видимості: «об'єкти». До одним і тим же даним могли звернутися тільки конкретні процедури, що належать до тієї ж області видимості. Це називається відображенням даних, або инкапсуляцией. В результаті вдалося набагато краще організувати коди.

Спочатку об'єкти не називалися об'єктами, вони просто розглядалися як окремі області. Пізніше, коли зменшилися залежності та зв'язки між змінними всередині цих галузей, їх стали розглядати як ізольовані сегменти, і врешті-решт виникли концепції «об'єктів» та «об'єктно орієнтованого програмування».

Потім, в основному із-за появи Java, з'явилися нові модні терміни, а «процедуру», або «функцію», перейменували в «метод», коли він належить окремій області видимості. Змінні перейменували в «атрибути», коли вони належать окремій області видимості.

Так що об'єкт, по суті, — це просто набір функцій і змінних, які тепер називають методами і атрибутами.

Методи та атрибути ізолюються всередині окремої області видимості з допомогою «класу». А коли створюється екземпляр класу, він називається об'єктом.

Об'єкти можуть посилатися один на одного, і завдяки цьому методи (функції) всередині них теж «взаємодіють один з одним. Також об'єкти можуть «успадковувати» методи від інших об'єктів, тим самим розширюючи їх, це називається «спадкування». Це спосіб повторного використання коду, що дозволяє створювати незалежні розширення додатків через публічні класи та інтерфейси. Взаємозв'язки між об'єктами породили ієрархію. Спадкування було створено в 1967 році для мови Simula 67.

Об'єкти також можуть успадковувати методи від інших об'єктів і «перекрити» їх за допомогою додаткової або зміненої функціональності, це називається «поліморфізм».

У різних мовах ці ідеї реалізовані дуже по-різному.

Об'єктно орієнтоване програмування — це інший спосіб організації коду. Це розширення процедурного програмування, пов'язане з приховуванням даних (инкапсуляцией) і униканням глобальних областей видимості. Це розширення функцій за допомогою «запозичення» їх креслень без впливу на оригінальний код (спадкування). І це перевизначення функцій без впливу на оригінальний код (поліморфізм).

Модель ООП дозволяє легко створювати програми шляхом аккреції (нарощування). На практиці це найчастіше означає, що це структурований спосіб написання спагетті-коду.
Пол Грем. Ansi Common Lisp
Неправильний шлях: завжди використовувати об'єктно орієнтоване програмування.

Боятися чужого коду
Один із частих аргументів, що виправдовують застосування фреймворків, — небажання людей мати справу з кодовими базами, зробленими з фрагментів коду, написаного іншими.

Це досить дивне мислення, в основному характерне для веб-розробників, говорить про недолік професіоналізму і досвіду.

Абсолютно нормально створювати програми і працювати з кодом, написаним іншими. Це частина повсякденної роботи професійного програміста, і не треба її боятися.

Професіонал не буде скиглити, що його робота тепер повністю залежить від коду співробітника, який, ймовірно, більше не має відношення до компанії або проекту, а от якщо б цей працівник використовував фреймворк А чи фреймворк Б, то це заощадило б вам день роботи.

Професіонали так не думають. Ні один.

Можливо, свою роль у поширеності такого мислення відіграє низький поріг входу в веб-розробки на PHP. Але в будь-якому випадку це говорить про те, що людина йде по невірному шляху.

Програмування в чому увазі взаємодію з людьми, які використовують чужий код. Це частина роботи: намагатися поліпшити існуючу кодову базу, і іноді доводиться її повністю переписувати. Почитайте, що кажуть майстри програмування в книзі Coders at work. Reflections on the Craft of Programming.

Деякі з найбільших і найбільш успішних кодових баз в світі розробили сотні людей, які ніколи не зустрічалися один з одним. Ці бази створені без використання фреймворків, виключно на процедурних мовах програмування з застосуванням однієї лише процедурної парадигми. І ніхто навіть не мріяв зробити по-іншому.

Ядро Linux містить більше 20 мільйонів рядків коду, написаних виключно з допомогою процедурного програмування. У його створенні брали участь 14 тисяч осіб — і ніяких фреймворків. Різні можливості BSD і велика частина GNU Linux userland також написані тільки з допомогою процедурного програмування без застосування фреймворків.

Те ж саме можна сказати про сотні open source проектів по всьому світу, покинутих авторами тільки для того, щоб їх підхопили інші досвідчені програмісти. По багатьом з цих проектів дуже мало документації (або її взагалі немає), ні коментарів в коді, немає посібників чи інших видів допомоги.

Та чого вже там — вся кодова база написана на PHP, процедурному мовою, без фреймворків.

Коли ви визначаєте клас PHP або коли ви запускаєте свій улюблений PHP-фреймворк, ви виконуєте чиєсь процедурну роботу!

Звичайно, буває і жахливий код, який, ймовірно, спочатку ніяк не проектувався або який розрісся у багато разів, але клієнт не захотів його переписувати. Кодова база настільки жахлива, що ви не можете знайти кінців. Але жоден фреймворк не захистить вас від такої ситуації. Найчастіше це стадія нормального росту програми. Зрештою, будь-фреймворк просто розірветься на шматки.

Безумовно, існує кошмарний спагетті-код, але ніхто не пише його навмисно. Іноді це результат нестачі досвіду, найчастіше — вина клієнтів, багато разів змінюють специфікації посеред розробки. Але в обох випадках ви б все одно отримали спагетті-код, навіть при використанні фреймворка. І неважливо, наскільки інтенсивно ви станете застосовувати об'єктно орієнтовану парадигму: результат буде тим же.

Як програмісти, ми повинні запобігати такі ситуації, але це нормально це мистецтво програмування, це частина того, що називається бути програмістом!

Неправильний шлях: боятися коду, написаного іншими.

Слідування стандартам PHP-FIG
FIG розшифровується як Framework Interoperability Group (Група сумісності фреймворків).

PHP-FIG була створена розробниками фреймворків на конференції php|tek в 2009 році. З тих пір її склад збільшився з 5 до 20 учасників.

З PHP-FIG пов'язано багато суперечок. Одні вважають це кращим починанням PHP-спільноти з часів виникнення самого PHP. Інші впевнені, що варто взагалі скоріше забути про існування цієї групи.

Одна з проблем полягає в тому, як PHP-FIG позиціонує себе у своєму FAQ:

Завдання нашої групи — дати можливість учасникам говорити про спільність між нашими проектами і постаратися знайти шляхи спільної роботи. Наша аудиторія — це ми самі, але ми прекрасно розуміємо, що на нас дивиться все інше PHP-співтовариство. Ми будемо раді, якщо інші захочуть прийняти те, що ми робимо, але це не самоціль. Ніхто в нашій групі не вказує вам, як створювати додатки.
Однак якщо ми подивимося на роботу кількох учасників групи, стає очевидно, що реальна мета повністю суперечить заявленому. Група всіляко намагається перетворити PHP-FIG в «групу PHP-стандартів», що було їх початковим назвою. У книгах учасників групи, на їх сайтах, в блогах, на форумах і т. д. роботу PHP-FIG іменують сучасним PHP, а всі інші підходи оголошують застарілими.

Проблема PHP-FIG в тому, що, хоча багато фреймворки і open source-проекти впровадили у себе ряд стандартів групи, самі ці стандарти в основному покликані вирішувати проблеми «з точки зору фреймворку», що робить їх непотрібними у багатьох практичних ситуаціях.

Чимало розробників створюють, яке повинно бути надзвичайно ефективним, безпечним, вигідним, щоб його хотіли купити і використовувати. Їх не можна відволікати стандартами, які мають відповідати потребам фанатиків фреймворків. Це буде катастрофою для бізнесу.

Якщо і потрібна якась група, то її стандарти повинні відображати інтереси всього PHP-спільноти, а не одних лише розробників фреймворків і open source CMS проектів. Така група повинна представляти розробників самої мови PHP, з набагато більшою кількістю учасників, причому з правом голосу.

Якщо ви вирішили слідувати стандартам PHP-FIG, то ви повинні розуміти, що деякі з них — наприклад, стандарти автозавантажувач PSR-0 та PSR-4 і ряд інших — безпосередньо впливають на те, як ви пишете код.

У багатьох сферах потрібно высокомасштабируемое, критичне до часу виконання, економічно вигідне, яке просто неможливо створити, якщо слідувати стандартам PHP-FIG.

Неправильний шлях: слідувати стандартам PHP-FIG, за винятком PSR-1 і PSR-2.

Нехтування безпекою
З програмістами є одна проблема: ви ніколи не знаєте, що робить програміст, поки не стає занадто пізно.
Сеймур Крей. defprogramming.com
Безпечний код — це спосіб написання програм, стійких до атак зловмисників та забавляються, а також інших програм. Безпечний код захищає дані від крадіжки або пошкодження. Небезпечний код може надати атакуючим контроль над сервером або ідентифікаційними даними користувачів. Наслідки — будь-які, аж до виходу сервісу з ладу і злому систем тисяч користувачів.

Кожна програма — потенційна мета для атаки. Нападники спробують знайти в ваших додатках уразливості і використовувати їх, щоб викрасти важливу інформацію, порушити цілісність програм і даних, отримати контроль над серверами і мережами. На кону власність ваших клієнтів і ваша репутація.

не Можна просто додати безпека в додаток!

Щоб зробити небезпечне додаток безпечним, можливо, доведеться істотно перепроектувати його. Ви повинні визначати походження загроз для вашого та впроваджувати методики безпечного коду з самого початку, дотримуючись їх протягом всього планування та розробки програми.

Безпека критичних програмних ресурсів сьогодні важлива як ніколи, оскільки основний вектор атак неухильно переміщується на рівень програми. За підсумками дослідження SANS 2009 року, атаки проти веб-додатків склали більше 60 % всіх атак, зареєстрованих в інтернеті.

Особливість PHP в тому, що це мова програмування, веб-фреймворк. У мову вбудовано багато веб-функцій, з-за яких дуже легко написати небезпечний код.

Безпека за замовчуванням
Складність вбиває. Вона висмоктує життя з розробників, ускладнює планування продуктів, їх створення і тестування, ставить перед нами виклики в сфері безпеки і стомлює кінцевих користувачів і адміністраторів.
Рей Оззі
Щоб розробляти додатки з впровадженням правильних вимог з безпеки, необхідно використовувати методики написання безпечного коду і приділяти увагу ризикам у щоденних операціях, своїх думках і в процесі можливих вторгнень зловмисників.

Неправильний шлях: не розробляти додаток безпечним за замовчуванням.

FAQ
Все вищеописане легко зрозуміти неправильно — давайте дещо з'ясуємо.

У чому мета вашого сайту і чому ви пливете проти течії?
Мета — почати дискусію про сучасних методиках і крайніх точках зору.

Так ви кажете, що об'єктно орієнтоване програмування це погано чи добре?
Ні, звичайно, ні! Мова про те, щоб ви розуміли: не варто вирішувати всі проблеми винятково за допомогою ОО-парадигми. Не можна ділити все на чорне і біле, це помилка. В рамках однієї програми можуть існувати самі різні проблеми, і іноді кращий вихід — використовувати різні парадигми в залежності від конкретної ситуації. А якщо ви вирішуєте проблему з допомогою невідповідного способу, то ні до чого хорошого це не призведе.

Ви кажете, що фреймворки — зло?
Ми не засуджуємо конкретно фреймворки. Ми засуджуємо лише їх постійне використання поверх PHP.

Якщо фреймворк допомагає мені швидко розпочати і продовжити працювати, що в цьому поганого?
Якщо ви проаналізуєте ситуацію і довгострокові наслідки і зрозумієте, що «швидко розпочати і продовжити працювати» — єдина проблема, яку ви коли-небудь вирішували, то в цьому немає нічого поганого. Але тоді ми говоримо не про програмування або розробки ПЗ, а про використання point-and-click рішень.

Швидко розпочати і продовжити працювати — це не створення програми; це означає, що ви не аналізували проблему і не усвідомили довгострокових наслідків свого вибору.

— Ви хочете сказати, що сторонні пакети — це погано?
Немає. Ми рекомендуємо використовувати сторонні бібліотеки. Код, який ви можете легко і без обмежень впроваджувати в свої проекти. Це відмінна можливість!

— Хто ви?
Наш сайт присвячений ідеї боротьби з екстремізмом в PHP-співтоваристві, а не особистого просування або набуття популярності. Якщо ми розкриємо імена — це лише відверне увагу від піднятих на сайті проблем. Давайте не будемо відволікатися.

Який ваш досвід в розробці?
Щоб прийти до ідей, думок і рішень, відображеним на нашому сайті, не потрібно великого досвіду, якщо ви завжди робите те, що кажуть інші.

Рекомендована література
  1. PHP: Неправильний шлях — на Hacker News. Коли ми запустили наш сайт, на Hacker News з'явилося багато коментарів, в яких відображено чимало цінних аргументів.
  2. Як програмувати без ООП. Свіжа й альтернативна точка зору: Брайан Уїлл в трьох відео міркує про те, що не варто починати з ООП. На завершення він наводить кілька зауважень, як писати не ООП код.
  3. Кодери за роботою. Роздуми про ремесло програмування. Інтерв'ю засновані майже на 80 годин бесід з 15 найбільшими програмістами і фахівцями з інформатики. Тут ви знайдете багатогранний розповідь про те, як вони вчилися програмувати, як вони відточували свою майстерність і що вони думають про майбутнє програмування.
  4. Риси кваліфікованого програміста. Компетентність означає достатню кількість досвіду і знань для виконання завдання. Кваліфікованість — знання, чому ви робить щось саме таким способом і як це вкладається в загальну картину. Іншими словами, кваліфікований практик завжди компетентний практик, але зворотне необов'язково вірно.
  5. Керівництва щодо безпечного програмування. Не залежить від технологій документ з набором загальних методик безпечного програмування у форматі чек-листа, який можна впроваджувати в життєвий цикл розробки ПЗ. Використовуючи ці методики, ви уникнете більшості поширених вразливостей.
  6. Принципи безпечного проектування. Безпека веб-додатків — невід'ємний компонент будь-якого успішного проекту, будь то open source додаток, веб-сервіс наскрізної обробки або власні бізнес-сайти. Хостери абсолютно справедливо остерігаються небезпечного коду, користувачі остерігаються небезпечних серверів. Завдання цього посібника — допомогти бізнесу, розробникам, дизайнерам і архітекторам рішень створювати безпечні веб-додатки. Якщо користуватися ним з самих ранніх стадій, то вартість створення безпечних додатків буде порівнянна з вартістю небезпечних, при цьому в довгостроковій перспективі фінансова ефективність виявиться незрівнянно вище.
  7. Виживання на глибині: безпека в PHP. Всі жертви успішних зломів швидко відзначають в прес-релізах і на сайтах: безпека для них вкрай важлива, і вони ставляться до неї з усією серйозністю. Прийміть це близько до серця, до того, як відчуєте на практиці.
  8. Поліпшення існуючої структури коду з допомогою рефакторінгу . Рефакторинг дозволяє покращити наявну структуру коду. Це зміна системи таким чином, щоб зовнішня поведінка коду не змінювалося, але при цьому внутрішня структура ставало більш гармонійною. З допомогою рефакторінгу ви навіть можете перетворити погану структуру в хорошу. У книзі обговорюються принципи рефакторінгу, розповідається, де його варто застосовувати в першу чергу і як налаштувати потрібні тести. Також наведено каталог більш ніж із 40 перевірених рефакторингов з описом, коли і навіщо їх застосовувати, і покрокові інструкції по впровадженню. Заодно ілюструються схеми роботи рефакторингов. Книга написана на прикладі Java, але її ідеї застосовні в будь-якому іншому ОО-мовою.
  9. Практика програмування. Збірник практичних питань, актуальних для програмістів.
  10. Прагматичний програміст. Тут досліджуються ключові процеси програмування, від підмайстра до майстра: вироблення вимог, виконання робіт, правильне супровід коду. Розглядаються різні питання, починаючи з особистої відповідальності і розвитку кар'єри і закінчуючи методикою розробки архітектури заради збереження гнучкості, простоти адаптації та багаторазового використання коду.
  11. Розуміння мов програмування. Вибір мови програмування — один з найважливіших факторів, що впливають на загальну якість програмної системи. На жаль, дуже багатьом програмістам не вистачає лінгвістичних навичок: вони закохуються в свій «нативний» мова і не здатні критично аналізувати його обмеження. Книга «Розуміння мов програмування» написана, щоб пояснити:
    • які альтернативи доступні розробникам,
    • які мовні конструкції краще використовувати для підвищення безпеки і читабельності,
    • як ці конструкції реалізовані і як їх можна ефективно компілювати,
    • яка роль мови у вираженні і посилення абстракцій.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.