Programavimas be PHP framework'ų? [Kam jie reikalingi?]

Prieš 25 minutes, brogrammer parašė:

Tau trūksta patirties, suvokiant savo įrankius, bei paprasta kalba paaiškinant jų reikalingumą.

del sql'o: ka darysi, kai (kaip pries tai minejo), dirbsi su viena DB, o paskui ja pakeisti turesi? Begsi per visus SQL ir ranka kaitaliosi? Ka daryti, jeigu projektas didelis? Kiek laiko sugaisi tam? Naudojant lib'a tam, vienintelis tavo pakeitimas butu prisijungimo pakeitimas (yra atvejais, kai koks DB kazko nepalaiko, ka kitas palaiko, bet pakankamai retas).

O kai nauja projekta kuri, ar neimi is seno projekto nieko? Viska nuo 0 darai? 

Daugiau: 

prieš 3 valandas, 0djek parašė:

del sql'o: ka darysi, kai (kaip pries tai minejo), dirbsi su viena DB, o paskui ja pakeisti turesi? Begsi per visus SQL ir ranka kaitaliosi? Ka daryti, jeigu projektas didelis? Kiek laiko sugaisi tam? Naudojant lib'a tam, vienintelis tavo pakeitimas butu prisijungimo pakeitimas (yra atvejais, kai koks DB kazko nepalaiko, ka kitas palaiko, bet pakankamai retas).

O kai nauja projekta kuri, ar neimi is seno projekto nieko? Viska nuo 0 darai? 

Daugiau: 

Dėkui už linką. Dėl DB API suprantu argumentą ir jam pritariu(bet tam frameworko nereikia, PHP turi įmontuotą funkcionalumą - PHP data objects). Dėl kodo pernaudojimo - pilnai pritariu. Bet manau, jog geriau pernaudot savo kodą, kurį suprantu, negu kažką, kas ateity gali sukelti bėdų, kurias išspręsti reiks braidžiot per stack overflow.
https://www.frameworklessmovement.org/

Jeigu projektą kursi sau, tai kodą rašyk nors ir lietuviškai, nesilaikant psr, solid, dry ir kitų principų, nesvarbu.

Bet jeigu tai projektai klientams, įmonės vidinės sistemos arba tie projektai, prie kurių dirbs ir kiti programuotojai, tai pats pagalvok ar lengviau yra susipažinti kai yra naudojami standartai (nors ir primityvus) ar belekaip parašytas kodas, kuri svarbu tu supranti?

Kodėl verta naudoti? Nes:

Greičiau, tau nereikia galvoti kaip parašyti paprasčiausius funkcionalumus kaip pvz. routing.

Saugiau, pvz. symfony ar laravel community yra didelis ir dažnu atvėju security issues nepasiekia releas'o, o jeigu pasiekia - būna pataisyta ir tau nereikia apie tai galvoti, o tik atnaujinti packages arba framework'o versiją.

Naujokams prie projekto lengviau susipažinti su pačiu projektu, žino kur ieškoti modelius, servisus, repositorijų ir t.t.

Apibendrinus, tai greičiausiai esi entry-level, max junior level, tai šitas klausimas bus atsakytas, kai padirbsi prie projektų ir suprasi jų naudą pats. Dar gali būti, kad nesi dirbęs prie vidutinio dydžio projekto arba nebandei scalinti projektų, rašant viską nuo nulio tu tiesiog užsiknisi tą patį visadą rašyti. O bijoti dėl performance šiais laikais tikrai nereikia, kodas gali būti ir tvarkingas ir greitas.

Mano patarimas būtų, tai kas be ko naudoti framework'us, laikytis psr, dry, solid ir kitų principų, domėtis geromis praktikomis ir taip augsit gerais specialistais, nes šūdarankių pilną, vežk vežimais, bet gerų, tvarkingų - maža dalis.

Framework yra jau kaip template, kuris padeda sutaupyti daugybe laiko programuojant standartinius sprendimus, jeigu tokiu dalyku nesuvoki tai isvis dar esi zalias programavime

prieš 2 valandas, babunas parašė:

Framework yra jau kaip template, kuris padeda sutaupyti daugybe laiko programuojant standartinius sprendimus, jeigu tokiu dalyku nesuvoki tai isvis dar esi zalias programavime

