Bra praxis när du utvecklar.

När jag programmerade mycket med PHP och MySQL så kunde jag lätt felsöka vad för saker som var fel, likadant jag kunde testa funktioner enkelt och smidigt. Jag förstod hur koden var uppbyggd och skulle byggas.

Förut idag skulle jag skapa en enkel AlertDialog, och jag tänkte; "Nu måste jag testa så själva, alertdialogen fungerar, alltså visar den text och de knappar den ska".
Men jag visste inte hur jag skulle göra, det jag ville göra var att jag skulle lägga en knapp direkt i appen, och när jag då skulle trycka på den så skulle alertdialogen starta. Men det är inte så enkelt som när jag programmerade hemsidor.

Men iallafall så satte jag en .show() på den så den startade direkt när jag startade appen, och det fungerade ju...

Ni som KAN detta, och likadant ni som har gått en utbildning och lärt er, hur tänker ni när ni programmerar? Vad börjar ni med? Om det blir fel, hur hittar ni er lösning?

Jag har inte tänkt att ni ska skriva massa kodsnippets och lösningar, bara mest pedagogiskt berätta hur ni tänker när ni kodar.

Jag själv känner att jag bör nog ta en tripp till mach och Zooklubba och få prata kodning för att förstå mer om, Adapters och Intents och ja... Allt... Jag förstår kanske 1% nu av vad de gör, och det kommer jag inte långt på :/.

 

Jag brukar använda mig av följande arbetssätt:

1) Definiera/specificera vilka funktioner programmet ska ha. (Ex enkel miniräknare som ska kunna addera, subtrahera, multiplicera och dividera två tal)

2) Skissa upp hur funktionerna skulle kunna fungera, exempelvis på ett papper att ha som stöd så du inte glömmer bort dina tankegångar.

Användaren skriver in siffor, sen en operator, sen ytterligare siffror.
Vad behöver programmet göra för att kunna utföra uträkningen med de siffror användaren skriver in?

1) Hålla reda på de första siffrorna
2) Hålla reda på operatorn
3) Hålla reda på de sista siffrorna
4) Utföra beräkningen
5) Presentera resultatet

Dessa fem punkter går sedan att formulera till frågor, ex Hur ska jag hålla reda på de första siffrorna?
Ska de sparas som en int, en double, eller kanske en sträng med både de första sifforna, operatorn och de sista siffrorna?

Svaren på dessa frågor ger en grund för hur programmeringen kommer att genomföras.


3) Sen tänka igenom eventuella begränsningar, tex användarens input i programmet, bokstäver är kanske inte särskilt lämpade i en enkel miniräknare, hur ska det angripas?

1) Ge felmeddelande och helt ta bort inmatningen?
2) Ta bort felaktiga tecken och använda de eventuella siffror som fanns och genomföra beräkningen?
3) Ha knappar som enbart är siffror?

Är decimaltal tillåtna, hur stora tal ska tillåtas?


4) Skriv programmet, med planeringen som stöd.

5) Testa, testa, testa. Om det inte fungerar är det mycket bra att stega igenom koden när den körs och kontrollera att alla varibaler får de värden som de borde ha.
Titta på koden så att inga logiska fel gjorts, att variabler inte tilldelas som de borde genom att något tecken glömts osv. När ett eventuellt fel har hittats gäller
det att försöka lösa detta, antingen själv eller genom sökningar i litteratur eller på nätet.

6) Känn hur kul det är med ett självskrivet program som funkar som det ska

Detta är självklart inget måste, men jag tycker själv det är skönt att ha funderat igenom så mycket som möjligt från början. Det kan leda till mycket extrajobb och ändringar
att inte ha någon klar uppfattning om vad programmet ska göra innan kodningen startar, speciellt vid mer komplexa/större uppgifter.

Det viktigaste måste ändå vara att man själv har kul, kanske inte alltid på jobbet dock
Övning ger verkligen färdighet, och jag tycker att det bästa sättet att lära sig på är att prova sig fram.

Med reservation för grova felskrivningar då jag är mycket trött!

 

Testa, testa och testa. Sedan så kommer du börja att förstå. Jag själv har inte gått någon utbildning alls, utan är självlärd. Du kommer garanterat klara det, man måste bara sitta ner och pilla på det en stund.

När du ser olika API:er i din kod, ta fram Android:s API och kolla vad de gör. Likadant om du ser något nyckelord som du inte känner igen - googla det och bygg vidare.

En annan viktig sak är att även när du har färdig kod så kan du testa göra om den, modifiera vidare och ändra så att du själv begriper vad du gör.

