Kwaliteit is niet te meten. Dat bepaald de gebruiker.
Mijn bedoeling is enkel een kleine vergelijking met andere projecten van zowel amateurs als (semi) professionelen.
?Onbekende gebruiker
16-08-2023 08:06
gewijzigd op 16-08-2023 08:13
Mijn grootste PHP-project (in aantal bestanden en aantal bytes, alleen eigen code):
- PHP: 124 bestanden, 1280 KiB
- CSS: 3 bestanden, 60 KiB
- JS : 1 bestand, 24 KiB
Ward merkt terecht op dat je daar niet de kwaliteit van code kan vergelijken. Kwaliteit is een waarde(oordeel) op een bepaalde schaal. Op welke schalen zou je code kunnen vergelijken?
Het aantal bytes meet niet de veelheid aan code, noch de complexiteit en begrijpbaarheid. Daarbij moet je eigenlijk ook nog de correctheid en elegantie meenemen in de vergelijking. (Spoiler: elegantie is weinig populair omdat het omdat het meer moeite kost om te bereiken en een goede opvoeding om te waarden.)
En dan heb je nog dingen als standaarden (bv. PSRs) en je linter waar je rekening mee kunt houden.
Bijna vergeten omdat het zo in mijn eigen systeem zit: vergeet ook vooral niet de veiligheid van de code mee te weten. Ik verwijs altijd naar OWASP vanwege hun handige cheat sheets. In Nederland moet je vaak aan de ISO 27000-series voldoen, en voor medische informatie ook aan de NEN-7510, en als je voor overheden werkt aan de BIO.
Kwaliteit is wél te borgen en daarbij indirect te meten. Mijn grootste project heeft bijvoorbeeld meer dan 30.000 unit tests met ruim 60.000 assertions en een code coverage van meer dan 80 procent. En nog belangrijker: 0 errors en zero defects.
Dit heeft gevolgen voor de omvang. Voor elk PHP-bestand in de directory src met broncode bevat de directory tests een PHP-testbestand voor PHPUnit. Deze directorystructuur is eerder regel dan uitzondering bij PHP-projecten die test-driven development (TDD) toepassen.
Dat zegt meer dan het feit dat ik daarmee nu 7,8 MiB code heb, waarvan 89,6 procent PHP.
?Onbekende gebruiker
16-08-2023 08:27
Wat een groot project, en wat een berg aan unit tests! Dat was vast een hele hoop werk om ze allemaal te controleren met de invoering van PHP 8?
Helaas bewijzen tests niet dat er helemaal geen errors zijn. Elke lijst aan tests blijft groeien naarmate een programma langer bestaat en/of groter wordt.
Omdat ik alle code zelf heb geschreven heb ik overzicht, en kan ik zonder tests toe. Hoewel ik wel erg enthousiast ben over TDD en de positieve effecten op het ontwikkelproces zelf, ben ik er helaas nog niet aan toe gekomen.
Wat een groot project, en wat een berg aan unit tests! Dat was vast een hele hoop werk om ze allemaal te controleren met de invoering van PHP 8?
Het is eerder omgekeerd: bij elke update van PHP melden errors in de unit tests exact, op de regel nauwkeurig, welke code incompatibel is geworden. Ik ben er met PHP 5.3 in 2014 mee begonnen en dat heeft dus werk bespaard bij alle minor en major updates vanaf PHP 5.4 via PHP 7 naar nu PHP 8.2.
Ad Fundum op 16/08/2023 08:27:55
Helaas bewijzen tests niet dat er helemaal geen errors zijn. Elke lijst aan tests blijft groeien naarmate een programma langer bestaat en/of groter wordt.
Klopt, maar dat is meer een logische consequentie van TDD dan een structureel nadeel. je kunt unit tests heel goed gebruiken om te debuggen. Als je TDD wilt gaan toepassen, zou ik hier zelfs mee beginnen: heb je een bug gevonden, schrijf dan een unit test die de bug reproduceert en verbeter vervolgens de code tot de test groen op pass gaat.
Ad Fundum op 16/08/2023 08:27:55
Omdat ik alle code zelf heb geschreven heb ik overzicht, en kan ik zonder tests toe.
Ik gebruik (of misbruik) PHPUnit voor meer dan alleen unit tests. Ik voer er ook acceptatietests, performancetests en end-to-end tests mee uit.
Daarnaast "documenteer" ik er de code mee. Goede unit tests illustreren met voorbeeldcode hoe je classes, interfaces en andere constructies gebruikt. Doel daarbij is dat je hiermee mijn hele framework kunt doorzien, zonder ook maar één regel van de onderliggende PHP-code te moeten lezen.
Bedankt aan allen voor alle info en data van wie heeft meegewerkt.
Ik weet dat het relatief blijft. ik wou gewoon eens een héél klein beetje vergelijken. Ook de reden dat ik geen afbeelding zal vergelijk. Met wat? resolutie, bpi,... :) dus ook niet te doen.
Gewoon wou ik weten of dit al IETS is.
Mijn conclusie is dus eigenlijk als niet -pro niet slecht
Ik heb net héél veel achtergrond processen verbeterd met info's ontvangen van jullie uit het verleden. Oude code verwijderd. DRY sterk verminderd. Ook ik modderde wat aan in het begin en zelf nu heb ik af en toe hulp nodig.
