Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.lang.php > #15646 > unrolled thread
| Started by | Roman Tyczka <noemail@because.no> |
|---|---|
| First post | 2018-01-18 13:37 +0100 |
| Last post | 2018-01-25 20:36 +0100 |
| Articles | 20 on this page of 51 — 8 participants |
Back to article view | Back to pl.comp.lang.php
Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-18 13:37 +0100
Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-18 18:30 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:31 +0100
Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-25 20:44 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:48 +0100
Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-25 21:22 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 23:55 +0100
Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-26 05:48 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 13:48 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-26 00:02 +0100
Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-26 23:16 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 13:09 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:04 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 23:07 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:22 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:31 +0100
Re: Dobre praktyki artiun <artiun@spam.wp.pl> - 2018-01-26 00:06 +0100
Re: Dobre praktyki denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2018-01-18 20:03 +0100
Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-21 05:03 -0800
Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-21 22:38 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-22 21:56 +0100
Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 08:16 -0800
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-24 17:20 +0100
Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 21:30 -0800
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:46 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-25 21:10 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 00:03 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-26 00:26 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 14:00 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 13:05 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 13:40 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 14:49 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 19:04 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 20:35 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 21:59 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 23:02 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:35 +0100
Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-28 00:24 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:49 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:08 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:26 +0100
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:56 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-28 00:34 +0100
Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-24 20:29 +0100
Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 21:51 -0800
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:43 +0100
Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-29 08:48 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-30 20:37 +0100
Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:45 +0100
Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-28 07:08 -0800
Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:36 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-01-18 13:37 +0100 |
| Subject | Dobre praktyki |
| Message-ID | <2lhebv1xabri$.dlg@tyczka.com> |
Może rozruszam tę grupę ;-) Mam pytanie o dobre praktyki w PHP. Chodzi mi szczególnie o kardynalne błędy, które wpływają na spadek wydajności działania skryptu. Na codzień programuję w Delphi i takich rzeczy jest sporo, które nawet nie całkiem początkujący ignorują, a które potrafią dramatycznie rzutować na wydajność. Przykładem jest przekazywanie stringów czy tablic przez wartość a nie referencję, co skutkuje alokacją i kopiowaniem pamięci a to proces czasochłonny. Czy moglibyście wypunktować kilka takich bad practicies dla PHP? -- pozdrawiam Roman Tyczka
[toc] | [next] | [standalone]
| From | Lemat <#@lemat.priv.pl> |
|---|---|
| Date | 2018-01-18 18:30 +0100 |
| Message-ID | <5a60d9c0$0$587$65785112@news.neostrada.pl> |
| In reply to | #15646 |
W dniu 18.01.2018 o 13:37, Roman Tyczka pisze: > > Może rozruszam tę grupę ;-) > > Mam pytanie o dobre praktyki w PHP. Chodzi mi szczególnie o kardynalne > błędy, które wpływają na spadek wydajności działania skryptu. Na codzień > programuję w Delphi i takich rzeczy jest sporo, które nawet nie całkiem > początkujący ignorują, a które potrafią dramatycznie rzutować na wydajność. > Przykładem jest przekazywanie stringów czy tablic przez wartość a nie > referencję, co skutkuje alokacją i kopiowaniem pamięci a to proces > czasochłonny. > > Czy moglibyście wypunktować kilka takich bad practicies dla PHP? > - includowanie kodu, który nigdy (podczas tego wywołania) się nie wykona - przechowywanie kodu poza plikami php i wykonywanie przez eval() - brak zwalniania pamięci po pracy z dużymi danymi - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE - brak keszowania fragmentów strony wynikowej mp. menu - zmieni się wtedy gdy administrator je zmieni raz na ruski rok. Ale strona (a zatem menu) zostanie pobrana wielokrotnie. Gdyby HTML odpowiedzialny za menu został wygenerowany tuż po zmianie w CMSie to każde wywołanie strony oszczędzi czas procka pobierając dane z kesza a nie wywołując procedury generowania menu. - stosowanie nieodpowiednich systemów przechowywania danych - obrazki w bazie danych, dane w CSV w pliku. -- Pozdrawiam Lemat
[toc] | [prev] | [next] | [standalone]
| From | Marek S <precz@spamowi.com> |
|---|---|
| Date | 2018-01-25 20:31 +0100 |
| Message-ID | <p4dbb2$aqf$1@node2.news.atman.pl> |
| In reply to | #15648 |
W dniu 18-01-2018 o 18:30, Lemat pisze: > - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto aby nie robić czegoś takiego jak: $sql="SELECT ... JOIN / WHERE"; $bazaDanych->execute($sql); Jeśli tak, to w jaki sposób budujesz zapytania do bazy typu PostgreSQL (moja ulubiona) lub podobna, wykonujesz je i zwracasz do PHP wyniki? Zakładam w pytaniu, że projekt jest dużo bardziej złożony niż zadanie 5 na krzyż niemodyfikowalnych zapytań SQL do bazy. -- Pozdrawiam, Marek
[toc] | [prev] | [next] | [standalone]
| From | Lemat <#@lemat.priv.pl> |
|---|---|
| Date | 2018-01-25 20:44 +0100 |
| Message-ID | <5a6a338d$0$591$65785112@news.neostrada.pl> |
| In reply to | #15669 |
W dniu 25.01.2018 o 20:31, Marek S pisze: > W dniu 18-01-2018 o 18:30, Lemat pisze: > >> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE > > Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto nie. Wręcz przeciwnie. -- Pozdrawiam Lemat
[toc] | [prev] | [next] | [standalone]
| From | Marek S <precz@spamowi.com> |
|---|---|
| Date | 2018-01-25 20:48 +0100 |
| Message-ID | <p4dca5$bid$2@node2.news.atman.pl> |
| In reply to | #15671 |
W dniu 25-01-2018 o 20:44, Lemat pisze: > W dniu 25.01.2018 o 20:31, Marek S pisze: >> W dniu 18-01-2018 o 18:30, Lemat pisze: >> >>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE >> >> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto > > nie. > Wręcz przeciwnie. Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? Jakiś przykład? -- Pozdrawiam, Marek
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-01-25 21:22 +0100 |
| Message-ID | <14g5fh47ji3uk.dlg@tyczka.com> |
| In reply to | #15673 |
On Thu, 25 Jan 2018 20:48:16 +0100, Marek S wrote: >>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE >>> >>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto >> >> nie. >> Wręcz przeciwnie. > > Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? > Jakiś przykład? Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony pomysł, ale pewnie są i tacy patenciarze ;-) -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | Marek S <precz@spamowi.com> |
|---|---|
| Date | 2018-01-25 23:55 +0100 |
| Message-ID | <p4dn8r$d4m$1@node1.news.atman.pl> |
| In reply to | #15675 |
W dniu 25-01-2018 o 21:22, Roman Tyczka pisze: > > Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po > stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony > pomysł, ale pewnie są i tacy patenciarze ;-) eeee... jakoś nie dowierzam, że o to mogłoby chodzić Lematowi. Brzmi to trochę za bardzo przekombinowanie :-D -- Pozdrawiam, Marek
[toc] | [prev] | [next] | [standalone]
| From | Lemat <#@lemat.priv.pl> |
|---|---|
| Date | 2018-01-26 05:48 +0100 |
| Message-ID | <5a6ab314$0$668$65785112@news.neostrada.pl> |
| In reply to | #15677 |
W dniu 25.01.2018 o 23:55, Marek S pisze: > W dniu 25-01-2018 o 21:22, Roman Tyczka pisze: > >> >> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po >> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony >> pomysł, ale pewnie są i tacy patenciarze ;-) > > eeee... jakoś nie dowierzam, że o to mogłoby chodzić Lematowi. Brzmi to > trochę za bardzo przekombinowanie :-D > niedowiarek... A ja znam osobiście takich programistów, którzy się na tym sparzyli. -- Pozdrawiam Lemat
[toc] | [prev] | [next] | [standalone]
| From | Marek S <precz@spamowi.com> |
|---|---|
| Date | 2018-01-26 13:48 +0100 |
| Message-ID | <p4f82l$sic$2@node1.news.atman.pl> |
| In reply to | #15684 |
W dniu 26-01-2018 o 05:48, Lemat pisze: > > niedowiarek... > A ja znam osobiście takich programistów, którzy się na tym sparzyli. To jestem pod wrażeniem :-) -- Pozdrawiam, Marek
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-01-26 00:02 +0100 |
| Message-ID | <slrnp6kof8.30gj.wojciech.bancer@pl-test.org> |
| In reply to | #15675 |
On 2018-01-25, Roman Tyczka <noemail@because.no> wrote: [...] > Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po > stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony > pomysł, ale pewnie są i tacy patenciarze ;-) Czyli każdy ORM z lazy-loadingiem? -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-01-26 23:16 +0100 |
| Message-ID | <1pk1ib81txiyp$.dlg@tyczka.com> |
| In reply to | #15678 |
On Fri, 26 Jan 2018 00:02:00 +0100, Wojciech Bancer wrote: >> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po >> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony >> pomysł, ale pewnie są i tacy patenciarze ;-) > > Czyli każdy ORM z lazy-loadingiem? Jeśli znasz ORMa, który ściąga całą tabelę, żeby wyjąć z niej jeden wiersz to zastrzel jego autora ;-) A lazy loading... domyślam się o co Ci może chodzić, że ORM żeby zrobić powiązanie między obiektami musi wczytać kilka tabel, ...ale dobry framework ORM potrafi generować JOINy na poziomie zapytań i nie musi ściągać do tego całych tabel na klienta. Nie wiem jakie ORMy są w świecie php, bo zasadniczo nie przepadam za ORMami, ale w Javie, .NET czy w Delphi ORMy potrafią inteligentnie tworzyć zapytania i wykorzystywać możliwości SQLa. -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-01-27 13:09 +0100 |
| Message-ID | <slrnp6oqvj.g5g.wojciech.bancer@pl-test.org> |
| In reply to | #15687 |
On 2018-01-26, Roman Tyczka <noemail@because.no> wrote: > On Fri, 26 Jan 2018 00:02:00 +0100, Wojciech Bancer wrote: > >>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po >>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony >>> pomysł, ale pewnie są i tacy patenciarze ;-) >> >> Czyli każdy ORM z lazy-loadingiem? > > Jeśli znasz ORMa, który ściąga całą tabelę, żeby wyjąć z niej jeden wiersz > to zastrzel jego autora ;-) Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak sobie już sobie iterujesz po obiektach będących odwołaniami do innych tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego joina. Na pewno Propel i Doctrine postępują wg metody jak wyżej. Widziałeś ORMa działającego inaczej? -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-01-27 23:04 +0100 |
| Message-ID | <1wblk1av0e74a$.wb9w9nkyczvr.dlg@40tude.net> |
| In reply to | #15690 |
Dnia Sat, 27 Jan 2018 13:09:23 +0100, Wojciech Bancer napisał(a): > Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak > sobie już sobie iterujesz po obiektach będących odwołaniami do innych > tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego > joina. > > Na pewno Propel i Doctrine postępują wg metody jak wyżej. > Widziałeś ORMa działającego inaczej? Eloquent z Laravela może na wejściu dostać "hinta" with(...) z czym dane będą w przyszłości wiązane. Wówczas potrafi zbudować takie zapytanie, które wrzuci w cache od razu więcej danych i przyszłe zapytania nawet nie dotkną bazy. Potrafi też przy iteracji grupować identyfikatory i wysłać do bazy jedno "IN (...)". Całkiem nieźle to działa. -- Borys Pogoreło borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-01-27 23:07 +0100 |
| Message-ID | <slrnp6pu11.q0u.wojciech.bancer@pl-test.org> |
| In reply to | #15702 |
On 2018-01-27, Borys Pogoreło <borys@pl.edu.leszno> wrote: > Dnia Sat, 27 Jan 2018 13:09:23 +0100, Wojciech Bancer napisał(a): > >> Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak >> sobie już sobie iterujesz po obiektach będących odwołaniami do innych >> tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego >> joina. >> >> Na pewno Propel i Doctrine postępują wg metody jak wyżej. >> Widziałeś ORMa działającego inaczej? > > Eloquent z Laravela może na wejściu dostać "hinta" with(...) z czym dane > będą w przyszłości wiązane. Wówczas potrafi zbudować takie zapytanie, które > wrzuci w cache od razu więcej danych i przyszłe zapytania nawet nie dotkną > bazy. To mi przypomina rozwiązania z Propela 1.x :) Faktycznie było to fajnie, chociaż propel miał swoje ogromne minusy (metody statyczne do obsługi zapytań baz danych). Laravel też chyba na statykach jedzie, z tego co pamiętam? -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-01-27 23:22 +0100 |
| Message-ID | <18tjyb48yyc1n.16jpg8j169v57.dlg@40tude.net> |
| In reply to | #15703 |
Dnia Sat, 27 Jan 2018 23:07:29 +0100, Wojciech Bancer napisał(a): > To mi przypomina rozwiązania z Propela 1.x :) > Faktycznie było to fajnie, chociaż propel miał swoje ogromne minusy > (metody statyczne do obsługi zapytań baz danych). Propela za bardzo nie znam. Wieki temu go macałem. > Laravel też chyba na statykach jedzie, z tego co pamiętam? Nie, jedynie w przypadku ręcznego pisania zapytań w stylu DB::select(...). Query builder jest obiektowy, eloquent tak samo. Ale jest bardzo ściśle powiązany z resztą frameworka, także może być trudno skorzystać poza nim. -- Borys Pogoreło borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-01-27 23:31 +0100 |
| Message-ID | <cd2m5pf7kta7$.3bjriv197ldm.dlg@40tude.net> |
| In reply to | #15703 |
Dnia Sat, 27 Jan 2018 23:07:29 +0100, Wojciech Bancer napisał(a):
> Laravel też chyba na statykach jedzie, z tego co pamiętam?
Ach, pytasz generalnie o Laravela. Nie do końca. Twórca wymyślił sobie coś,
co nazwał fasadą i działa to tak, że wywołanie statyczne jest
przekształcane w wywołanie kontenera IoC. Czyli pisząc DB::table() tak
naprawdę wołasz app('db')->table(). Społeczność jest mocno podzielona w
sprawie tego rozwiązania i nie dziwię się temu. Ale nie trzeba z tego
korzystać.
--
Borys Pogoreło
borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | artiun <artiun@spam.wp.pl> |
|---|---|
| Date | 2018-01-26 00:06 +0100 |
| Message-ID | <5a6a64e3$0$1678$65785112@news.neostrada.pl> |
| In reply to | #15673 |
W dniu 2018-01-25 o 20:48, Marek S pisze: > W dniu 25-01-2018 o 20:44, Lemat pisze: >> W dniu 25.01.2018 o 20:31, Marek S pisze: >>> W dniu 18-01-2018 o 18:30, Lemat pisze: >>> >>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE >>> >>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto >> >> nie. >> Wręcz przeciwnie. > > Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? > Jakiś przykład? > Wszystko zależy. Czasem nie dasz rady. To wygląda tak, dostałem zlecenie na zrobienie ornungu w bazie. Miałem założyć triggery (służące utrzymaniu porządku między tabelami). Zrobiłem na developerskiej bazie, przyszedł czas na wdrożenie, wszyscy dostali papiery z opisem zależności. Nie minęło 2h i gość przyłazi "Do bazy nic nie mogę dopisać" ???!!!! Z innej mańki, baza ma swoją logikę, dane są rozrzucane i zapisywane w różnych tabelach. Nie próbuj tego łamać na siłę, powinieneś dostać procedury/funkcje, które realizują logikę bazy. Żeby załapać co wymyślili w Insert (MS SQL) zeszło mi z miesiąc, choć w bazie na żywca nie odważyłem się grzebać :) -- Artur
[toc] | [prev] | [next] | [standalone]
| From | denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2018-01-18 20:03 +0100 |
| Message-ID | <p3qr2f$1k3$1@node1.news.atman.pl> |
| In reply to | #15646 |
fajne to pytanie to pytanie z cyklu "jak lepiej zoptymalizować na etapie pisania programu zamiast zwalić to na kompilator" - wiele łbów na politechnice na tym poległo...
[toc] | [prev] | [next] | [standalone]
| From | Rafal Podsiadly <spinacz24@gmail.com> |
|---|---|
| Date | 2018-01-21 05:03 -0800 |
| Message-ID | <6d0bd754-9b46-46ce-98ff-c5265a9a93af@googlegroups.com> |
| In reply to | #15646 |
Dobre praktyki. (1 -5) załatwiają frameworki 1. Projekt opieraj o klasy i obiekty. 2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania) 3. Wykorzystuj zmienne statyczne w stałych plikach (ograniczysz kopiowanie zmiennych). 4. Poznaj różnicę między przekazaniem argumentu do funkcji a argumentu do metody (klasa w funkcji) 5. Ograniczaj używanie zmiennych globalnych do minimum. 6. W metodach buduj gettery i settery a zmienne dawaj do private. Poznaj PSR-1/2/3 -> to standard (hardcorowcy idą do 7 :)
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-01-21 22:38 +0100 |
| Message-ID | <1p8x8la6msc28.dlg@tyczka.com> |
| In reply to | #15656 |
On Sun, 21 Jan 2018 05:03:14 -0800 (PST), Rafal Podsiadly wrote: > 2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania) Właśnie trafiłem na notkę w opisie: Warning This feature has been DEPRECATED as of PHP 7.2.0. Relying on this feature is highly discouraged. -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | pl.comp.lang.php
csiph-web