Jag själv kommer ihåg mitt första "riktiga" program som jag gjorde på min praktikplats. Den koden är fruktansvärd att kolla på och inte alls strukturerad och optimal alls, men det var ändå en lärdom. Våga göra fel så kommer du senare att automatiskt göra rätt i 95% av fallen.

Jag började förra sommaren och sedan dess har allting fallit på plats. Om jag nu inte vet hur jag ska lösa något så testar jag först själv, sedan googlar jag om det inte löser sig.

 

Som nybörjare skall man inte vara rädd att kopiera. Google och Stack Overflow är ens vän!

Klipp och klistra, googla på krasherna och så småningom så kommer du se kod på nätet där du tänker -"Nä, jag hade nog gjort på ett annat sätt." När du kommit så långt är det dags att börja titta på design-patterns och bli av med din gyllene hammare.

Lycka till!

 

Jag är väl mest amatör i gänget här, men jag har ändå med självlärdom slängt ihop en rss-läsare (med en hel del "lånad" kod förvisso.) och en helt egenbyggd app som hämtar info från en hemsida med lite grafik och knappar osv.

Och mitt tips är, kommentera din kod, hellre för mycket än för lite.

Tack till alla som hittills skrivit! Jag sitter i samma båt som Dreamhawk, jag har hopplöst dålig struktur på min kod, och inget vidare effektivt arbetsflöde, så det var nyttigt att lösa för mig med.

 

Jag är personligen väldigt pragmatiskt lagd. Delvis självlärd, delvis utbildad (universitet). Alla har vi olika åsikter och tillvägagångssätt, men här kommer iaf mina tankar i ämnet.

Var väl förberedd innan du börjar
Låter tråkigt men innan man ger sig in i ett nytt ramverk, typ android, se till att vara väl förberedd. Även den mest erfarna programmören behöver känna till förutsättningarna. Läs på om androids arkitektur och ramverk. Android Developers är en utmärkt resurs för detta. Men det finns även många bra, lättlästa böcker i ämnet. Är man förberedd så är det dessutom betydligt roligare att utveckla. Varenda liten detalj blir inte en stor utmaning.

Utveckling
När man väl har en produkt man vill ta fram så rekommenderar jag att man skriver ner några user stories. En user story beskriver, med vardagliga ord, vad man ska kunna göra med produkten, oftast ur en slutanvändares perspektiv. De behöver inte vara speciellt komplicerade. Ska man t.ex. göra en RSS-läsare kan några user stories vara:

• Som en användare vill jag kunna prenumenera på ett nytt RSS-flöde genom att klistra in en URL
• Som en användare vill jag kunna växla mellan olika RSS-flöden
• Som en användare vill jag kunna avsluta prenumerationen av ett RSS-flöde
• Som en användare vill jag kunna komma till orginaltexten från ett element
• Som en användare vill jag kunna rekommendera ett RSS-flöde till mina vänner

Varje user story kan man sedan (om man så önskar) bryta ner till tydligare arbetsuppgifter för dig som pragrammör. Personligen gillar jag att bryta ner uppgifter ganska mycket. Dels för att det är lättare att ta sig an en deluppgift om den är tydligt definierad och dels för att det känns bättre mentalt att ofta kunna bocka av mindre saker (snarare än större saker sällan). En user story beskriver sällan hur saker och ting ska ske rent tekniskt. Därför finns det också en annan fördel med att bryta ner dessa. Du börjar fundera på hur du ska implementera en viss detalj innan du faktiskt sätter dig ner och kodar. Exakt på vilket format du skriver ner detta på är givetvis upp till dig. Men jag kan tipsa om att skriva ner det rent fysiskt, t.ex. som post-it lappar och sätta upp på väggen. Det känns mer konkret att ta fram papper och penna. Men återigen, gör på det sätt som känns bäst för dig.

Ta hjälp
Ett problem för nybörjare är ofta att över huvud taget kunna formulera sitt problem så att andra förstår. Detta hänger ofta ihop med för lite kunskap om ramverket. Så återigen, se till att du har koll på förutsättningarna. Inte nödvändigtvis i detalj givetvis. Men tillräckligt mycket för att kunna ställa tydliga frågor. Börja alltid med att försöka hitta svaret på din fråga innan du ställer den. Stack Overflow är förstås en utmärkt resurs där många svar på frågor redan finns att hitta. Allt som oftast med bra kodexempel också. Om du ändå inte hittar svaret, var då inte rädd att fråga, men försök formulera frågan tydligt och exakt. Då får du snabbast och bäst svar. Kolla även in androids guider som har svar på många frågor.

