Felsökning och kvalitetssäkring av kod

Hej alla

Håller för närvarande på med att skriva en rapport om hur jag felsökt och kvalitetssäkrat min kod.
Det jag fått med i min rapport, som är på knappt en sida, är att jag kört koden i debugging-läge, läst av de felmeddelanden som uppstått och åtgärdat dom och bett någon annan kontrollera min kod och uppriktigt sagt känns inte det som en rapport att hänga i granen.
Så är det någon som kan nämna fler bra metoder att "felsöka och kvalitetssäkra" en kod.

Om det är av någon betydelse så använder jag mig av VS och kodar i C#

Bygg enhetstester och integrationstester.

För enhetstestning finns det idag bra verktyg för att göra mockups, där du kan injecta in mockups i befintliga API:er. Även metoder som db.getConnection() elller systemanrop går lätt att mocka, så det finns egentligen ingen ursäkt att inte skriva enhetstester för allt.

Tack för hjälpen!

Parprogrammering, mobprogrammering, code reviews, TDD, enhets- och integrationstester m.m. För enhetstester i .Net finns NUnit, Rhino Mocks, Shouldly m. fl. nugetpaket att hämta för att underlätta det.

Det är också rekommenderat att följa adekvata kodkonventioner, vilket exempelvis ReSharper hjälper till med.

Jag vet ej om dessa självklara tips är något för dig, jag vet ej om hur van du är vid att rätta kod osv, och din kodvana överhuvudtaget, men:

1, Kolla alltid parametrarna i dina funktioner att de har valida indata, det undviker bekymmer längre fram, ett enkelt exempel är tex en konstruktor som anropas med felaktiga parametrar, det bör man kolla, om så sker så kan man istället skapa ett default tomt objekt, eller ett objekt som är flaggat som ogiltigt.
2, Använd exceptions när du tycker det är tillämpligt
3, Dumpa sådana på fil eller på annat sätt så att du kan felsöka bakåt
4, Tänk på att debugging är ett värdefullt verktyg men det finns vanligtvis aldrig tid till att testa för alla uppsättningar indata som är möjligt, därför får man försöka vara lite kreativ när det gäller att välja indata för testningen.
5, Om du skrivit en funktion som är jättebuggig och du inte klarar av att rätta till koden, så ersätt den tillfälligt med en funktionsstub, som gör just ingenting annat än returnerar ett acceptabelt värde. Då kan du testa all den övriga koden, och spara lite tid. Din krånglande buggiga funktion skriver du ut på papper och försöker tänka ut rättningar med pennan istället för på skärmen, Ibland är det lättare att tänka om man tar med utskriften till nåt kafe' eller nåt o sitta och fundera på det. Tex en funktion som omfattar en > 10 sidor papper blir rätt så kämpig att bara sitta och kolla och rätta på skärmen.
6, Om flera indexvariabler behövs såsom i, j, k, l, m, n, så tycker jag oftast att j och n ska inte användas för det är väldigt lätt att skriva fel, Skärmarna är inte så där jättetydliga heller. Alternativt är det en del programmerare som använder minst två tecken för sådana variabler pga att råkar man skriva fel så reagerar kompilatorn oftast på detta. Jag menar att det är inte så stor risk att man skriver två tecken fel, ett felslag kan väl hända att man gör, men två är mer sällsynt.

Äh, jag vet att det finns massor av tips kring sådant här, och mycket att botanisera i olika tekniker att felsöka kod. Det är viktigt att få igång tankeprocessen kring hur man felsöker bäst, (och snabbast). Lycka till

En del av det du skriver löser man med enhetstester kan jag tycka. Exempelvis variabelnamnen.

En sen kommentar men likväl.

Jo det finns en jävligt bra ursäkt för att skita i att göra för genomgående både tester och rapporter i IR innan release. Och det är pengar.

Orsakerna är enkla.

1 Det kostar en för jävla massa pengar att göra dem och åtgärda dem innan release.

2 Du har evt investerare eller företagsledning som är jävligt intresserade av att få ut
produkten på marknaden och skiter fullständigt i evt småbuggar och ibland kritiska sådana med.

3 Produkten ges oftast med ett friskrivningsavtal gentemot programvaruföretaget.
Se tex Försäkringskassans misslyckade försök till att skaffa sig ett vettigt system.
Kostade dem hur mycket pengar som helst men fick inget nytt fungerande system.
Men företaget tjänade många 100 miljoner vill jag minnas.

4 Man riskerar att bli ifrånsprungen av andra tillverkare som släpper sin produkt tidigare.

Titta bara på den största programtillverkaren av alla MS.
Hur ofta sker inte deras uppdateringar?

Speltillverkare även så, finns ju spel som släppts som knappt varit spelbara.
Köpta spelrecensenter som dock höjt spelen till skyarna.

Mods i egna forumen som raderat klagomål den första månaden efter release för att inte försäljningen skall droppa.

Sedan följer en 3 - ... månader lång process där de värsta buggarna rättas till om det inte
är Microsoft för då kan det handla om en flera år lång process.