Esmė, kad ne žalias, teko girdėti senioro pasakojimų, kaip į interviu atėję programeriai nesugeba 2+2 sudėti be frameworko pagalbos. Tiesiog atrodo, jog kartais tenka naudoti sprendimus pilnai nesuprantant jų naudos, tai kyla klausimas ar visi aplinkui mane tiesiog apsimetinėja, jog supranta ką ir dėl ko naudoja, kad jų nekompetencija neišlystų?
Ar visą likusią savo karjeros dalį turiu save pasmerkt nežinojimui naudojant abstrakcijas, kurios neaišku man reikalingos ir ką daro?

Prieš valandą, brogrammer parašė:

Esmė, kad ne žalias, teko girdėti senioro pasakojimų, kaip į interviu atėję programeriai nesugeba 2+2 sudėti be frameworko pagalbos. Tiesiog atrodo, jog kartais tenka naudoti sprendimus pilnai nesuprantant jų naudos, tai kyla klausimas ar visi aplinkui mane tiesiog apsimetinėja, jog supranta ką ir dėl ko naudoja, kad jų nekompetencija neišlystų?
Ar visą likusią savo karjeros dalį turiu save pasmerkt nežinojimui naudojant abstrakcijas, kurios neaišku man reikalingos ir ką daro?

Tai čia jau ne frameworko kaltę, o pačio programerio. Mikrokontrelius pvz programuojant irgi gali naudoti abstrakcijas, tačiau jeigu reikia greičio, tikslumo ar dar kažko, ko negali pasiekti naudojant abstrakcijas, tada tenka dirbti be jų. VSCode frontend'as su plain JavaScript (arba typescript, nlb pamenu) padarytas, nes jiems greičio reikėjo ir tikslumo. Patys pasidarydami FE framework'a, jie valdo, kaip elementus sukuria, kada juos sukuria, patys gali susitvarkyti bug'us vietoj to, kad laukti, kol kažkas kitas tą padarys.

Dėl to daug kas ir pataria pasimokyti, kelis paprastus projektus pasidaryti be įrankių, kad zinotum, kaip kas ir kodėl. Abstrakcijas naudoji, nes žinai kas būtų be jų ir tiesiog pasilengvini gyvenimą.

Kažkas aukščiau rase, kad frameworkai taip pat struktūros suteikia, padeda komandoje dirbti bei išplėsti, jeigu kada to prireikia. 

prieš 6 valandas, babunas parašė:

Framework yra jau kaip template, kuris padeda sutaupyti daugybe laiko programuojant standartinius sprendimus, jeigu tokiu dalyku nesuvoki tai isvis dar esi zalias programavime

Kaip matau ne vistiem duota mastyti out of the box. Gaila biškį. Tavo klientų ir serverio.

prieš 4 valandas, brogrammer parašė:

Kaip matau ne vistiem duota mastyti out of the box. Gaila biškį. Tavo klientų ir serverio.

Kurioj vietoj pas jį kas blogai? Nelabai supratau, dėl ko ji puoli, kai jis tiesa sako 😄

ir priciom čia klientų ir serverio gaila? Paaiškino biski

prieš 20 valandų, 0djek parašė:

Kurioj vietoj pas jį kas blogai? Nelabai supratau, dėl ko ji puoli, kai jis tiesa sako 😄

ir priciom čia klientų ir serverio gaila? Paaiškino biski

Blogai nes jis tiesiog pasakė tai kas ir taip aišku, jog frameworkai yra templeitai, turintys palengvint darbus, nu ir aišku tipinis lietuvis su tipine replika ant galo dėjo. Klientų ir serverio gaila, nes kartais gali nukentėti kokybė, kai aklai paimamas frameworkas, darbui, kuriam pakanka savo kodo. Turiu omeny serverio apkrovas.

Beje čia keli žmonės paminėjo, jog db api gali išgelbėt jeigu ateity norėsiu migruoti kodą iš mysql į postogre, man įdomu kiek Jūsų pačių praktikoje pasitaikė tokių dalykų?

prieš 6 valandas, brogrammer parašė:

Blogai nes jis tiesiog pasakė tai kas ir taip aišku, jog frameworkai yra templeitai, turintys palengvint darbus, nu ir aišku tipinis lietuvis su tipine replika ant galo dėjo. Klientų ir serverio gaila, nes kartais gali nukentėti kokybė, kai aklai paimamas frameworkas, darbui, kuriam pakanka savo kodo. Turiu omeny serverio apkrovas.

