Katarzyna K.

Katarzyna K. Lider przyszłości :)

Temat: Rola architekta w projektach IT

Witajcie,

Pracuję w firmie wytwarzającej software, i współpracując z firmami zewnętrznymi natknęłam się na problem jakości kodu.
Jeżeli jako firma zamawiamy produkt w postaci jakiejś części oprogramowania to jakimi wzorcami lub sposobami / metodami powinnam się kierować odbierając dostarczony kod ? Czy istnieje jakieś "elastyczne lekarstwo" wg którego powinno się ten kod weryfikować pod kątem jakości?

Raczkuję dopiero w tym temacie, więc będę bardzo wdzięczna za wszelkie wskazówki. A dlaczego akurat grupa architekci IT? poniewaz w naszej organizacji to architekt odbiera dostarczony kod. Czy u was w firmach też tak jest ?
Kamil Grzybek

Kamil Grzybek Architekt
Oprogramowania .NET

Temat: Rola architekta w projektach IT

Za odbieranie kodu najczęściej odpowiedzialni są architekci lub projektanci systemów z tego powodu, że posiadają największe kompetencje i doświadczenie oraz z reguły odpowiadają za wdrożenie rozwiązania po stronie zamawiającego.

Pamiętajmy jedną rzecz - aby zweryfikować jakość czegokolwiek trzeba mieć ustalone kryteria jakości. Jeśli chodzi o jakość kodu istnieje wiele metod / metryk do mierzenia tejże jakości, jednak z mojego doświadczenia są to tylko narzędzia pomocnicze. Na sam koniec osoba odpowiedzialna za odbiór rozwiązania i tak musi zrobić tzw. "code review" aby upewnić się, że system napisany jest zgodnie z przyjętymi wymaganiami oraz standardami firmy.

Odpowiadając na pytanie - "elastyczne lekarstwo" wg mnie nie istnieje, jednak osoba doświadczona i znająca temat jest w stanie takiego odbioru dokonać i przedsiębiorstwo na tym nie straci (czytaj nie dostanie bubla).
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rola architekta w projektach IT

Jeżeli jako firma zamawiamy produkt w postaci jakiejś części oprogramowania to jakimi wzorcami lub sposobami / metodami powinnam się kierować odbierając dostarczony kod ?

po 20 latach "pracy w terenie" poznałem tylko jeden sposób: zaprojektuj to co zamawiasz i sprawdź co odbierasz. W przeciwnym wypadku skazujesz się na "zabawę" w rodzaju "zamawiam ładny i wygodny dom".

Jeżeli znasz wykonawcę (developera) i wiesz "co dostarcza" i ufasz mu, możesz u niego zamówić "ładny i wygodny dom" z małym ryzykiem, jeżeli nie znasz developera daj mu projekt domu do wykonania a nie proś o "ładny dom".

Na początek zastanówcie się co nazywacie jako firma zamawiająca produktem i jak sprawdzacie, czy otrzymujecie to co zamówiliście. Jedna uwaga: jeżeli zamówieniem jest wyłącznie specyfikacja wymagań funkcjonalnych i nie-funkcjonalnych (lub jej ekwiwalent w postaci specyfikacji interfejsów") to troszkę tak ja byś zamówiła samochód pisząc tylko tyle, że ma mieś pedały sprzęgła, hamulca i gazu, kierownicę i prędkościomierz i ma jeździć. Co odbierzesz od dostawcy?

Jak pisał poprzednik: zlecić i odebrać oprogramowanie (kod) może raczej dobry architekt projektant...Jarek Żeliński edytował(a) ten post dnia 13.03.13 o godzinie 07:52
Katarzyna K.

Katarzyna K. Lider przyszłości :)

Temat: Rola architekta w projektach IT

Dziękuję wam za odpowiedzi:) Ja wiem, że złoty środek nie istnieje ;)
Code review jest wykonywany, ale tak naprawdę miernikiem jest w tym wypadku subiektywna ocena architekta - czy u was też tak jest?

Mówimy o narzędziach pomocniczych.. ja bym właśnie tutaj chciała się chwilkę zastanowić apropo mierników jakości kodu. Ale nie wiem zbytnio jak to ugryźć, raczkuję dopiero w temacie.

Jarku:) Muszę się z Tobą zgodzić, że obecnie oddajemy analizę ale zarówno analityczną jak i architektoniczną + interfejsy GUI. Także dokument dostarczany nie pozwala na choćby minimalną dozę swobodnej interpretacji - wszystko jest określone, a jeśli nie - dopracowywujemy iteracyjnie (szczerze mówiąc aż dziw bierze że tak się to udaje).

