Fork me on GitHub

PHP

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

Останнє оновлення: 2023-01-31
cartoon

Ласкаво просимо.

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

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

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

Не соромтеся робити свій внесок.

Переклади

Небезпека екстремізму (крайнощів).

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

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

Досвід показує, що неправильне використання загальних правил і принципів завжди призводить до ускладнення, дірок у безпеці, багів, а в деяких випадках і до повного краху.

Принцип KISS (Keep It Simple, Stupid), «роби це простіше, тупиця», є надзвичайно мудрим і добрим принципом. Як правило, він розглядається досвідченими людьми, як чудова порада, якої варто дотримуватися. Однак навіть ця порада становить небезпеку для проєкту, якщо її доведено до крайності. Якщо все занадто просто, то це може призвести до відсутності необхідної функціональності.

Неправильний шлях: Релігійне дотримання правил і керівних принципів. Thumbs down

Завжди використовуйте фреймворк.

Усі PHP-фреймворки загального призначення відстій!

Расмус Лердорф

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

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

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

Ці люди, схоже, одержимі думкою стати в певному сенсі лідерами PHP спільноти, мати послідовників свого методу, які використовують їхні останні модні опенсорсні інструменти. При цьому вони забувають переконатися в тому, щоб поради, які вони дають, були б корисними і надійними.

Фреймворк загального призначення можна порівняти з каркасним будинком (це будинок, який збирається з готових блоків). Розробка програм на основі таких фреймворків не робить вас кодером або програмістом, подібно до того, як складання такого будинку не робить вас теслею.

На цьому сайті ми відрізняємо фреймворк від бібліотеки таким чином:

У світі Python і Ruby створення веб-сайтів з нуля виснажливе, тому що ні Python, ні Ruby від початку не були створені для цього. У підсумку фреймворки, такі як Django та Ruby on Rails, швидко стали відомими і широко використовуваними для створення веб-сайтів на цих мовах. Навпаки, Расмус Лердорф спочатку створив PHP, як набір інструментів, написаних на C, який дає вам можливість швидко і легко розробляти динамічний HTML. По суті PHP сам по собі був і залишається фреймворком. Відтоді PHP бурхливо розвивався, і сьогодні його не тільки можна використовувати для генерації HTML або створення веб-сайтів, а й розглядати, як свого роду фреймворк. PHP, написаний повністю на процедурному C, за своєю суттю є певним рівнем абстракції для розробки веб-додатків. Використання бібліотеки у вашому проекті цілком природно. Сам PHP поставляється в комплекті з набором бібліотек, які ви можете використовувати, щоб розширити свій власний код. PDO, наприклад, являє собою невелику бібліотеку, яка забезпечує послідовний інтерфейс для доступу до баз даних у PHP. А ось використання фреймворка поверх PHP - це зовсім інша справа. Коли ви використовуєте фреймворк у PHP, ви додаєте новий шар абстракції поверх іншого, вже існуючого, який вже був готовий до використання. Додатковий рівень абстракції, що забезпечується фреймворком, може просто організувати код у заздалегідь підготовлені шаблони або ж може ускладнити справу завдяки переплетенню сотень або навіть тисяч класів і методів у жахливий кошмар залежностей. Але як би там не було, ви додаєте у свій код нові рівні складнощів, які зовсім не потрібні!

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

Прийміть, як очевидне: ** Ідеально кількість рядків у проєкті має бути настільки малою, наскільки це можливо, доки все залишається чітким і читабельним.**

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

Расмус Лердорф

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

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

Дія чи мислення мають радше зважати на можливі практичні наслідки, аніж керуватися теоріями чи догмами.

– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014

Неправильний шлях: Завжди використовуйте фреймворк поверх PHP. Thumbs down

Завжди використовуйте шаблони проєктування.

У мене просто алергія на вежі зі слонової кістки та на шаблони проєктування. Коли Пітер Норвіг був у Harlequin Inc, він написав статтю про те, що шаблони проєктування насправді лише прикривають дефекти у вашій мові програмування, вам треба вибрати кращу мову. І він абсолютно правий. Поклоняючись патернам, можна думати тільки категоріями: «Так, зараз я буду використовувати шаблон X»