Beje čia keli žmonės paminėjo, jog db api gali išgelbėt jeigu ateity norėsiu migruoti kodą iš mysql į postogre, man įdomu kiek Jūsų pačių praktikoje pasitaikė tokių dalykų?

Jeigu sugebi ant tiek blogai pasinaudoti framework'u, kad visur darbas stoja: cia jau ne template'o problema. Plius dauguma framework'u yra tikrai geriau optimizuoti, negu kad galetum rankomis pasidaryti. Arba naudoji toki framework'a, kuris jau letas yra ir visi skundziasi, kad letas yra.

Nori pasakyt, kad jeigu darysi API, kur yra 2 endpoint'ai ir lieps daryti tau su Python pvz, pats ranka rasyti socketus, juos priziuresi, paskirstysi pagal uzklausos URL i teisingus metodus ir pns? Nes naudojant koki Flask arba FastAPI butu per "leta" bei "uzkrausi serveri"? Ka darysi, kai reikes ta API isplesti iki 10 endpoint'u? O puses metu iki 20? Nori pasakyt, kad tavo homemade veiks geriau, greiciau, patikimiau, patogiau prisiziures ir bus galima lengviau isplesti negu naudojant framework'a? Tikrai taip nebus ir sau paciam nemeluok, kad taip padaryt galetum. As darydamas su framework'u galesiu business logic daryti, kol tu toliau prakaituosi ir bandysi optimizuot. Ir vistiek tokio pat gero rezultato nepasieksi, koki biblioteka duoda.

Mano sita arba praignoravai, arba tiesiog neatsakei: 

Man paciam del DB dar tokio nebuvo, kad reiketu duombazes keisti (per maza imone ir per mazai migruojam, kad ta daryti). Bet buvau uni projektui pasidares, kad in production naudojju MySql, o local'iai su SqlLite . Kadangi naudojau DB API, man tarp environments kodo keisti nereikejo, uztekdavo pakeisti prisijungimo duomenis, visus skirtumus tarp duombaziu (jeigu tokiu net buvo, neisivaizduoju) sutvarke biblioteka. Dar va reddit'o link'as del DB: 

Beje, kaip atrodo pas tave tas PHP ir DataBase duomenu pasiimamas? Pamenu kazkoki rasei, bet nenaudoju PHP, nezinau kaip veikia. Kiek maciau doc'se, tai ranka turi rasyti uzklausas bei tarp puslapiu vaiksciot ir pns?

prieš 5 valandas, 0djek parašė:

Jeigu sugebi ant tiek blogai pasinaudoti framework'u, kad visur darbas stoja: cia jau ne template'o problema. Plius dauguma framework'u yra tikrai geriau optimizuoti, negu kad galetum rankomis pasidaryti. Arba naudoji toki framework'a, kuris jau letas yra ir visi skundziasi, kad letas yra.

Nori pasakyt, kad jeigu darysi API, kur yra 2 endpoint'ai ir lieps daryti tau su Python pvz, pats ranka rasyti socketus, juos priziuresi, paskirstysi pagal uzklausos URL i teisingus metodus ir pns? Nes naudojant koki Flask arba FastAPI butu per "leta" bei "uzkrausi serveri"? Ka darysi, kai reikes ta API isplesti iki 10 endpoint'u? O puses metu iki 20? Nori pasakyt, kad tavo homemade veiks geriau, greiciau, patikimiau, patogiau prisiziures ir bus galima lengviau isplesti negu naudojant framework'a? Tikrai taip nebus ir sau paciam nemeluok, kad taip padaryt galetum. As darydamas su framework'u galesiu business logic daryti, kol tu toliau prakaituosi ir bandysi optimizuot. Ir vistiek tokio pat gero rezultato nepasieksi, koki biblioteka duoda.

Mano sita arba praignoravai, arba tiesiog neatsakei: 

Man paciam del DB dar tokio nebuvo, kad reiketu duombazes keisti (per maza imone ir per mazai migruojam, kad ta daryti). Bet buvau uni projektui pasidares, kad in production naudojju MySql, o local'iai su SqlLite . Kadangi naudojau DB API, man tarp environments kodo keisti nereikejo, uztekdavo pakeisti prisijungimo duomenis, visus skirtumus tarp duombaziu (jeigu tokiu net buvo, neisivaizduoju) sutvarke biblioteka. Dar va reddit'o link'as del DB: 

