Точно так же, як і в разі будь-якого іншого мови програмування, PHP-розробники здатні написати на PHP код самого різного якості - від зовсім жахливого до дуже хорошого. Освойте навички хорошого програмування, які допоможуть вам підвищити свою продуктивність.
З точки зору продуктивності «прекрасний» розробник може перевершувати просто «хорошого» розробника в 10 - 20 разів. Прекрасний розробник є більш продуктивним внаслідок свого досвіду і проходження хорошим звичкам. Звички поганого програмування, прокрався в ваш код, є причиною зниження продуктивності. У даній статті демонструється кілька хороших звичок, дотримання яких допоможе вам підвищити свою професійну майстерність програміста.
Крім підвищення вашої продуктивності в процесі написання коду ці звички допоможуть вам створювати якісний код, розрахований на весь термін служби додатки. У будь-якого створюваного вами коду велика частина терміну служби швидше за все доведеться на етап супроводу, а супровід додатків, як правило, вимагає великих витрат. Дотримання хорошим звичкам в області кодування покращує проектувальні показники, в тому числі ступінь модульності, завдяки чому ваш код стає простіше в розумінні і, відповідно, простіше і дешевше в супроводі.
Погані звички в області кодування призводять до порушення нормальної роботи в програмному коді і можуть в подальшому утруднити внесення в нього змін без появи нових дефектів. Перераховані нижче п'ять хороших звичок, будучи застосовані до вашого PHP-коду, допоможуть вам уникнути подібних пасток.
- Давайте належні імена
- Розбивайте код на фрагменти меншого розміру
- Документуйте свій код
- обробляйте помилки
- Ніколи не користуйтеся операцією «копіювати і вставити»
Наступні розділи присвячені детальному роз'ясненню цих звичок.
Давайте належні імена
Погана звичка: неоднозначні або безглузді імена
У лістингу 1 наведено приклад коду, що містить занадто короткі імена змінних, складні для розуміння скорочення і імена методів, які не описують вироблені ними дії. Ім'я методу, що натякає на будь-які виконуються цим методом дії, в той час як в дійсності він робить щось зовсім інше, може виявитися надзвичайно шкідливим, оскільки буде вводити в оману.
Лістинг 1. Погана звичка: неоднозначні або безглузді імена
Гарна звичка: осмислені і лаконічні імена
Код, наведений у лістингу 2, демонструє використання хороших звичок іменування. Змінені імена методів краще відображають, що роблять ці методи і чому. Імена змінних також стали більш змістовними. Єдина змінна, яка залишилася короткою в цьому лістингу - це змінна циклу $ i. Хоча багато хто може не погодитися зі мною, але я вважаю, що коротка назва для змінної циклу є цілком прийнятним і навіть хорошим вибором, оскільки воно чітко вказує на її функціональне призначення.
Лістинг 2. Гарна звичка: осмислені і лаконічні імена
Я рекомендую представляти великий умовний блок у вигляді методу і давати цим методом ім'я, яке описує цю умову. Цей прийом спрощує читання коду і наділяє умова під зовнішню форму, завдяки чому воно може бути абстрагировано і можливо навіть повторно використано. У разі зміни формулювання умови простіше оновити відповідний метод. Оскільки цей метод має осмислене ім'я, код не втратить свого сенсу і не стане важким для читання.
Розбивайте код на фрагменти меншого розміру
Досить просто зосередитися на вирішенні проблеми і приступити до написання програмного коду. У міру того, як ви вирішуєте поточне завдання, ваші функції стають все довше і довше. Це не становить проблеми в довгостроковій перспективі, якщо згодом ви повернетеся назад і переформіруете свій код у вигляді фрагментів меншого розміру.
Вам також слід сформувати звичку до такого написання методів, щоб кожен з них виконував одну, і тільки одну, функцію. Існує кілька причин для такої пильної уваги до написання методів. По-перше, метод простіше застосовувати багаторазово в тому випадку, якщо він робить тільки одну річ, і робить її добре. По-друге, такі методи простіше в тестуванні. По-третє, такі методи простіше розуміти і легше змінювати в разі потреби.
Погана звичка: довгі функції (які роблять занадто багато)
У лістингу 3 наведено приклад довгою функції. Така функція є джерелом потенційних проблем з кількох причин. Вона виконує багато незв'язаних дій. Її важко зрозуміти, налагодити і протестувати. Вона робить ітерації і будує список елементів, вона привласнює значення об'єктів, вона виконує обчислення і т.д.
Лістинг 3. Погана звичка: довгі функції
Якщо до цього методу додати ще трохи програмного коду, то його супровід стане практично неможливим.
Гарна звичка: керовані, фокусовані функції
На лістингу 4 демонструється більш компактний, більш чіткий варіант попереднього методу. У цьому прикладі довгий метод розбитий на методи меншого розміру, кожен з яких виконує тільки одну задачу і робить це добре. Отриманий в результаті код простіше повторно використовувати в майбутньому, і простіше тестувати.
Лістинг 4. Гарна звичка: керовані, конкретні функції
Поділ довгих методів на більш короткі має сенс до певної межі, тому будьте обережні і не перестарайтеся. Ви можете розбити код так, що він залишиться таким же складним для розуміння, як і раніше, коли він був єдиною функцією.
Документуйте свій код
Погана звичка: відсутнє і надмірне документування функцій
Лістинг 5. Погана звичка: відсутнє і надмірне документування функцій
Гарна звичка: документування функцій і класів
Лістинг 6. Гарна звичка: документування функцій і класів
обробляйте помилки
Добре відомо, що при написанні стійких додатків обсяг коду для обробки помилок повинен відповідати правилу 80/20: 80% коду присвячено обробці виключень і валідації, 20% коду виконує фактичну роботу. Цілком природно, що при написанні коду багато розробників орієнтуються на найбільш сприятливий сценарій (happy-path). Такий код добре працює в т.зв. «Базової» обстановці, коли всі дані є валідними, а всі умови відповідають очікуваним. Однак протягом терміну служби додатки такий код може проявити свою нестійкість. З іншого боку, ви можете витратити занадто багато часу на написання коду в розрахунку на умови, з якими, можливо, ніколи не зіштовхнетеся.
Гарна звичка полягає в знаходженні розумного балансу між достатнім обсягом обробки помилок і відмовою від зайвого вдосконалення свого коду, яке може ніколи не закінчитися.
Погана звичка: повна відсутність обробки помилок
Код в лістингу 7 демонструє дві погані звички. Одна з них полягає у відсутності перевірки вхідних параметрів, навіть якщо ви знаєте, що в цій точці параметр в певному стані викличе виключення в вашому методі. Друга полягає в тому, що код викликає метод, який може кинути необроблене виняток. Такий код змусить розробника або супроводжуючу особу будувати здогади про джерело проблем, коли вони почнуть з'являтися.
Лістинг 7. Погана звичка: повна відсутність обробки помилок
Гарна звичка: програмування з захистом
Лістинг 8. Гарна звичка: програмування з захистом
Взагалі кажучи, перевірка параметрів відноситься до етапу валідації - який виявиться недаремним для кожного, хто буде використовувати ваші функції (якщо він хоче, щоб параметри відповідали певним умовам). Проте, вам слід перевірити ці параметри і кинути осмислені виключення.
- Обробляйте виключення якомога ближче до місця виникнення проблеми.
- Обробляйте кожен виняток специфічним для нього чином.
Ніколи користуйтеся операцією «копіювати і вставити»
Можливість скопіювати код з одного місця і потім вставити його в інше місце вашого коду - це палиця з двома кінцями. З одного боку, це рятує вас від безлічі помилок, що виникають при використанні клавіатури для ручного введення будь-якого коду з прикладу або з шаблону. З іншого боку, це сприяє «розростання» схожих фрагментів коду.
Будьте дуже уважні при копіюванні коду між різними частинами вашого застосування. Коли ви знайдете себе на тому, що ви займаєтеся саме цим, зупиніться і запитайте себе, яким чином ви могли б переписати копіюється фрагмент коду, щоб забезпечити його повторне використання. Розміщення коду в одному місці істотно спрощує його подальший супровід, оскільки зміни необхідно проводити тільки в одній точці.
Погана звичка: схожі фрагменти коду
У лістингу 9 показано кілька методів, які майже ідентичні, за винятком кількох значень. Існують інструменти, які допоможуть вам знайти код, отриманий шляхом копіювання і вставки (див. Розділ Ресурси).
Лістинг 9. Погана звичка: схожі фрагменти коду
Гарна звичка: багаторазово використовувані функції з параметрами
У лістингу 10 показаний змінений код, з перетворенням скопійованого блоку в один метод. Інші методи також були змінені, щоб делегувати свою роботу новим методом. Побудова загального методу забирає деякий час на етапі проектування; крім того, вам обов'язково доведеться зупинитися і подумати, замість того, щоб інстинктивно використовувати операцію «копіювати і вставити». Однак ви з лишком компенсуєте витрачений вами час згодом, коли вам знадобиться вносити будь-які зміни.
Лістинг 10. Гарна звичка: багаторазово використовувані функції з параметрами
висновок
Якщо ви розвинете у себе описані в цій статті хороші звички при написанні PHP-коду, то зможете створювати код, який буде простий для прочитання, розуміння і супроводу. Побудова простого в супроводі програмного коду дозволить вам налагоджувати, виправляти і розширювати свій код з більш низьким рівнем ризику.
Використання хороших імен та організація коду у вигляді фрагментів меншого розміру спрощує його читання. Документування призначення вашого коду спрощує розуміння ваших намірів і полегшує можливість розширення. Належна обробка помилок робить код більш стійким. І, нарешті, відмова від «милиці» у вигляді операції «копіювати / вставити» дозволяє вам утримувати свій код в чистоті.