Keresés

Új hozzászólás Aktív témák

  • PazsitZ

    addikt

    válasz cucka #11817 üzenetére

    Alapvetően abban egyetértek, egy házi 2 formos php kódot, lehet felesleges OOP-ben megírni.
    Továbbá, ha már adott is egyegyszerűbb kód, felesleges egy csv felolvasást köré 5-10 osztályt felhúzni.

    Viszont, ha én kezdenék bele, akkor már fognék egy framework-öt, ami segítségével oldanám meg a dolgokat.
    Alapvetően a PHP-s framework-ök is OOP irányba mennek, amit az én észrevételeim alapján a nyelv is egyre inkább támogat.
    Abban van igazság, hogy ez script nyelv, de ettől még nem a register globals és levegőbe lógó függvények szempontjából kell használni szvsz.

    Amennyiben pedig elkezdesz egy OOP framework-kel dolgozni, akkor viszont igenis namespace és osztálystruktúrát kell használni, nem kavarni a dolgokat.

    A TDD hasznos dolog, kellő rálátás esetén jobban ki is kényszeríti a szebb kódot, SRP-t, amiből már könnyen jön a panaszolt "overgeneralization".

    (#11820) Soak:
    Egyébként nem olyan könnyű eltalálni a balanszot.
    Egyik oldalról ott van az a szabály, hogy csak a kért feature-t fejleszd, ne űrhajót.
    Másik részről viszont rá lehet/kell érezni, mi az, ami a következő iterációban biztos be lesz rendelve. Ebben az esetben pedig nem árt, ha kicsit előre gondolkozva tervezel, kellő mértékben absztrakt a kódod, hogy ne kelljen szétdúrni és gyors-hatékony lehess.

  • Peter Kiss

    őstag

    válasz cucka #11817 üzenetére

    Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét, és klasszul lehetne használni, csak épp az elterjedtsége ellenére is kevesen próbálkoznak kiaknázni minden lehetőségét.

    Mit vett át funkcionális nyelvekből?

    Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap (@Soak: termelő vállalatnál kell ügyviteli és termeléstámogató szoftvereket fejleszteni, sajnos eddig szinte csak legacy [és szar] kódokat kellett támogatni). De akkor végül is azt mondod, hogy PHP-val hegesszen mindenki úgy, hogy csak az adott problémára koncentráljon, legyen kész, és rendben is van a dolog?

    Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva. Premature optimization valóban veszélyes lehet, de igazából csak azt fenyegeti, aki rettentően unatkozik, és valamilyen oknál fogva előre látni véli a rossz teljesítményű pontokat.
    Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni. ;)

    TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelni, vagy nagyon nagy mocskot kell csinálnod, ezzel szemben egy interface-ből stub-ot/mock-ot hegeszteni nem nagy mutatvány. (Smoke tesztnek tényleg nincs köze az OO/nem OO dologhoz (bármit lehet rosszul tesztelni), de nem is azért írtam.)

Új hozzászólás Aktív témák