Ifrågasätt
Om man verkligen vill lära sig att göra saker på rätt sätt och inte bara "tillräckligt bra", våga då ifrågasätt dina egna lösningar. När du kommit på hur du vill lösa ett specifikt delproblem. Fundera på dess konsekvenser och om det kanske finns bättre sätt att lösa problemet på. "Är det nödvändigt med en bakgrundstjänst för att lösa mitt problem?", "Finns det verkligen inget bättre sätt att spara inställningar än till en textfil på SD-kortet?", etc.

 

Jag är imponerad. Detta var den typ av information jag ville höra och som jag tror många andra vill behöva höra med. Jag

Sent from my Nexus S using Tapatalk

 

Bäste rådet jag kan ge är att studera andra personers kod. Finns där ett program till din telefon som du gillar, men som inte är 100 %? Är det öppen källkod? Hämta koden, läs den, förstå uppbyggnaden och strukturen, och förbättra det du kan.

 

Agil utveckling, TDD och refaktorering är mina ledord.

Börja med enkla basala saker. Ett GUI så man har en startpunkt och något som kan dra igång det man vill göra. Enhetstester funkar också bra för att driva kod.
Prototypa fram olika delar för att se att det man vill göra funkar och att alla delsteg går att lösa. Driv och testa dem med GUI:t och enhetstester.
Det är viktigt att de kritiska delarna av projektet övervinns tidigt så att man inte sparar dem till slutet och först då upptäcker att det inte går att genomföra.
Se till att appen tidigt går att köra även om det inte är mer än en titel och en knapp. Lägg till de nya delarna efter hand så att appen växer och funktionaliteten ökar.

Refaktorera hela tiden för att göra koden bättre. Bryt kod till mindre metoder. Bryt ut till nya klasser. Använd den smidiga refactor-menyn i Eclipse. Den gör nästan hela jobbet.

Skapa så många enhetstester som möjligt. Då kan man lätt refaktorera koden utan att riskera att saker som fungerade tidigare går sönder utan att man märker det.

Debuggern är otroligt viktig. Se till att lära dig debugga med den, så blir det lätt att se vad som är fel.
Metod för att hitta fel:
Sätt en breakpoint där du ser att felet uppstår. Antingen via tracen eller att felet uppstår när en knapp trycks in eller något annat händer. Stega sedan framåt tills det blir fel. Kolla om felet orsakas av inparameter eller om det är något som anropas senare. Om det var en inparameter som t.ex. var null så blir det till att söka bakåt i koden och se var parametern sätts. Om felet uppstår senare så flytta breakpointen till den rad som blev fel och kör igen. Stega in på den raden och stega framåt tills det blir fel igen. Flytta breakpointen dit och kör igen. Till slut så ser man exakt vilken rad som orsakar felet.

 

Mycket svår fråga och du har fått en hel del bra svar redan.

Jag vill ge dig lite perspektiv och samtidigt beskriva en applikations livscykel. När jag pluggade så ställde en elev samma fråga till en programmeringslärare. Han kunde inte svara utan menade att det kommer till slut med lite erfarenhet (detta var en vecka innan tentan). Det är först när jag kom bort från skolan och började jobba som Java-utvecklare och numera Lösningsarkitekt som jag har fått se det hela i ett större sammanhang.

När du frågar andra gör så har du fått väldigt olika svar. Det beror på vi alla inte har samma referensramar och vi fokuserar på olika delar som är svåra för oss.

Modellen för en applikations livscykel är hyfsat teoretisk, den blir mer tydlig för komplexa system i stora företag. Men även när du bygger en applikation hemma på kammarn så går du igenom samma stadier, du är bara inte medveten om det.

Snodd bild:


Idea Conception
Först får du en briljant ide, men du vet i detta läget inte om det är en idé som håller hela vägen igenom.

Business Case
För att testa idén på papper så skapar du ett business case.

Ett business case behöver inte vara speciellt komplicerat. Det är helt enkelt en förklaring till hur din idé gagnar/ger värde till din slutanvändare samtidigt samtidigt som du får något av värde tillbaka från dina slutanvändare. Helst mer än vad du investerat till slut.

Vad du vill ha kan variera, exempelvis: pengar, social status, egotripp/beröm, engagemang, nya kunskaper etc.

Requirements
När du har listat ut vad du ska göra hur det gagnar slutanvändaren och dig själv så kan du börja lista kraven. Det är här som User Stories och Scenarion passar in.