Och vid nästa release börjar historien om igen.
Recensenter köps och höjer produkten till skyarna som det bästa de sett.
Köparna rusar till.
Buggarna börjar strömma in...
Och så vidare.

Och det är en process som affärsmodell som funkar alldeles utmärkt uppenbarligen för MS och väldigt många andra programföretag tjänar ju "hyfsat med stålar" fast de levererar allt som oftast fullkomligt undermåliga produkter med massor med buggar.

Så nej det finns massor med orsaker till varför man skiter i att göra allt för omfattande tester och åtgärder för att rätta till dem och man ursäktar sig inte heller mer än en läpparnas sådan. Sedan garvar VD och ledningsgruppen röven av sig och håvar in detta årets bonus.

Det finns dock områden där det är regel att göra omfattande tester som i flygplan, sjukvårdsutrustning, industriell programvara mm men bland det stora flertalet program för kommersiellt bruk sker det mycket sparsamt skulle jag vilja hävda om man ser på den omfattande uppdateringshistorik många program uppvisar.

Förresten jag glömde ju en debugsituation som är synnerligen kämpig, och det är sådan kod som ska rulla i realtid, med tidskritiska funktionsanrop och svar, Då kan man istället behöva dumpa de misstänkta variabelinnehållen på fil istället (Trace Debug) och läsa bakåt i loggen. Alltså jag menar sådan kod där man inte kan tillåta att debuggern stannar upp programmet medans man tex gör en inspect eller en typ stacktrace.

Det gäller ju särskillt sådan kod som har med nätverksanrop att göra med tex listen på sockets osv,

Måste man ändå debugga sådant i realtid med öppet debug-fönster så kan man lura processen genom att lägga in delayer som innebär att man har tillräcklig tid på sig ändå, dvs man kan sägas köra programmet långsammare, Om du kör inne i en virtuell maskin så kan man också på det viset växla ner CPU-hastigheten.

Det finns exempel på kod som avsetts att delaya all nätverkskommunikation, det är lite finlir med detta, Jag minns knappt om hur jag gjorde för att åstadkomma detta, förmodligen så gjorde jag om alla sockets operationer till att inbegripa en delay som sattes vid runtime. På så vis så kunde man ändå köra debuggern i ett fönster och se vad som hände, steg för steg, men det ä ju nästan detsamma som att skruva ner nätverkshastigheten ifrån tex 100 MBit till 0,0001 MBit dvs 0,1 KBit/sek en hastighet som är mer anpassad för vad vi klarar av.

Och då går det tex bra att filma debugfönstret med en vanlig kamera så man kan se vad som händer och kan enkelt backa tillbaka, mm, det finns massor av ide'er man kan använda.


Ja, det var ju mitt i prick - ja fast den här 3 månaders processen av att rätta buggar går ju på en annan budget än den förstnämnda, så det är inte samma sak enl VD och ledningen., Det är bara en annan kassa man tar ur.

Nej visst är det ett otyg, fast jag har hört märkliga historier om försök att få programmerarna att skriva bättre program, och hålla uppe deras lojalitet emot företaget. Man provade ju att höja lönen mycket på en del ställen, med följden att folk slutade jobba och började resa Jorden runt "för att finna sig själva", till Goa i Indien - vindsurfning, går i kloster, kristallterapi mm, och andra newage-grunkor.

En del jobbar ihop en massa pengar för att sen sluta, och köper sig tex en vingård i Australien mm. Och skiter i sin lojalitet gentemot företaget.

Men det är dyrt att utveckla program, har man 20 programmerare som jobbar i två år så kostar det ju kanske 20 milj i löner o skatter osv. Och sen om några blir sjuka då och då, så blir det ju struligt värre. Man kan inte hålla kvar alla anställda om man inte har massor av ide'uppslag om nya projekt som ska sätas i sjön, Mycket logistik i att hantera sådant. inte alla klarar av att hålla sådant flytande.


Det är en väsentligt annorlunda programmeraretyp som jobbar på sådana ställen, en sådan som är mycket noggrannare och att de har testandet som första prioritet: -- när tex en modul är färdigskriven så kan ett annat team ta över testningen direkt mm.

Joo jag vet, brottats med dessa problem dagligdags tills jag själv lade ner det för ett tag sedan för att just göra det jag själv finner meningsfullt. Det är mycket budgetdividerande och revirpinkande när du kommer ovanför själva programmerandet bland de som beslutar trots att pengarna kommer från samma kassa. Gäller att få folk att förstå att de jobbar för att företaget skall gå bra och det betyder inte synonymt att det gör det om deras avdelning presterar optimala budgetmål. Det är ibland en svår ledningsfråga att få de olika avdelningarna att fatta det.

