Хејтерите секогаш газеа PHP од различни причини, но една од најлесните цели е колку кодот може да биде грд. Некои луѓе можеби не се согласуваат дека чистотата и „убавноста“ на кодот се важни, но кога станува збор за долгорочно одржување на базите на кодови, можете да заштедите многу време на вашиот тим со тоа што имате код што е лесен за читање.
Додека бев во Apple, развив екосистем на финансиски апликации што ги користат внатрешните засегнати страни. Со текот на годините, постојано вклучував нови програмери во алатките за да помогнам со општо одржување или подобрувања. Еден од главните моменти од тоа време е колку е важно да можете да го читате вашиот код со природен јазик.
Интересно е да се открие дека повеќето кодови се напишани на таков начин што треба да прочитате низ значителен дел од него, а потоа да се вратите на почетокот за целосно да разберете што се случува. Користењето поекспресивен јазик или API додека пишувате код може значително да го намали времето на вклучување и зголемување на новите програмери.
Ова е местото каде што блескаат Колекциите. Колекциите на Ларавел земаат неколку комплицирани низи и ги прават неверојатно лесни за читање и разбирање. Вашиот код станува синџир на наредби, како „Филтрирајте ја оваа низа само на зборови кои почнуваат со а, потоа мапирајте го износот на трошоците во редот и на крајот намалете го на збир од сите трошоци“. Многу е лесно да се потцели важноста на пишувањето на вашиот код со поекспресивен јазик, но штом ќе станете навика, тешко е да се замисли како нешто друго е прифатливо.
Се разбира, читливоста не може да дојде на сметка на перформансите, па затоа е важно да се осигураме дека секогаш правиме здрав избор и даваме приоритет на читливоста само онаму каде што е соодветно. Секогаш треба да разбереме што се случува зад сцената и да бидеме целосно свесни за какви компромиси се соочуваме со начинот на кој пристапуваме кон нашите решенија. Не е добро нашиот код да биде читлив ако е потребно цела секунда подолго од помалку читливо решение.
Ајде да нурнеме и детално да ги погледнеме PHP низите наспроти колекциите и да ги споредиме перформансите помеѓу двете.
Една од најголемите предности на користењето на Laravel колекциите е нивната течна синтакса, која овозможува поврзување на методи. Ова резултира со чист и читлив код, бидејќи можете да извршите повеќе операции во низа без да ви требаат привремени променливи или сложени вгнездени функциски повици.
Ајде да споредиме некои од најчесто користените функции за манипулација со низи подолу за да видиме како PHP се споредува со Колекциите во многу едноставен пример.
PHP
array_filter($data, function($row) { return substr($row, 0, 1) === "a"; });
Колекции
$data->filter(function($row) { return substr($row, 0, 1) === "a"; });
PHP
array_search(function($row) { return substr($row, 0, 1) === "a"; }, $data);
Колекции
$data->search(function($row) { return substr($row, 0, 1) === "a"; });
PHP
array_map(function($row) { return "test"; }, $data);
Колекции
$data->map(function($row) { return "test"; });
PHP
sort($data);
Колекции
$data->sort();
PHP
foreach($loop as $item) { $doSomething = true; }
Колекции
$data->each(function($row) { return "test"; });
PHP
array_reduce($data, function($carry, $row) { return $carry + strlen($row); });
Колекции
$data->reduce(function($carry, $row) { return $carry + strlen($row); });
PHP
array_splice($data, count($data)/2);
Колекции
$data->splice(count($data)/2);
Сите заедно (PHP)
$data = array_filter($data, function($row) { return substr($row, 0, 1) === "a"; }); $data = array_search(function($row) { return substr($row, 0, 1) === "a"; }, $data); $data = array_map(function($row) { return "test"; }, $data); sort($data); foreach($loop as $item) { $doSomething = true; } $sum = array_reduce($data, function($carry, $row) { return $carry + strlen($row); });
Сите заедно (колекции)
$sum = $data->filter(function($row) { return substr($row, 0, 1) === "a"; })->search(function($row) { return substr($row, 0, 1) === "a"; })->map(function($row) { return "test"; })->sort() ->each(function($row) { return "test"; })->reduce(function($carry, $row) { return $carry + strlen($row); });
Споредба
Со вака едноставен пристап, се чини дека не постои голема компромис во читливоста за секоја поединечна функција, иако кога ќе го земете предвид примерот каде што треба сите да се применат на една низа, јасно може да се види дека е повеќе концизни и полесни за читање кога се користат методите со синџири во збирка.
Наместо постојано да треба да ја презапишуваме вашата променлива и потоа да поставуваме нова променлива за излез на крајот, можеме едноставно да ја врзуваме секоја команда додека не дојдеме до посакуваниот излез. Колекциите се дефинитивно полесни за читање колку што вашиот код станува покомплексен.
Ги зедов горенаведените примери и генерирав некои тест-податоци за да се обидам да утврдам дали колекциите се повеќе или помалку перформанси од стандардните PHP функции.
Секоја низа имаше 100.000 случајни низи како ставки, а јас ја извршив секоја функција 100 пати. На крајот, го пресметавме просекот на сите времиња на одговор.
Конечните резултати се подолу:
========== Tests Complete (ms) ========== php filter: 5.07 collect filter: 6.49 ======================= php search: 0.79 collect search: 0 ======================= php map: 3.45 collect map: 4.18 ======================= php sort: 25.27 collect sort: 11.18 ======================= php each: 1.03 collect each: 6.96 ======================= php reduce: 2.78 collect reduce: 7.75 ======================= php splice: 1 collect splice: 0.74 =======================
Како што можете јасно да видите, иако добиваме голема количина на читливост од Колекциите, губиме значителна количина на перформанси во некои клучни области.
Филтер , Мапа , Foreach и Reduce се побрзи со стандардните PHP функции. Foreach и Reduce се всушност неверојатно значајни разлики. Пребарување , подредување и спојување ги прикажуваат Колекциите како победници, а Сортирањето всушност е огромна заштеда на време.
Исто така, важно е да се напомене дека ќе треба да ја креирате секоја колекција од изградена низа која додава мал дел од трошоците за поставување на колекцијата за почеток, но дури и со таа мала количина дополнителна работа и време, резултатите се прилично јасно.
Според мое мислење (и тоа е само мислење засновано на овие резултати), ако перформансите предизвикуваат огромна грижа, сигурно би се придржувал до стандардната PHP функционалност за Foreach јамките и веројатно истото за сите потреби на Reduce . Ако треба да направите какво било сортирање на големи збирки на податоци, јасно е дека Колекциите се вистинскиот начин. Останатите се толку блиски што навистина се чувствува како личен избор.
Во тој момент, би рекол дека збирките се секогаш полесни за читање и одржување.
Очигледно, треба да ги земете овие информации и да донесете сопствена информирана одлука, меѓутоа, ако сте како мене, мислам дека ќе се најдете како пропуштате колекции за многу од овие функции погоре. Но, мислам дека ќе ја повратам употребата на →each
и →reduce
онаму каде што е соодветно понатаму!