Hoe groot zijn jullie projecten?
Gewoon uit nieuwsgierigheid :) Hoe groot zijn jullie projecten.
Mijn competitie webpagina is momenteel
| # | MiB | Kib | B | |
| JS | 12 | 0.24 | 247.88 | 253 825 |
| PHP/HTML | 341 | 2.34 | 2 394.19 | 2 451 646 |
| CSS | 25 | 0.08 | 81.68 | 83 641 |
Als simpele zien en niet professionele vind ik dit al tamelijk groot. Het is natuurlijk ook geen office365-online.
Voor wie antwoord. Hou het eerlijk en gebruik de juiste waarden 1KiB = 1024 Bytes.
CSS is niet zo belangrijk maar staat er bij voor de volledigheid.
Jan
En meet je ook alle packages uit je /vendor? of laat je die erbuiten?
Gewijzigd op 15/08/2023 14:18:34 door - Ariën -
Mijn bedoeling is enkel een kleine vergelijking met andere projecten van zowel amateurs als (semi) professionelen.
- 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.
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.
Gewijzigd op 16/08/2023 08:14:23 door Ward van der Put
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.
Ad Fundum op 16/08/2023 08:27:55:
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.
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.
Jan
— Parkinson’s Law of Data
Ward van der Put op 16/08/2023 09:14:01:
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.
Het zere punt is natuurlijk dat je met de verandering van booleaanse logica in PHP 8 (ik begon er natuurlijk niet voor niets over) eigenlijk je hele code moet doorspitten en controleren of alle operatoren nog doen wat je verwacht. En alle code is dan ook inclusief de unit tests zelf, want dat is ook gemaakt in PHP. Dat is een ergernis, waardoor unit tests minder effectief kunnen zijn dan dat je zou verwachten.
Over het algemeen is het natuurlijk wel zo dat unit tests, zeker als onderdeel van TDD een effectieve manier is om software te ontwikkelen. De overhead betaalt zich uit (zij het minder met PHP maar toch). Een aantal bugs ben je in de initiële ontwikkelfase al voor, daarom vind ik TDD ook een goed idee.
De andere kant is dat de ontwikkelaar wel de ruimte moet hebben voor die overhead. En ik vind het lastig te bepalen waar het kantelpunt precies is. Omdat je algemeen gesproken met unit tests niet de afwezigheid van bugs kunt bewijzen, komt er nooit een einde aan de lijst van unit tests. Maar unit tests moet je net als code ook onderhouden, en er zijn ook nog andere tests.
Persoonlijk denk ik dat het genoeg is om een aantal unit tests te hebben die blokken code zou moeten testen op hun correcte werking, en een aantal om te laten zien tot waar de code werkt, wanneer het fout zou moeten gaan.
Qua grootte denk ik dat de hoeveelheid code voor unit tests niet groter zou moeten zijn (los van documentatie) dan de code die getest wordt.
Wat denk jij Ward, is in jouw geval die verhouding ook 1:1 ?
Documentatie is in mijn geval een veelvoud van de code. Naast dat elke functie gedocumenteerd is in de code, heb je allerlei aanvullende documentatie, standaarden, handleidingen, ontwikkelhandleidingen, beleid, procedures en ga zo maar door.
Ad Fundum op 19/08/2023 16:29:52:
Qua grootte denk ik dat de hoeveelheid code voor unit tests niet groter zou moeten zijn (los van documentatie) dan de code die getest wordt.
Wat denk jij Ward, is in jouw geval die verhouding ook 1:1?
Wat denk jij Ward, is in jouw geval die verhouding ook 1:1?
Ik denk dat je moet streven naar minstens 1:1.
Als we ervan uitgaan dat één regel code precies één ding doet, dan heb je minstens één assertion nodig om de juistheid van je programma te bewijzen.
Dat is wat code coverage ook controleert: wordt elke regel code wel 'gedekt' door je test suite? Dat zegt echter alleen iets over de omvang van je tests, niet over de kwaliteit.
Er zijn veel situaties denkbaar waarbij je méér tests dan code hebt, vooral als je state erbij betrekt. Eenvoudig voorbeeld: om de juistheid van één simpele tinyint te bewijzen, heb je drie assertions nodig, namelijk assertIsInt(), assertGreaterThan() en assertLessThan().
Als je unit tests gebruikt om te debuggen, krijg je bovendien een heleboel tests die overbodig lijken omdat ze het onmogelijke bewijzen: ze tonen aan dat een bug niet meer optreedt. Toch laat je vooral die ogenschijnlijk overbodige tests staan, juist om te voorkomen dat de bug ooit terugkeert.
Gewijzigd op 20/08/2023 10:24:03 door Ward van der Put
En hoe test je (complexe) queries? Ook op dezelfde manier, met meerdere scenario's?
Ik heb ook nog een groep functies die redelijk op elkaar lijken. Ik zou ze kunnen normaliseren, maar dan moet de code dynamisch worden en uit de database opgehaald. Uitzonderingen toevoegen wordt dan ook veel lastiger.
Hoe test je die code, die je ook prima op het oog kunt doorzien? Zou je daar ook allemaal unit tests voor gaan schrijven?
Ik denk dat het in mijn geval nog gaat schuiven, omdat de software requirements (van het ontwerp) de hele tijd veranderen. Dat is niet iets dat ikzelf bepaal, dat komt van de business.
Quote:
Er zijn veel situaties denkbaar waarbij je méér tests dan code hebt, vooral als je state erbij betrekt. Eenvoudig voorbeeld: om de juistheid van één simpele tinyint te bewijzen, heb je drie assertions nodig, namelijk assertIsInt(), assertGreaterThan() en assertLessThan().
Kleine aanvulling nog: je voorbeeld over unit tests is niet heel illustratief. Als je in PHP voor elke INT een unit test moet gaan doen vanwege het weak type system, zit je gewoon in de verkeerde taal. Een andere taal geeft meteen een error in de IDE nog voordat je de code uitvoert, zelfs als de integer overflowt. En als het voor de database is, dan is een isInt test ook maar 1x handig, tenminste als je het object-georiënteerd doet.
Code (php)
De code is fout, maar je kunt tijdens het programmeren niet blindvaren op parser, linter, strict typing of IDE. De fout zal gegarandeerd opduiken zodra je de code uitvoert en die zekerheid biedt een unit test.
Unit testing is zeker geen zaligmakende totaaloplossing. Met static analysis kun je deze specifieke fout ook vinden. Bijvoorbeeld PHPStan herkent de bug direct: probeer zelf maar... ;-)