– Брендан Айк у “Кодери за роботою - Роздуми про ремесло програмування”

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

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

Пол Грем

Ми не повинні бути втягнуті у філософію або ідею конкретного шаблону чи рішення. Наше головне завдання - зберегти код максимально зрозумілим і простим для навігації, наскільки це взагалі можливо. І в результаті його буде легко підтримувати та забезпечувати безпеку. Також маємо пам’ятати, що існує така річ, як анти-патерн. Це теж шаблон, який зазвичай використовується, але на практиці виявляється неефективним та/або контрпродуктивним.

Я гадаю, що шаблони починали як загальновизнані найкращі рішення для загальних проблем. Але тепер, після того, як певний час патерни були в ходу, ми маємо додатки, які в десятки разів складніші, ніж це необхідно. І це тільки тому, що люди намагаються впихнути в них усі шаблони, про які коли-небудь читали (“мій застосунок добре спроєктований, тому що до країв напханий різними патернами”). Тож моє враження про їхню цінність трохи змінилося.

– Пол Уiтон у “Лихо шаблонів проектування”

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

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

– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014

Неправильний шлях: Шукати шаблон, щоб вирішити проблему. Thumbs down

Завжди використовуйте об’єктно-орієнтоване програмування.

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

– Джо Армстронг у «Кодери за роботою - Роздуми про ремесло програмування»

Абстракція - велика сила. А що в мене викликає алергію ще з 1990-х, то це CORBA, COM, DCOM і всяка об’єктно-орієнтована нісенітниця. Кожен новий проєкт у той час обов’язково мав якусь примочку, якій було потрібно 200 000 викликів тільки для того, щоб надрукувати Hello World. Це профанація. Справжні програмісти таким не займаються.

– Брендан Айк у «Кодери за роботою - Роздуми про ремесло програмування»

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

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

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

Як комп’ютерні теоретики і програмісти ми повинні навчитися спростовувати упередження і знаходити найкращі рішення для поставленого завдання.

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

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

Невеликий урок історії.

Один із найкращих способів зрозуміти специфічну парадигму програмування - подивитися на її еволюцію. Що стало причиною для її розвитку? Які проблеми, наявні в інших парадигмах, призвели до нового способу мислення? Чи була це реальна світова проблема, чи вона була академічною? І як ця парадигма відтоді змінилася?

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

Є два способи побудови програм. Перший - зробити її настільки простою, що в ній очевидно не буде недоліків. Другий - зробити її такою складною, що в ній не буде очевидних недоліків.

Чарльз Ентонi Рiчард Хоар

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

Існують як високорівневі, так і низькорівневі мови, які використовують неструктуроване програмування. До них належать ранні версії BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинний код, ранні асемблерні системи (без процедурних метаоператорів) і деякі скриптові мови.

Програма в неструктурованих мовах, як правило, складається з послідовних команд і операторів по одному в кожному рядку. Рядки зазвичай нумеруються або мають мітки, що дозволяють потоку переходити до будь-якого рядка в програмі (наприклад, за допомогою непопулярного оператора GOTO).

У шістдесяті роки структурне програмування з’явилося переважно завдяки відомій статті Едсгера Дейкстри «Докази проти оператора GOTO»

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

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

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

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

Нова технологія розвивалася, що дало змогу розділити дані на різні області видимості, які називаються «об’єктами». Тільки конкретні процедури, що належать до однієї області видимості, могли отримати доступ до даних тієї ж області. Це називається приховування даних або інкапсуляція. Результатом стала набагато краща організація коду.

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

Ще пізніше, здебільшого завдяки розвитку Java, з’явилися деякі “слівця”, процедури і функції перестали називатися функціями, а стали називатися методами, якщо вони перебували всередині меж об’єкта. Змінні теж більше не називають «змінними», їх було перейменовано в «атрибути», якщо вони перебували в окремій області видимості.

Таким чином, об’єкт, по суті, це просто набір функцій і змінних, які тепер стали називатися «методами та атрибутами».

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

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

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