Det sista visar dock på en process som är det viktigaste i att felsäkra system, skriv koden så enkelt och lättförståeligt att ett barn nästan kan förstå den. Talar inte variabel och metodnamn om vad du utför, gör om koden. Innehåller metoder/funktioner vad man nu väljer att kalla det, mer än ett moment och det finns ett "and" i metodnamnet, gör om koden till fler delmoment. Det är nog det viktigaste som finns i att skriva kod när tredje eller fjärde person som skall underhålla eller jaga buggar i skall försöka sätta sig in i vad en tidigare programmerare gjort. Och sedan dokumentera ALLT till sista bokstav i det du tillför eller tar bort.

Jo, jobbat med realtidssystem för processindustrin och ansvarat för utvecklingen av styrsystem och övervakning av sådant, finns inte utrymme för buggar där. Du kan ha processer igång av användaren som kostar flera miljoner om ett styrsystem lägger av för att inte tala om hur mycket ett produktionsbortfall kostar så det skall bara fungera när en produkt levereras så enkelt är det.

Det är därför jag anser det är så viktigt att minimalisera metoder ner till en process per metod när det är möjligt, så tiden för felsökning blir minimal och rättelsen påverkar minst möjliga antal andra system. Och sedan testa och åter testa systemen, när man ser hur jättar som MS verkar jobba funderar man på om de ens utför betatester ibland, ME, Vista, W8 för att nämna det mest uppenbara W4an var ju ingen hit den med när den levererades i början. Novell som var deras stora utmanare på nätverk på den tiden svarade med att leverera ett användargränssnitt till deras servrar skriven i java har jag för mig som var totalt obrukbart, segt var ett understatement och extremt fult till råga på allt, det räckte för att de som varit den största aktören på marknaden fick lägga ner trots att de hade i grunden en bättre fungerande produkt, Lotus 123 (sista större programmet helt skrivet i assembler vill jag minnas) åkte ju på storstryk av Excel just på grund av användargränssnittet vill jag minnas som en liten parentes trots att de med hade en imho långt bättre produkt...

Helst vill jag i sådana lägen undvika dynamiska minnes allokeringar, och allokerar allt som kan behövas på en gång - realtidssystem behöver sällan mycket minne för att snurra.

Timingen är ytterst viktigt i sådana styrsystem, tänk dig styrsystemet på JAS, i att datorerna måste reagera inom XX millisekunder, annars går det åt helvete.

Man kan stressa sådana här system med att köra dem i simuleringar mot ett fiktivt virtuellt produktionssystem eller en fiktiv modell av flygplanet
och tex sakta ner CPU-hastigheten (görs bäst i en virtuell maskin), därmed kan man se när det blir risk för att systemet ballar ur, dvs när timing kraven inte kan upprätthållas., och var dessa fel först uppstår,
Och viktigaste om hur mycket marginal det finns kvar att vinka på

En annan sak som jag löste något problem med, minns knappt vad - gjorde ett sådant lattjolajbanjobb att jag helt enkelt körde ett program avsiktligt långsammare än vanligt - och dumpade hela CPU-innehålllet på en buffer och kollade i efterhand vad som hänt

Realtidssystem har på sätt och vis en stor fördel programmeringsmässigt, vi vet redan i förväg om hur miljön ser ut där man kör programvaran. Så är inte fallet i en vanlig PC, där kan miljön variera enormt även under exekveringstiden, olika versioner av DLL-er finns, olika versioner av OS, konkurrerande processer, osv osv

Sådana realtidssystem som måste använda asynkrona enheter har ju en speciell svårighet med detta, man kan behöva handkoda sådan hantering pga att det inte finns libs som stödjer sådant. Tex antingen kan man polla den asynkrona enheten, ellr välja att bygga den på tex interrupts ellr timers. Pollning är ju slöseri med CPU-cykler, men om det inte är viktigt så what if and else or not ?


Ja fast jag sett funktioner med 100 tals variabler och parametrar där bara dessa upptar flera sidor (avancerad matematik). Det är mkt svårt att klippa upp sådana att de blir mer lättförståeliga utan att antalet nya funktionsanrop blir så många att det går avsevärt långsammare, och man får stora problem bara med att hitta på funktionsnamn på delfunktionerna osv.


Windows NT 4.51 var mycket riktigt ett bekymmersamt OS, dels fick man installera det via disketter alldeles i början, och man kunde räkna med att en del drivare kunde man glömma, NT 4.51 var ett system man bara kunde köra vissa program som ofta var de allra mest använda. Ett riktigt uppsatt NT 4.51 system kunde dock fungera bra, om användarna följde råden de fått. Dock om man hade hade störig nätverksuppkoppling så blev det snabbt stora problem.


Java hypen höll i sig med många misslyckade projekt, någon grupp av töntar hade ju tagit an sig att skriva en databashanterare i Java men det sket sig helt vill jag minnas, -- den var väl så långsam att ett vanligt papperskartotek hade varit snabbare. Novell hade ju riktigt smarta ide'er genom att kunna packa in programvaran på så lite minne som kärrorna hade då. Jag gillade Novell för de jobbade mycket för att få det att fungera med olika nätverksprotokoll. Novell gick ju riktigt bra som företag vill jag minnas, med många sålda licenser, - doch så upptod den väl runt > 50 st 3,5 tums disketter kanske .


.