User stories beskriver vad användaren vill få ut. Scenarion beskriver steg för steg vad som händer. En User Story delas alltid in i en eller fler scenarion.

Det underlättar om du skapar en avatar av din slutanvändare (jag gjorde en enkel avatar i detta inlägget.).

Om vi tar Bankdroids notifieringar som fiktivt exempel på en User Story:
As UserAvatarX (Kalle Svensson)
I want to automatically recieve notifications when money is withdrawn from my account
So that I can be assured no one is using my card without my knowledge.

Scenarion går ner på djupare nivå och listar steg för steg vad som händer i applikationen med formatet:
Given New transactions have been downloaded
When the sum of all transactions differ from cached sum of transactions
And the notifications setting is turned on
Then notify the user
And update the cached value for sum of transactions

Andra krav kan vara icke funktionella, exempelvis: det ska gå fort som attan för användaren är otålig eller att det ska vara säkert och pålitligt (som i exemplet BankDroid).

Ett sätt som blivit populärt på senare år är att göra mockups och användbarhetstudier (UX Studies) som en del av kravfångsten.

Du kan titta på första inlägget i min tråd för ett simpelt exempel på mockups.

Architecture/Design
Nästa steg i livscykeln är att skapa en arkitektur och design. Ofta det finns lika många uppfattningar om vad Arkitektur vs Design är som det finns människor, så detta är mer vägledande information än en definition. Min roll på jobbet är Lösningsarkitekt så jag jobbar dagligen med arkitektur.

Arkitektur utgår ifrån kraven och behöver svara på bland annat:

• Vilken mjukvaruplattform? (ex Android)
• Vilket programmeringsspråk och vilka bibliotek?
• Hur flödar data in och ut i din applikation? (gentemot externa parter)
• Hur delas lösningen in i olika subsystem? (ex ett Spel och en Spel-editor)
• Vilka kommunikationsprotokoll och datastandarder? (TCP/IP, SSL, JSON, XML, SQL etc.)
• Översikt av hårdvara (servrar/infrastruktur/middleware) och vilka specifikationer dessa ska ha?
• Klassificering av information, är info personligt/hemligt? måste info finnas tillgänglig? Gör det något om info försvinner?)
• osv...

Design av din applikation tycker jag främst handlar om vilka standardlösningar du använder i eller skapar för din applikation:

• Hur ser din datamodell ut? (Transaktionerbaserad vs Analysbaserad)
• Hur gör du för att inte ha beroenden mot andra applikationers datamodell?
• Hur validerar du inkommande data?
• Hur sparar du data?
• Hur hämtar du data?
• Hur kommunicerar du men omvärlden?
• Hur delar du upp din applikation i logiska delar?
• Hur ser du till att varje klass/paket har ett avgränsat ansvar? (high cohesion)
• Hur skapar du "öar" av kod och minskar antalet broar mellan dessa? (low coupling)
• osv...

Här finns det en uppsjö av olika teorier. Domain Driven Design är ett bra exempel. För alla olika typer av standardproblem så finns minst tre-fyra olika designmönster (DAO, Command, Facade, Proxy, Dependency Injection).

Development
Först nu har du hamnat i stadiet av programmering. Här finns olika processer för programmering. Exempelvis eXtreme Programming, Test Driver Development osv.

Test
När du kodat ihop ett Scenario eller en User Story så testar du. Här avser jag inte unit tester (som jag klassar som utveckling) utan tester med större omfång som är till för att se att alla flöden är vettiga.

Olika typer av test:

• Funktionstest
• Integrationstest (två parter som pratar med varandra)
• Systemtester (alla delar tillsammans)
• Prestandatest (Lastest, Kapacitetstest, Stresstest, Uthållighetstest)
• Penetrationstest ("ethical hack"/säkerhetstest)
• Acceptanstest (om du har en beställare)

Operations
Till slut så har du släppt din applikation till dina användare, när det dyker upp buggar eller fel så får du fixa dem. Har du betalande kunder så kan du få behöva släppa patchar för deras system och behov.

Decomission/Inspiration
I slutet av livscykeln så finns det ett vägskäl. Antingen har du fått inspiration till ny funktionalitet och du börjar på en ny cykel eller så är applikationen färdig att skrotas. I det fallet kan det vara så att det finns data som användaren vill kunna flytta till en ny applikation eller ta backup på.

Vart ville jag nu komma?
Det jag ville få fram i slutändan är att det jättestort område. När du bygger appikationer själv så kommer du att intuitivt lösa vissa faser utan att tänka på det och andra faser kommer att vara jättesvåra. Förhoppningsvis kan du nu ställa mer specifika frågor och få bättre svar:

