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

кодування

Для менших сценаріїв насправді немає сенсу говорити про це, навіть якщо наша програма отримує та обробляє запити від 100 000 користувачів, оскільки чим менша програма, тим важче її добре «оптимізувати». Звичайно, вам не потрібно використовувати "відносно" повільні мови сценаріїв під час програмування на стороні сервера, оскільки ви можете зробити те ж саме з Java, Visual Basic або навіть Assembly.
Великою перевагою php є те, що він дає програмісту досить велику свободу. Нам не потрібно попередньо оголошувати наші змінні, функції, нам не доводиться мати справу з тим, що з ними відбувається пізніше, і нам не потрібно турбуватися про проблеми під час виконання, оскільки це те, що робить для нас парсер php (принаймні намагається). Зараз я пишу в 5 пунктах про те, на що слід звернути увагу в програмуванні на PHP загалом, з практичної точки зору.

Дизайн 1

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

Давайте розглянемо просту функцію:

Або з простим дизайном:

простий (Текст, Колір);
Друкує вказаний текст (Текст) із зазначеним кольором (Колір)

Очевидно, що якщо ми плануємо заздалегідь (скажімо погано:), виправлення помилок часом стає неможливим, оскільки ми не знаємо, де і що ми зіпсували, і навіть логіка, якою ми керувались, може бути помилковою по черзі. Якщо ми постійно розширюємо код, проблеми продовжуватимуть надходити, але після певного розширення ми зазвичай знаємо, що (можливо) наша програма генерує помилку через поточне розширення. Через останнє я віддаю перевагу постійному розширенню певної програми. Якщо ви використовуєте багато файлів, корисно описати (наприклад, графіками, тобто намалювати), який файл php використовує, і це особливо актуально, якщо код фрагментований. Наприклад, у нас є такий список:

  • main.php
  • content.php
  • kepek.php
  • linksek.php
  • config/config.php
  • config/funcs.php
  • config/sql.php

Який файл залежить від якого? Скажімо, вам усім потрібен config.php? Або sql.php? Якщо ви використовуєте велику кількість включень, непогано включити їх на початку файлу, що вам точно знадобиться, тоді як те, що буде виконуватися за певної умови, буде лише тоді і там. Це значно полегшує інтерпретацію php, оскільки часто вставляти тисячі послідовних php-файлів є важливим.
обчислювальна потужність. Отже, у наведеному вище прикладі скажіть, чи перелічуєте ви images.php на основі таблиці сервера sql, але лише якщо користувач натискає посилання:

2. функції

Можливо, функції є найбільш корисними структурами в програмуванні, як і в математиці, хоча це звучить дебільно, оскільки саме програмування ґрунтується на функціях (точніше, відношеннях). На абстрактному рівні ми бачимо, що напр. присвоєння значення, структури управління (якщо тощо ...) - це всі відносини. Сьогодні ви чуєте багато (або мало) про oop, навіть найбільші нові функції в php 5 пов'язані з об'єктами. Коли ми думаємо про клас, ми по суті уявляємо собі набір даних, над якими пов'язані функції виконують операції. Я читав у багатьох книгах про php, щоб використовувати класи "обгортки" скрізь, де ми можемо.

Я не буду вдаватися до останньої концепції зараз, ви можете прочитати її в багатьох місцях, і, на мою думку, використання класів насправді не широко поширене серед програмістів PHP (звичайно, не на рівні професіоналів).
Слід зазначити, що це не проблема. Класи насправді варто застосовувати лише там, де ми знаємо, що будемо робити подібні операції в іншому місці, і ми не хочемо переробляти свої функції та дані. Деякі приклади: перевірка форм, доступ до баз даних, читання/запис файлів, перевірка даних, управління сесіями, написання елементів HTML (таблиця, вибір, введення тощо) тощо.

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

Давайте подивимося на це простим слідом, ми хочемо розрахувати індекс маси тіла людини, а потім сказати нам, наскільки він відрізняється від ідеального:

У нас тут теж біда?

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

Але чому останній кращий? Зрештою, було більше коду (65 рядків замість 40), і крім того
ніщо не запускається автоматично (тобто функцію потрібно викликати). Однак одразу стає очевидним, що використання декількох структур управління (випадків)
сам код також став більш прозорим (я сподіваюся). Ми розділили перевірку даних, обчислення результату та його відображення. також буде набагато простіше налагодити в ретроспективі, оскільки ми завжди можемо легко розмежувати, між якою функцією є помилка. Більш докладні повідомлення про помилки можуть бути надіслані користувачеві. Якщо ми хочемо виключити частину, ми просто не запрошуємо її.
І все-таки найкрасивіше у функціях те, що ви можете будь-коли вийти з них. Давайте розглянемо просте управління авторизацією. У наведеній нижче програмі ми цього не хочемо
користувачі можуть видаляти та змінювати дані адміністратора та користувача, дозволяючи адміністраторам:

Якщо сюди увійде несанкціонована особа (наприклад, людина в групі користувачів), вона нічого не побачить. Паралельно ми можемо виконувати функцію modosito_admin із подібним управлінням дозволами.

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

Натомість замість цього (і якщо ми вже дотримуємося 12):

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

сервер, $ this-> ім'я користувача, $ this-> пароль); якщо ($ sql) < $this->стан = істина; повернути $ sql; >>>?>

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