Ці в різних мовах програмування ці ідеї реалізовано різними способами.

Об’єктно-орієнтоване програмування - це зовсім інший спосіб організації коду, ніж був раніше. Це продовження процедурного програмування з додаванням приховування даних (інкапсуляції) та уникненням глобальних областей видимості. Йдеться про розширення функцій шляхом “запозичення” своїх схем без впливу на вихідний код (успадкування). І йдеться про перевизначення функцій, при якому не зачіпається вихідний код (поліморфізм).

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

– Пол Грем у Ansi Common Lisp

Неправильний шлях: Завжди використовувати об’єктно-орієнтоване програмування. Thumbs down

Бійтеся коду інших програмістів.

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

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

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

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

У професійних програмістів менталітет інший. Вони так не роблять.

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

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

Подивіться, що говорять великі програмісти в книзі «Кодери за роботою. Роздуми про ремесло програмування».

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

Ядро Linux містить більш ніж 20 мільйонів рядків коду, написаних повністю на процедурній парадигмі. Його розробляли більш ніж 14.000 учасників, і вони не використовували жодних фреймворків.

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

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

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

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

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

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

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

Неправильний шлях: Боятися чужого коду. Thumbs down

Дотримуючись стандартів 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» у своїх книжках, на сайтах, на різних форумах, блогах, визначаючи всі інші напрямки як застарілі.

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

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

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

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

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

Неправильний шлях: Дотримуватися стандартів PHP-FIG, релігійно. Thumbs down

Нехтуйте безпекою

З програмістами є одна проблема: ви ніколи не знаєте, що робить програміст, поки не стає надто пізно.

– Сеймур Крей у defprogramming.com

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

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

Безпека - це не те, що можна додати до програмного забезпечення!

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

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

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

Безпека за замовчуванням

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

Рей Оззi

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

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

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

FAQ

Дуже просто неправильно витлумачити те, що ми написали, тому давайте прояснимо деякі питання.

Q: У чому сенс цього сайту і чому ви обрали конфронтаційний підхід?

A: Для того щоб почати дискусію про сучасні методики і крайні точки зору.

Q: Ви кажете, що об’єктно-орієнтоване програмування погане або неправильне?

A: Ні, звісно ж, ні! Ми говоримо: не варто розв’язувати всі проблеми тільки використанням об’єктної парадигми. Не можна ділити все на чорне і біле, це неправильно.

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

А якщо ви насильно розв’язуєте проблему за допомогою невідповідного способу, трапляються нехороші речі.

Q: Ви кажете, що фреймворки - зло?

A: Ми не намагаємося судити конкретні фреймворки. Ми засуджуємо лише їхнє постійне використання поверх PHP.

Q: Якщо фреймворк допомагає мені швидко почати і продовжити працювати, що в цьому поганого?

A: Якщо ви проаналізуєте ситуацію, її наслідки в довгостроковій перспективі та зрозумієте, що “швидко почати і продовжити працювати” - єдина проблема, яку вам треба вирішити, то в цьому немає нічого поганого. Але тоді ми говоримо не про програмування або розробку ПЗ, а про використання point-and-click рішень.

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

Q: Ви хочете сказати, що сторонні пакети - це погано?

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

Q: Хто ви?

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

Q: Який ваш досвід у розробці програмного забезпечення?

A: Щоб прийти до ідей, думок і рішень, відображених на нашому сайті, не потрібно великого досвіду, якщо ви просто залишаєтеся сфокусованими на основній темі, яка полягає в тому, щоб завжди робити конкретні речі.

Рекомендована література

PHP: Неправильний шлях - на Hacker News

Чому найпростіший код б’є «найкращі практики»

Як програмувати без ООП.

Кодери за роботою. Роздуми про ремесло програмування.

Риси кваліфікованого програміста.

OWASP Посібники з безпечного програмування.

Принципи безпечного проєктування.

Виживання на глибині: безпека у PHP.

Поліпшення наявної структури коду за допомогою рефакторингу

Практика програмування.

Прагматичний програміст

Розуміння мов програмування

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

Як зробити свій внесок

Співпрацювати на GitHub.