• Jag har kanske inte problem med programmeringen och API:erna, jag har bara för otydliga krav och vet inte hur mina flöden ska se ut. Hur gör jag för att få ihop bra krav/stories?
• Jag har tröttnat på att jag fick ändra på 10 olika ställen för femte gången, hur gör jag för att få en bättre arkitektur/design från början? Finns det någon bra referensakritektur?
• Jag saknar standardlösningar på återkommande problem, vilka designmönster kan hjälpa mig med probem X?

Har du läst hit så bra jobbat! Det tog mig säker 2,5h att skriva, så tack för visat intresse.

 

Extremt bra svar, jag tror att den här informationen skulle hjälpa väldigt många.
Får man fråga var du jobbar? :-)

Sticky thread plz!

 

Jag vill mest med den här tråden, dels få råd själv, men jag vill ju att andra (n00bs) ska kunna ta del av era tankesätt också.

 

Välj bra verktyg och lär dig använda dem. Mina rekommendationer:
IDE (utvecklingsmiljö): Eclipse är de facto standard för Android, men även mitt val för all Javautveckling.
Plugins till Eclipse: CheckStyle (hittar dålig kod), Cobertura eller EclEmma (test coverage).
Versionshantering: Mercurial eller Git, privat kör jag Subversion
Ärendehantering: JIRA med GreenHopper, privat kör jag MantisBT
Integrationsserver: Jenkins
Tester: jUnit, Robotium (endast för Android), FitNesse
Övrigt: SoapUI (simulerar och testar webservices)

 

En fara med att ha många kommentarer i sin kod är att man sällan ändrar kommentarerna, och därför är det inte säkert att kommentarerna fortfarande stämmer.

Ett annat alternativ till att kommentera sin kod är att alltid försöka hålla metoder så korta som möjligt. Det bör inte vara på mer än 10-20 rader. Om du skriver så korta metoder kommer metodnamnet med argumenten vara din kommentar

En bra sak, om man googlar efter lösningar, är att i sin kod ha med länken till artikeln där man hittade svaret till en särskild lösning. Då kan man i efterhand gå tillbaka till artikeln om man undrar varför en sak ser ut som den gör.

 

Utan någon som helst egen research (sitter med tapatalk för tillfället): jag utvecklar i eclipse och saknar möjligheten att brancha koden samt issue tracking. Är git någon för mig? Eller finns det bättre webbaserade tjänster? Google code?

Sent from my Nexus S using Tapatalk

 

Git är min personliga favorit som versionshanterare. Jag använder github som repository för open source projekt. Men även google code klarar git sedan ett par dagar!

 

Open source eller closed source?

Många ställen kräver att du har open source för att kunna utnyttja deras gratistjänster.

 

Closed i dagsläget. Känner att jag inte riktigt händer med här med både git, github och Google code.... Hur hänger det ihop?

Sent from my Nexus S using Tapatalk

 

Det är bara att titta i min profil på "Om mig".

Jag är IT-konsult på Capgemini i Göteborg, ute hos kund har jag rollen Lösningsarkitekt. Men eftersom vi kör Agile Scrum så blir det ganska spridda uppgifter. En Lösningsarkitekt behövs mest i början av ett projekt. Jag brukar sitta med alla surdegar och göra förarbete (beställa och driva på saker) för att se till teamet slipper oklarheter i sprintarna.

Hinner tyvärr inte koda på jobbet, så jag får koda på fritiden istället.

 

Det finns en mängd olika versionshanteringssystem t.ex: Subversion och Git Antingen kör du dessa lokalt på din egen dator/server eller så använder du dig av någon webbtjänst som erbjuder denna funktionalitet t.ex: Google Code eller Github.

I fallet med subversion har man ett centralt källkodsförråd (repository) och på din arbetsdator har du hämtat ut olika revisioner från det centrala förrådet som du jobbar med (arbetskopia)

Git däremot är ett s.k. distribuerat versionshanteringssystem vilket betyder att det inte finns någon central punkt utan alla som jobbar med källkoden har en klon av hela förrådet på sin dator och skickar sedan ändringar man gjort mellan sig (push och pull). Av organisatoriska skäl brukar det även i fallet med git vara lämpligt att ha en central punkt som alla skickar sina ändringar till. Detta skulle kunna vara en egen server eller github.

Mer info:
Distribuerade versionshanteringssystem (GIT) vs Centrala versionshanteringssystem (SVN) | Webbfeeden

Jag skulle rekommendera att använda git lokalt på din dator med en kopia någon annanstans som backup.