Beje, kaip atrodo pas tave tas PHP ir DataBase duomenu pasiimamas? Pamenu kazkoki rasei, bet nenaudoju PHP, nezinau kaip veikia. Kiek maciau doc'se, tai ranka turi rasyti uzklausas bei tarp puslapiu vaiksciot ir pns?

Nepraignoravau, sutinku su Tuo ką ten parašei. Socketų aišku kad nerašysiu pats(nors kiek teko su socket API žaist, tai jis paprastesnis negu šiuolaikiniai OOP frameworkai). Pastebėjimas, kad ne frameworko kaltė, o programerio šeip įdomus - motyvuoja geriau išmokti tai ką naudoju, kad būtų tikslesnė kritika arba didesnis vertinimas tiem kas parašė man įrankius. Dėkui už linkus. PHP turi savo ORM native palaikomą viduje.

Prieš 30 minučių, brogrammer parašė:

Nepraignoravau, sutinku su Tuo ką ten parašei. Socketų aišku kad nerašysiu pats(nors kiek teko su socket API žaist, tai jis paprastesnis negu šiuolaikiniai OOP frameworkai). Pastebėjimas, kad ne frameworko kaltė, o programerio šeip įdomus - motyvuoja geriau išmokti tai ką naudoju, kad būtų tikslesnė kritika arba didesnis vertinimas tiem kas parašė man įrankius. Dėkui už linkus. PHP turi savo ORM native palaikomą viduje.

paprastesnis tai gal va kai ne daug endpoint'u, bet kai prisides daug daugiau visokiu papildomu detaliu sone (auth, middlewares, etc), tada ir bedos prasides. As pavydziui naudoju ASP.Net core framework'a API kurti, tai jis man issprendzia tokius dalykus:

1. Middlewares
2. Dependency injection
3. Swagger docs
4. Authentication
5. Authorization
6. Auto request and response parsing
7. Tikrai tikiu kad dar daugiau yra, kurios nuo manes pasleptos

Jeigu kalba turi ORM, kuri patogu naudoti: why not. C# man rodos patogaus by default neturi, tai kazka naudoti tenka. ORM patogu naudoti, nes man uztenka nurodyti is kokio context'o pasirinkti kokia lentele, ideti filtrus, prijungti papildomas lenteles ir man automatiskai viska padaro, nereikia nieko paciam stengtis. Jeigu pasikeite DB scheme, uztenka pergeneruot modelius ir klaidas sutvarkytos del pakeistu pavadinimu (jeigu tokiu yra).

Čia tas pats kas dėžę alaus nusipirkti, alų išpilti, priduoti butelius ir gautus pinigus pragerti.

 Analtinio mastymo pas tamsta nerasta, kas siaip budinga programuotojui, jeigu elementariu dalyku nesuvoki

prieš 7 valandas, 0djek parašė:

paprastesnis tai gal va kai ne daug endpoint'u, bet kai prisides daug daugiau visokiu papildomu detaliu sone (auth, middlewares, etc), tada ir bedos prasides. As pavydziui naudoju ASP.Net core framework'a API kurti, tai jis man issprendzia tokius dalykus:

1. Middlewares
2. Dependency injection
3. Swagger docs
4. Authentication
5. Authorization
6. Auto request and response parsing
7. Tikrai tikiu kad dar daugiau yra, kurios nuo manes pasleptos

Jeigu kalba turi ORM, kuri patogu naudoti: why not. C# man rodos patogaus by default neturi, tai kazka naudoti tenka. ORM patogu naudoti, nes man uztenka nurodyti is kokio context'o pasirinkti kokia lentele, ideti filtrus, prijungti papildomas lenteles ir man automatiskai viska padaro, nereikia nieko paciam stengtis. Jeigu pasikeite DB scheme, uztenka pergeneruot modelius ir klaidas sutvarkytos del pakeistu pavadinimu (jeigu tokiu yra).

Manau su patirtim supratimas ateis. Ko gero gudriau rašyt kodą, negu ginčytis internete. Bet sukūrus kontraversišku tonu pateiktą temą gavau ganėtinai konkrečių ir gerų atsakymų.