共用方式為

Reflektioner efter dagens "Open Spaces"-möte om säkerhet.

  • 發行項

Idag genomförde vi en aktivitet som inspirerats av SweNugs tidigare Open Spaces-diskussion om Arkitektur. Vi valde att fokusera på säkerhet då vi kände att vi kunde bjuda in både utvecklare och IT-proffs till samma möte och på det sättet bredda diskussionerna och låta personer som tidigare aldrig träffats se vilka gemensamma utmaningar och intresserområden som fanns. Jag hade en mycket intressant dag och kände mig väldigt upprymd efter dagen, det var många intressanta diskussioner och det verkar också som om några problem har lösts, spännande och motiverande.

Jag initierade själv en diskussion angående eventuella motstånd från utvecklare till att lära sig skriva säker kod och vi hade en intressant dialog. Bland annat diskuterades om mogenheten på utvecklare på .NET plattformen var lägre än andra plattformar och det i sin tur har lett till en lägre kompetens i säkerhet och hur vi ska skydda oss mot vanliga attacker. Vi tog också upp om ökad förståelse och användning av kodgranskning skulle kunna förbättra kvaliteten på projekt och lösningar i allmänhet, och det nämndes bland annat möjligheten att allokera resurser (personer alternativt tid) till att genomföra kontinuerliga kodgranskningar. Till exempel skulle det kunna existera en roll inom utvecklingsteamet på 6 utvecklare som inte utvecklade ny kod utan istället spenderade sin tid på att granska tidigare incheckningar och andras arbete. Denna roll skulle också kunna vara rullande vilket i sin tur skulle leda till att kompetensen inom teamet ökade och inte bara stannade hos en person, det skulle också kunna leda till bibehållen motivering bland utvecklarna.

Vi pratade också om möjligheter med exempelvis Visual Studio Team System att kräva att en annan utvecklare alltid granskade kod innan den fick slutligt checkas in i källkodssystemet, lite som pseudo-extreme-programming.

Naturligtvis nämndes också TDD (Test Driven Deployment) och enhetstester som tekniker för att förbättra kvaliteten.

Jag är nyfiken på vad du tror om dessa förslag, omöjliga, intressanta eller bara fantasier?

Comments

  • Anonymous
    September 01, 2005
    Ämnet kodgranskning är ständigt aktuellt för oss. Tyvärr rinner det ofta ut i sanden, eftersom kortisktigt så finns det nästan alltid något som har högre prioritet. Att kräva en kodgranskning för incheckning låter spännande, men å andra sidan vill man nog oftast kunna checka in utan att vara beroende av att någon annan har möjlighet att granska. Men en indikering vilka filer/versioner som är granskade vore bra - att man får ut en rapport på ogranskade filer.

    Vi har som policy att utföra tredjedelsgranskningar - när vi utvecklat ungefär en tredjedel ska någon/några granska och komma med synpunkter. Lite halvformellt. Men som alltid - plötsligt är det någon tidsplan som måste tajtas och då får såna aktiviteter tyvärr ofta stryka på foten.

    Idén med att ha en rullande roll som heltidsgranskare låter intressant, men blir nog svårt att få gehör för hos de som bestämmer. =)
  • Anonymous
    September 02, 2005
    Kom gärna ner till "södern" och håll open spaces här med.
  • Anonymous
    September 05, 2005
    Håller med Morgan, kom till söder ut ;)

    På mitt förre företag provade vi på olika varianter av granskning. Något som jag tror på är delar ur eXtreme Programming och Agile som arbetsmetodik. Refactoring kan också leda till bättre och säkrare kod etc. För att granskingen ska ge resultat så krävs att de bästa granskar. Många företag sätter vem som helst på det, men granskning ska leda till att få bättre kvalité på produkten. Det ska även leda till att andra lär sig något av det. Granskning är alltså ett annat bra sätt att sprida kunskap :)
  • Anonymous
    September 09, 2005
    Mycket bra initiativ! Jag önskar att jag hade kunnat vara där.

    Jag tycker också att ni kan komma ner till söder/väster.

    Eftergranskning vore riktigt trevligt. Helst skulle man då i VS kunna välja att granska kod från en användare och får upp de aktuella filerna. De rader som är ändrade/nya sedan förra granskningen bör också markeras i någon färg. Detta gör att man har möjligheten att granska i efterhand när/om det är så mycket att göra att man måste tumma på kodgranskningen. När det inte är mycket att göra blir det dessutom enkelt för den som granskar och den kod som granskas kan lätt hittas.