Advies van scripting naar classes overstappen
Mijn applicatie heeft enkel functionele doeleinden. De content is van minder belang.
Zowel HTML als de php is scripting geschreven. Ook hier en daar is inmiddels javascript toegevoegd om de applicatie gebruiksvriendelijker te maken.
Het programma werkt prima en de gebruikers zijn tevreden. Echter, ik ben de enigste die snapt wat er is geprogrammeerd. Ik heb wel op veel plekken commentaar toegevoegd ter verduidelijking van de code. Dit is dus erg kwetsbaar als ik zou uitvallen.
Enkel om meer duidelijkheid en structuur aan mijn code te geven wil ik overstappen op object oriented programming.
Ooit ben ik al eens begonnen met Laravel. Ik snap de beginselen maar vraag me af of wat complexere queries of andere zaken makkelijk in Laravel is op te lossen. Ook heb ik het idee dat ik met scripting veel meer verschillende functionaliteiten op 1 pagina kan zetten terwijl er met Laravel al snel met een nieuwe pagina wordt gewerkt. Tonen, invoer en wijzigen bijvoorbeeld gebeurd nu door een gebruiker op 1 pagina. Medicatie toevoegen per dier of per groep dieren gebeurd nu ook door een gebruiker op 1 pagina.
Ook heb ik de tutorial https://www.phphulp.nl/php/tutorial/overig/oop-beginnershandleiding-php5/701/ gelezen. Ik snap wat er staat maar hoe dit te vertalen naar mijn programma is lastig. Hiervoor zal ik het moeten gaan toepassen denk ik.
Daarnaast heb ik een klein programma geschreven in C# dat lokaal bij gebruikers is geïnstalleerd. Dit programma stuurt data van een elektronische reader naar de website en andersom middels json.
Mijn huidige code zal dus niet zomaar zijn overgezet naar OOP. Ik wil dus een wel overwogen keuze maken om ergens naar over te stappen.
Of moet ik uberhaupt niet overstappen met een 6-tal gebruikers?
Het is mijn hobby en zowel mijn opdrachtgever als ik streven naar meer gebruikers echter de schapensector heeft weinig registratieverplichtingen en ze zien vaak het nut er niet van in. Het kost hun meer (tijd en geld) dan dat het oplevert denken ze. Juist omdat het commercieel minder interessant is probeer ik in dat gat te springen en wil dat voorlopig blijven doen.
Heeft iemand nog adviezen waar naar over te stappen?
Ik gebruikte hiervoor Heredoc/Nowdoc: https://www.php.net/manual/en/language.types.string.php
Daar kan geen query-builder tegenop.
OOP maakt code niet duidelijker. OOP is bedoeld om code op te delen in behapbare brokken.
PHP is een nare taal voor een groter product, ik heb in 8 maanden mijn project (> 1MB PHP code) omgeschreven naar Rust (https://rust-lang.org) en het werkt geweldig, met een eigen embedded multithreaded webserver aan het einde van de cursusdocumentatie op https://doc.rust-lang.org/book/ch20-00-final-project-a-web-server.html .
Ze zeggen dat Rust een steile leercurve heeft. Maar mijn ervaring is dat als je eerder al in aaraking bent gekomen met het vak computer science, dat het reuze mee valt.
De vraag is of jouw programma in aanmerking komt voor label 'groter product', of je blijft roeien met PHP of dat je overstapt naar een serieuze programmeertaal (in plaats van een scripttaal).
Waarom sluit je je niet aan bij een Rust-forum of begin je je eigen Rust-forum? Word je daar niet veel gelukkiger van? Is toch veel leuker (ook voor de overige leden) dan hier telkens je frustraties te uiten over PHP?
Wanneer programmeren meer dan een hobby kan worden, kan het geen kwaad om je af te vragen wat je met PHP wilt:
Grootste voordelen:
- hele platte leercurve
- met weinig moeite maak je iets dat voldoet
- het werkt overal op alle systemen
- grote community
Grootste nadelen:
- hele lange leercurve (PHP verbergt met succes veel complexiteit)
- iets maken dat echt goed (en veilig) is blijft lastig
- je kunt er geen echte programma's mee maken omdat het een scripttaal is
- kritiek wordt doorverwezen
Toepassing PHP:
Zoals ik het zie is PHP ideaal voor pilots en kleinere codebases, met als sterkste kant ontwikkeling voor het (server side) web, waarbij Intellectueel Eigendom (IE) geen issue mag zijn.
Omdat je geen objectcode van PHP kunt maken kan je PHP niet inzetten om jouw IE te beschermen. Een veelgebruikte omweg is om software als dienstverlening (SaaS) aan te bieden, maar dat wordt niet gewaardeerd door de community, hierdoor is de GPL Affero-licentie ontstaan.
Toekomst:
PHP is groot geworden dankzij de opkomst van het website-gebaseerde internet sinds 1995. Er wordt nog steeds veel mee gedaan maar de focus van het internet is verschoven naar Apps. In dit deel kan PHP niet mee. Je kunt bijvoorbeeld geen PWA maken zonder JavaScript. Sinds asm.js is er nog een nieuwe ontwikkeling om PWA's dezelfde prestaties te geven als 'native apps', door in een browser toegang te geven tot de 'virtuele machine' waarop JavaScript draait, via een binair formaat 'WebAssembly'. Om hiervan gebruik te kunnen maken is het nodig dat je broncode kunt compileren tot objectcode in het WASM-formaat. Dat is niet mogelijk met PHP, hiervoor zou PHP volledig op de schop moeten en dat bleek met PHP 6 al onwerkbaar (PHP 6 is nooit gekomen). De ontwikkelaars proberen daarom PHP op een andere manier aantrekkelijker te maken, door steeds meer functionaliteit toe te voegen en basisfunctionaliteit (langzaam) te verbeteren, waardoor je minimaal elke drie jaar (vanwege de doorloopsnelheid van PHP) je eigen code moet herzien omdat het dan waarschijnlijk niet meer werkt.
(Mijn) conclusie: zolang er websites en stateless webapplicaties zijn zal er behoefte blijven aan PHP, vanwege de platte leercurve en beschikbaarheid. Software is vanwege veiligheid altijd aan verandering onderhevig. Daarbij zijn er ook talen die meer doordacht zijn met (veel) minder uitzonderingen, waardoor je sneller kunt werken en waardoor jouw code altijd zal blijven werken. Met die talen heb je wel toegang tot PWA's, WASM en dus serieuze apps/programma's kunt maken en verkopen, ook voor tablets, smartphones en embedded hardware.
Voor Bas de wedervraag waar hij met zijn software naartoe wil.
Bas van de Ven op 21/11/2023 18:34:30:
Echter, ik ben de enigste die snapt wat er is geprogrammeerd. Ik heb wel op veel plekken commentaar toegevoegd ter verduidelijking van de code. Dit is dus erg kwetsbaar als ik zou uitvallen. Enkel om meer duidelijkheid en structuur aan mijn code te geven wil ik overstappen op object oriented programming.
[...]
Heeft iemand nog adviezen waar naar over te stappen?
[...]
Heeft iemand nog adviezen waar naar over te stappen?
Ja. Om deze kwetsbaarheid te verkleinen is het raadzaam om de software vrij te geven als open source. Dat maakt het praktisch toekomstbestendig en neutraliseert juridisch de continuïteitsvraag.
Dan zit je nog met het probleem dat jij de enige bent die heel specifieke domeinkennis heeft van de schapensector. Dit zal je ook moeten overdragen aan anderen. Wanneer die er (nog) niet zijn is het beste dat je kunt doen zoveel mogelijk je kennis en keuzes documenteren, en de context beschrijven hoe en waarvoor het programma wordt gebruikt. (Dat kan een heel epistel worden).
Met mijn eerdere uiteenzetting van de voor- en nadelen kan je er voor kiezen om het wel of niet OOP te maken, en afhankelijk van de context of je op een andere taal over wilt gaan. Misschien wil je je programma geschikter maken voor smartphones, en het ook laten werken wanneer er even geen internetverbinding is? En of je dat met je hobbytijd (of betaald?) wilt gaan doen. Dat soort afwegingen moet je zelf maken.
Toevoeging op 23/11/2023 07:48:45:
Kleine toevoeging; OOP is slechts een manier om code te organiseren, het kan goed werken wanneer meerdere mensen tegelijk aan software werken. Maar OOP heeft ook nadelen die met andere methoden op te lossen zijn, bijvoorbeeld met 'compositie' van software in plaats van een hiërarchie van objecten.
OOP gaat het probleem van overdracht niet veranderen. Het is ook niet direct nodig voor stateless webapplicaties. Neem bijvoorbeeld het bekende bugtrackingsysteem MantisBT dat is gemaakt op de C-manier.
Ik zal het e.e.a.in overweging nemen.