Google CodeSearch
skrevet af Niels Brinch
Når man mangler en metode der kan noget meget specifikt, hvor man tænker "hvorfor er den ikke indbygget i .NET-frameworket?" eller "det må der da være tusindvis af andre der har kodet for længe siden", så kan man overveje at søge efter det.
De fleste .NET-programmører har nok haft held med at finde lige præcis det de ledte efter på CodeProject eller et andet sted. Men det som er på CodeProject er normalt lidt større moduler eller små prototyper på applikationer. Hvis man bare skal bruge en enkelt metode som kan noget bestemt, er det ikke så smart bare at søge på Google.
Jeg skulle f.eks. bruge en metode til at fjerne al html fra en html-side, så kun teksten er tilbage. Det er en af den slags metoder som må være lavet enormt mange gange før. Til denne type søgning er Google CodeSearch velegnet!
Man angiver det programmeringssprog man vil søge i og så et nøgleord. I mit tilfælde søgte jeg efter "strip html":
Resultatet er omtrent 2000 kodestumper som gør nøjagtig det jeg har brug for. Så er det bare et spørgsmål om at udvælge den jeg synes ser bedst ud og kopiere den ind i min kode. Det tog 2 minutter og det virker bare - dem der skrev det oprindeligt har formentlig afprøvet det virker, så det sparer jeg.
Jeg endte faktisk med at anvende sådan en lille sød metode til formålet:
| 4 kommentarer |
4 Kommentarer:
Jeg ser 2 store problemer ved denne fremgangsmåde.
1: Du antager at koden er gennemtestet.
Du skriver: "dem der skrev det oprindeligt har formentlig afprøvet det virker, så det sparer jeg."
Jeg fatter ikke hvordan du kan skrive dette. Som professionel udvikler kan man aldrig antage dette.
Du skal som minimum skrive en Unit Test til metoden og single step igennem koden for at sikre dig at koden virker.
Hvad sker der f.eks hvis du kalder metoden med et null object?
2: Ved at kopiere kode direkte fra nettet er det ikke sikkert at du forstår 100 % hvordan koden fungere.
Igen vil en grunding Unit Test hjælpe dig på vej.
Der er alt for mange udviklere som blot kopiere kode fra nettet, laver en lynhurtig test, arbejder videre med næste opgave og senere på dagen checker koden ind.
Senere kommer koden i produktion hvorefter der opstår et scenario hvor koden fejler.
Ofte fordi koden ikke er testet grunding nok.
Personligt vil jeg ikke kalde dette Software Udvikling, men Trial-and-Error.
Der er ok at finde inspiration, hjælp og kode stumper på nettet. Men man skal aldrig antage at det er gennemtestet og virker korrekt i alle scenarier.
/Thomas
Hej Thomas, tak for kommentaren. Selvfølgelig skal man stadig teste selvom man anvender kode fra nettet.
Når man sidder og udvikler, skriver man ofte noget som ikke fungerer de første par gange, og så efter nogle afprøvninger, kommer det til at fungere efter hensigten. Den del sparer man tit ved at hente koden fra nettet. Men man kan selvfølgelig ikke spare sine almindelige testprocedurer væk.
Du har ret i man så ikke vil forstå koden 100%, men det er heller ikke nødvendigt. Jeg forstår heller ikke al koden i .NET-frameworket og heller ikke al den kode mine kollegaer udvikler.
Hvis jeg skal opsummere pointen, som jeg tror er den del vi er enige i, så er det, at man skal være klar over det ikke er sikkert, at kode hentet fra nettet fungerer efter hensigten.
Hej Niels,
Du skriver "Du har ret i man så ikke vil forstå koden 100%, men det er heller ikke nødvendigt".
Jeg er ikke enig i denne kommentar.
Vi snakker her om kode som du eller dine kollegaer har skrevet eller hentet fra nettet.
Jeg mener helt klart at den person som har skrevet koden (eller hentet den fra nettet) skal vide 100% hvordan koden fungere.
Hvordan vil du ioevrig skrive en Unit Test til en metode som du ikke forstaar?
----------
Du kan ikke sammeligne .NET Framework kode med Jeres kode. Microsoft har en ufattelig maengde af Test Engineers og .NET koden er uden tvivl bedre testet end et gennemsnitligt projekt.
/Thomas
Selvom jeg ikke forstår indholdet af en metode, forstår jeg hvad den skal modtage og hvad den skal returnere og kan derfor også teste den på forskellige måder.
Send en kommentar
<< Tilbage