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ć.