Codificare, metode, optimizare prima parte: proiectare, funcții

Ca programator, după un timp vom întâlni cu siguranță conceptul de optimizare. Există multe niveluri și modalități de a face acest lucru, dar în primul rând pentru a crește viteza, resp. reducerea încărcării (mai puțină utilizare a memoriei, mai puțin cod etc.) este obiectivul principal.

Pentru scripturile mai mici, nu are rost să vorbim despre acest lucru, chiar dacă programul nostru primește și procesează cereri de la 100.000 de utilizatori, cu cât un program este mai mic, cu atât este mai greu să îl „optimizăm” bine. Desigur, nu trebuie să utilizați limbaje de scriptare „relativ” lente atunci când programați pe partea serverului, deoarece puteți face același lucru cu Java, Visual Basic sau chiar Assembly.
Marele avantaj al php-ului este că oferă programatorului destulă libertate. Nu trebuie să ne declarăm în prealabil variabilele, funcțiile, nu trebuie să ne ocupăm de ceea ce li se întâmplă mai târziu și nu trebuie să ne deranjăm problemele de execuție, deoarece acest lucru face analizatorul php pentru noi (măcar încearcă). Acum scriu în 5 puncte despre ce să căutăm în programarea PHP în general, din punct de vedere practic.

Proiectare 1

Eu personal nu sunt credincios în design. Acesta poate fi cazul pentru mulți, deoarece poate părea o pierdere de timp când putem începe să codificăm programul imediat, iar ceilalți râd de el acum sau poate că vin cu „profesioniștii” în felul acesta (din fericire Nu sunt încă un profesionist).)
Dacă lucrăm la o slujbă mai mare, nu este rău să vedem în mintea noastră ce face programul sau ce ne așteptăm de la el. Dacă ne blocăm, putem totuși scoate pixul și hârtia, sau imaginația noastră. Dar care este mai bine? Dacă notăm pe o bucată de hârtie ce vrem și apoi decodăm totul dintr-o dată, sau pornind de la un program gol, ajungem treptat la destinație?

Să vedem o funcție simplă:

Sau cu un design simplu:

simplu (Text, Culoare);
Tipărește textul specificat (Text) cu culoarea specificată (Color)

Este evident că, dacă planificăm înainte (să spunem rău:), corectarea erorilor devine uneori imposibilă, deoarece nu știm unde și ce am încurcat și chiar și logica pe care am urmat-o poate fi greșită pe rând. Dacă extindem în mod constant codul, problemele vor continua să apară, dar după o anumită extindere știm de obicei că (probabil) programul nostru generează o eroare din cauza extinderii actuale. Din cauza acestuia din urmă, prefer extinderea continuă a unui anumit program. Dacă utilizați o mulțime de fișiere, este o idee bună să descrieți (de exemplu, cu grafice, adică să desenați) ce fișier php folosește ce, și acest lucru este valabil mai ales dacă codul este fragmentat. De exemplu, avem o astfel de listă:

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

Care fișier depinde de care? Să presupunem că aveți nevoie de toți config.php? Sau sql.php? Dacă utilizați o mulțime de includeri, este o idee bună să le includeți la începutul fișierului, de care cu siguranță veți avea nevoie, în timp ce ceea ce va rula într-o anumită condiție este doar atunci și acolo. Acest lucru face interpretarea php mult mai ușoară, deoarece inserarea adesea a mii de fișiere php seriale este semnificativă.
puterea de calcul. Deci, în exemplul de mai sus, spuneți dacă listați images.php pe baza unui tabel server SQL, dar numai dacă utilizatorul face clic pe un link:

2. funcții

Probabil funcțiile sunt cele mai utile structuri în programare, așa cum sunt și în matematică, deși acest lucru sună debil, deoarece programarea însăși se bazează pe funcții (mai precis, relații). La nivel abstract putem vedea că de ex. atribuirea valorii, structurile de control (dacă etc ...) sunt toate relații. Astăzi auzi multe (sau puține) despre oop, chiar și cele mai mari caracteristici noi din php 5 sunt legate de obiecte. Când ne gândim la o clasă, ne imaginăm în esență un set de date pe care funcțiile conexe efectuează operațiuni. Am citit în multe cărți PHP pentru a folosi cursurile „wrapper” oriunde putem.