Moglibyście mi podać jakieś przykłady apropo metod / metryk mierzenia jakości kodu?
Jestem w posiadaniu książki UML i wzorce projektowe, ale nie wiem czy obieram właściwy kierunek..
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rola architekta w projektach IT

ja na Waszym miejscu ukierunkował bym się na pisanie testów, dobry test to nie tylko sprawdzanie czy się nie wysypuje" ale także testowanie architektury. Np. mój ulubiony test struktur onbiektów (danych):
1. wpisz dane klienta
2. wystaw mu fakturę
3. zmień dane klienta
4. wydrukuj duplikat faktury: w polu Nabywca musi być stary adres

kontynuacja:
5. odłącz komponent Magazyn, wydrukuj duplikat faktury: to MUSI być możliwe.

i parę innych wrednych pomysłów :), dobre testy powiedzą Ci więcej niż czytanie tysięcy linii kodu (bo kto to robi????)

nie wiem jaką dokumentacje oddajecie więc nie mam zdania, bo jej objętość nie koniecznie równa się skuteczność...

(ta książka to Larman???)Jarek Żeliński edytował(a) ten post dnia 13.03.13 o godzinie 08:28
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: Rola architekta w projektach IT

Ja bym rozdzielił zagadnienia "jakości oprogramowania" od "jakości kodu". Pierwsze rozumiem jako, stopień w jakim oprogramowanie realizuje wymagania funkcjonalne/pozafunkcjonalne, zaś drugie pojęcie dotyczy tylko kodu źródłowego.

W tym drugim obszarze dostępne są narzędzia do statycznej analizy kodu, wyliczające wartości różnorodnych metryk, generujące raporty zgodności ze standardami kodowania, raporty zduplikowania kodu etc. (przykłady takich narzędzi:
PMD - http://pmd.sourceforge.net/,
Splint - http://www.splint.org/, ze splinta/pmd korzystałem i byłem zadowolony
Sonar - http://www.sonarsource.org/ - nie korzystałem).

"Subiektywne spojrzenie architekta/projektanta" można zobiektyzować przez przekazanie dostawcom wytycznych co do tego jakie standardy kod powinien spełniać (formatowanie, komentarze, stopień kohezji, ...), a później rozmawiać czy są spełnione czy nie.

Jako że kodu źródłowego jest raczej dużo, to ten proces oceny jakości powinien być mocno zautomatyzowany. Automat nie załatwi jednak wszystkiego i "code review" pozwoli uzupełnić obraz :)
Kamil Grzybek

Kamil Grzybek Architekt
Oprogramowania .NET

Temat: Rola architekta w projektach IT

Przedmówca podał narzędzia do analizy statycznej kodu, to może napiszę czym ja kieruję się podczas "code review". Zaznaczam jednak, że dotyczy to głównie języków obiektowych, gdyż z tymi obcuje na co dzień:

- ogólna architektura rozwiązania, jak powiązane są komponenty systemu (zasada loose coupling, high cohesion)
- podejście do pisania kodu - to, że coś jest napisane w języku obiektowym nie znaczy, że jest napisane obiektowo
- styl pisania - dobry dobór nazw (zmiennych, metod, klas itd), odpowiedni format, kolejność elementów
- wielkość klas, metod
- stosowanie wzorców projektowych
- stosowanie zasad SOLID, DRY, YAGNI
- kod powinien być "samodokumentujący". Komentarze w kodzie powinny być umieszczane tylko w sytuacjach wyjątkowych - odpowiadać na pytanie "dlaczego to robię?" a nie "co robię?". Wyjątkiem też jest komentowanie API w przypadku pisania bibliotek.
- brak dziwnych obejść
- czy istnieją testy jednostkowe i jaki posiadają "code coverage"
- czy istnieją testy integracyjne
- jaka technologia i biblioteki są wykorzystywane
- warto też zapytać się dostawcy, czy wykorzystuje Continuous Integration w celu automatyzacji procesu wytwórczego.

Aby to wszystko sprawdzić (i jeszcze więcej) nie trzeba czytać setek linii kodu - nie okradajmy naszych pracodawców z pieniędzy a siebie samych z czasu ;-). Wystarczy tak naprawdę przejść przez kilka zaimplementowanych przypadków użycia + obejrzeć dokumentację techniczną projektu.

PS: Świetną pozycją, która omawia część zagadnień, które przytoczyłem jest książka Martina Fowlera "Refactoring: Improving the Design of Existing Code". Zdecydowanie polecam się zapoznać.
Katarzyna K.

Katarzyna K. Lider przyszłości :)

Temat: Rola architekta w projektach IT

Jarku tak, to Larman.
Dziękuję wam bardzo za wskazówki a z książką na pewno się zapoznam.
Teraz już trochę wiem:)

Następna dyskusja:

Sankcjonujemy oficjalnie za...




Wyślij zaproszenie do