Utvecklingsmetodik från utvecklarens vinkel!!!

Utvecklingsmetodik enligt en utvecklare är att använda följande väg för Ruby on Rails applikationsutveckling.

1. Skriv ner en lista med mål, roller och funktioner

• Mål – vad är målen med hela projektet – affärer och annat. Detta hjälper dig att bestämma vilka funktioner som är viktiga
• Roller – vem ska använda sidan – besökare, inloggade medlemmar, administratörer? Har olika personer olika syn på samma information på sajten?
• Funktioner – vilka är de grundläggande kategorierna för interaktion på webbplatsen? Till exempel: Användare: registrering, använda forumen och blogga; Administratörer: modererar användarinnehållet

2. Skriv en lista med berättelser

• En berättelse är annorlunda än en funktion eftersom den representerar en enda tråd av interaktion från en viss användares perspektiv.
• Det är vanligt att uttrycka berättelser i formen "Som ____ vill jag ____ så att jag kan _____." Detta tvingar dig att svara på tre viktiga frågor – Vem är detta till för? Vad vill de göra? Varför vill de göra det?
• Om du inte kan fylla i en berättelse i det här formuläret, är det troligt att du inte har något svar på någon av dessa tre frågor ännu, så du måste fundera lite för att få svaren innan berättelsen kan genomföras.
• Ex: "Som administratör vill jag blockera användare från forumet, så att jag kan förbättra kvaliteten på användarinskickat innehåll på webbplatsen.
• Skriv ner dessa berättelser på anteckningskort. Detta kommer att hjälpa dig med uppskattning och prioritering.

3. Uppskatta berättelserna

• Uppskattning är ett stort ämne i sig, men grundidén är att associera en viss nivå av ansträngning med varje berättelse.
• De vanligaste skalorna är 0/1/2/3/4, 0/1/2/4/8. Jag tror inte att det här är särskilt viktigt, men välj något och håll fast vid det.
• Häng inte för mycket på exaktheten i uppskattningarna. Många saker påverkar hur lång tid det tar för dig att avsluta en berättelse, så små skillnader i berättelsens komplexitet tenderar att gå vilse i bruset.
• Ditt mål här är att skilja saker som är låga i ansträngning, som berättelser som kommer att resultera i att du skapar en enkel modell med en REST-kontroller, från berättelser som är mycket ansträngda, som att koppla din applikation med ett utmanande tredjeparts-API, eller en historia som kommer att kräva att du använder en teknik som du inte är så bekant med.
• Skriv uppskattningen på varje kort.

4. Prioritera berättelserna

• Ordna om korten i den ordning som du vill ta itu med berättelserna.
• Endast produktägaren kan verkligen fatta detta beslut. Det finns många saker som handlar om prioritering – deadlines, användartester, affärsvärde, etc. Uppskattning kan ha mycket att göra med prioritering, eftersom det belyser alternativkostnad. Kanske produktägaren verkligen vill ha den detaljerade Admin Dashboard, men om alla berättelser för att få det att fungera totalt 40 poäng, är det värt det att spendera en månad på just den här funktionen. Kanske produktägaren fortfarande vill ha historien
• Finns det några berättelser som inte passar in i den absolut lägsta livskraftiga produkten att lansera? Om så är fallet bör du flytta ner dem. Försök att slutföra en fungerande app så snabbt som möjligt så att du kan lägga den inför användarna.
• Vid det här laget flyttar jag vanligtvis mina kort till Pivotal Tracker, men jag känner många människor som föredrar penna och papper.

5. Testkör den första berättelsen tills den är klar

• Börja med gurka Skriv en gurka-funktion som täcker användarens interaktion med sajten från början till slut. Definiera de odefinierade stegen när du kommer till dem, och när du träffar ditt första misslyckande vet du att det finns ett beteende som du önskar som din app inte har (Detta kommer att ske väldigt snabbt i början, eftersom din tomma app inte har har mycket beteende).
• Om jag har Javascript-interaktioner som är en viktig del av användarinteraktionen, försöker jag låta Cucumber testa dessa med @javascript-taggen.
• Fortsätt till Rspec Skriv testet för det beteende du önskar att du hade.
• Skriv din kod Skriv koden för att få specifikationen att passera. Detta kommer att ta dig genom hela din applikation från routing till UI, till modeller, till databasschemat, till kontrollern. Du kommer att hantera dessa kodbitar i den ordning dina tester hänvisar dig till.
• Upprepa tills gurkan passerar och du är klar med historien.
• Nu är det ett bra tillfälle att fixa CSS-stylingen förutsatt att du har designen klar. Om jag arbetar ensam eller utan en designer, gillar jag att försöka wireframe UI antingen på papper eller i något som Balsamiq Mockups innan jag ens börjar koda historien.

6. Acceptera berättelsen

• Är berättelsen acceptabel? Gör den som du ville att den skulle göra? Om inte, måste du gå tillbaka och få det att fungera som det var tänkt. Att skriva gurktester i förväg hjälper till att förhindra att detta händer.
• Klarar alla dina prov? Du bröt inte konstruktionen, eller hur? Om så är fallet måste du fixa det du har gått sönder.
• Om du arbetar ensam kan det vara bra att låta någon annan ta emot dig, eftersom det kan vara svårt att se ditt eget arbete med objektiva ögon.

6. Upprepa tills det är klart

Det är så jag gör saker. Det är inte på något sätt det enda sättet att göra saker på, men det är ett väldigt vanligt sätt att göra saker på i Rails. Jag tror att det finns en bra debatt att föra kring värdet av smidig uppskattning, eller av speciell teknik som Cucumber vs. Steak eller RSpec vs Test::Unit, men de flesta Rails-utvecklare håller med om att det rätta arbetsflödet är att: 1) Identifiera en singelberättelse 2) Skriv tester för den 3) Slutför den. 7. Implementering

Vi rekommenderar att du distribuerar applikationen i molnet på grund av skalbarhet, drifttid, kostnadseffektivitet och många andra faktorer. Vi är experter på implementering på moln, oavsett om det är Heroku, Rackspace eller AWS.

Verktyg:- Capistrano, Apache, Passenger, Heroku, GIT/SVN (för det mesta GIT används)

8. Support efter implementering

När applikationen är aktiv finns det alltid ett behov av att stödja applikationen så att slutanvändaren får en härlig upplevelse. Vi tar upp AMC för de applikationer vi utvecklar och anlitar resurser för att ta hand om nya funktionsförbättringar, buggfixar samt 24×7 serverunderhåll. Kort sagt, vi garanterar därmed att applikationen vi utvecklar också sköts och underhålls väl!

Verktyg: - BugZilla, Redmine, Pivotal Tracker, Helpdesks