Nu voi intra în ultimul concept acum, îl puteți citi în multe locuri și, după cum îl văd, utilizarea claselor nu este foarte răspândită printre programatorii PHP de aici (desigur, nu la nivelul profesioniștilor).
Trebuie remarcat că nu este o problemă. Clasele merită aplicate doar acolo unde știm că vom face operațiuni similare în altă parte și nu vrem să ne reproiectăm funcțiile și datele. Câteva exemple sunt: verificarea formularelor, accesarea bazelor de date, citirea/scrierea fișierelor, verificarea datelor, gestionarea sesiunii, scrierea elementelor html (tabel, selectare, intrări etc.) și altele asemenea.

După cum puteți vedea, putem recicla majoritatea unei pagini bazate pe PHP. Concepte precum moștenirea, închiderea, clasele abstracte ne ajută să facem acest lucru.
Revenind însă la bazele claselor și (poate) la toate programările moderne: cel mai mare avantaj al unei funcții este că putem să o numim și să „returnăm” o valoare.
În esență, putem numi și o funcție o structură de control, deoarece declararea unei funcții nu înseamnă a o numi, deci este în esență
executarea condiționată.

Să o privim cu o amprentă simplă, vrem să calculăm indicele de masă corporală al unei persoane și apoi să ne spunem cât de diferit este de ideal:

Aici avem și noi probleme?

Puteți vedea imediat că programul se îneacă în IF și în altele, indiferent dacă am efectuat în esență o sarcină de calcul simplă, cu unele verificări și tipăriri de date.
Pentru mii de linii de cod, programul în sine ar fi deja opac și, dacă am dori să-l extindem, am putea începe să ne deranjăm din nou dacă. În plus, dacă îl folosim în mai multe locuri și dorim să rescriem ceva, trebuie să o facem în fiecare loc.
Până acum, am citit acest lucru în orice manual de programare, dar în multe locuri nu se menționează că funcția în sine formează o structură închisă. De exemplu, putem separa programul de mai sus în 3 funcții, una pentru a verifica datele, una pentru a returna calculul la textul care urmează să fie tipărit și ultima pentru a tipări:

Dar de ce este din urmă mai bun? La urma urmei, a existat mai mult cod (65 de linii în loc de 40) și, pe deasupra
nimic nu rulează automat (adică funcția trebuie apelată). Cu toate acestea, este imediat evident că utilizarea mai multor structuri de control (cazuri)
codul în sine a devenit și mai transparent (sper). Am separat verificarea datelor, calculul rezultatului și afișarea acestuia. va fi, de asemenea, mult mai ușor de depanat retrospectiv, deoarece putem oricând delimita cu ușurință ce funcție este eroarea. Utilizatorului îi pot fi date mesaje de eroare mai detaliate. Dacă dorim să excludem o parte, pur și simplu nu o invităm.
Cu toate acestea, cel mai frumos lucru despre funcții este că le puteți ieși oricând. Să analizăm o simplă gestionare a autorizațiilor. În programul de mai jos nu vrem asta
utilizatorii pot șterge și modifica datele de administrator și de utilizator, permițând în același timp administratorilor să:

Dacă o persoană neautorizată intră aici (de exemplu, o persoană din grupul de utilizatori), nu va vedea nimic. În paralel, putem face o funcție modosito_admin cu gestionarea permisiunilor similare.

Scopul principal al funcțiilor este, desigur, generalizarea. Oriunde putem, încercați să scriem funcții absolute, adică unele care sunt mai puțin dependente de datele noastre statice.
De exemplu, următoarea funcție funcționează complet fără sens, nu scrieți niciodată funcții pentru astfel:

În schimb, în loc (și dacă ne menținem deja la 12):

Acesta este un exemplu puțin prea simplu, desigur, dar poate de înțeles.
Din moment ce nu există de ex. proceduri similare cu Pascal, putem folosi și structuri similare cu cele de mai sus (prima), dar de obicei o folosesc numai atunci când ceva trebuie defalcat și nu există dependență de date (deci, de exemplu, procedura nu depinde de un număr). Dacă aveți o funcție similară cu prima (deci faceți întotdeauna același lucru cu aceleași date), poate doriți să organizați funcția într-o clasă:

server, $ this-> nume de utilizator, $ this-> parolă); if ($ sql) < $this->state = adevărat; returnează $ sql; >>>?>

Desigur, toată lumea trebuie să dezvolte metodele cu care vor lucra, deoarece toate cele descrise mai sus pot fi rezolvate în alte moduri (în multe feluri) și, evident, există o metodă care economisește complet codul și oferă mult mai mult muncitorului cu puțină muncă. Dacă știți despre asta, împărtășiți-l cu mine:)
În cele ce urmează, vom vorbi despre structurile de control și stilul și organizarea codării.