Przejdź do treści

Konsulting techniczny

Audyty kodu, optymalizacja architektury, code review.

Problem, który realnie rozwiązujemy

Firmy przychodzą do nas z konsultingiem technicznym zwykle w jednym z trzech momentów. Aplikacja zaczyna działać wolniej z każdym miesiącem, a nikt w zespole nie wie dokładnie dlaczego. Zespół chce wprowadzić nową funkcję, ale każda zmiana w kodzie powoduje błędy w zupełnie innym miejscu aplikacji. Albo firma planuje duże zlecenie developmentu i chce mieć niezależną opinię przed podpisaniem umowy z wykonawcą, żeby wiedzieć, czy wycena i podejście techniczne mają sens.

Wspólny mianownik: decyzje techniczne podjęte miesiące albo lata temu zaczynają kosztować więcej, niż kosztowałaby ich poprawka na czas, a nikt w organizacji nie ma pełnego obrazu, gdzie dokładnie jest problem.

Jak podchodzimy do tego inaczej

Audyt, który kończy się ogólnikami typu “architektura wymaga poprawy”, nie jest wart papieru, na którym jest wydrukowany. Nasze audyty kończą się listą konkretnych, zlokalizowanych problemów z priorytetami — z dokładną lokalizacją w kodzie (plik, linia), nie samym opisem słownym.

Konkretnie sprawdzamy:

  • Architekturę — czy podział na warstwy/moduły ma sens, czy dane przepływają w przewidywalny sposób, czy dodanie nowej funkcji wymaga zmian w dziesięciu niepowiązanych miejscach.
  • Wydajność — zapytania do bazy danych (N+1, brakujące indeksy), rozmiar i sposób ładowania zasobów frontendowych, cache’owanie.
  • Bezpieczeństwo — podstawowe luki (SQL injection, XSS, niezabezpieczone endpointy administracyjne, hasła przechowywane źle) w oparciu o OWASP Top 10.
  • Zależności — biblioteki z znanymi lukami bezpieczeństwa, nieaktualizowane od lat pakiety, które w końcu przestaną działać z nowszym środowiskiem.
  • Testy i proces wdrożeń — czy w ogóle istnieją testy automatyczne, czy wdrożenie na produkcję to jedno kliknięcie, czy rytuał z modlitwą.

Stack, którego używamy

Narzędzia dobieramy pod technologię projektu, który audytujemy — profilery specyficzne dla danego języka/frameworka (Node.js, Python, PHP, Java), narzędzia do analizy statycznej kodu, skanery zależności pod kątem znanych luk (CVE), oraz ręczny przegląd kodu tam, gdzie automatyczne narzędzia nie wystarczą — a w kwestiach architektury nigdy nie wystarczają.

Jak wygląda współpraca krok po kroku

  1. Wstępna rozmowa i dostęp do kodu. Ustalamy zakres audytu (cała aplikacja czy konkretny obszar, np. tylko backend albo tylko wydajność) i dostajemy dostęp do repozytorium (read-only wystarczy).
  2. Przegląd. Analizujemy architekturę, kod, zależności i (jeśli w zakresie) bezpieczeństwo. To praca głównie po naszej stronie — nie wymaga codziennego angażowania Twojego zespołu.
  3. Dokument z wynikami. Lista znalezisk z lokalizacją w kodzie, priorytetem i rekomendacją naprawy — w formacie, który Twój zespół techniczny może od razu zacząć wdrażać.
  4. Omówienie wyników. Spotkanie, na którym przechodzimy przez najważniejsze znaleziska i odpowiadamy na pytania — nie zostawiamy dokumentu bez kontekstu.
  5. Opcjonalnie: wdrożenie poprawek. Jeśli chcesz, żebyśmy naprawili znalezione problemy, wyceniamy to jako osobne zlecenie na bazie tego, co już wiemy o Twoim kodzie — bez ponownego audytu od zera.

Co dalej

Jeśli podejrzewasz, że Twoja aplikacja ma problem, którego nikt w zespole nie potrafi dokładnie zlokalizować, albo planujesz duże zlecenie i chcesz niezależnej opinii przed podpisaniem umowy — napisz przez formularz kontaktowy albo na biuro@devscave.com.

Najczęstsze pytania

Czy audyt kodu jest wiarygodny, jeśli robi go firma, która chce potem sprzedać development?

Rozumiemy tę wątpliwość, dlatego audyt kończy się konkretnym dokumentem z listą problemów i priorytetów — niezależnie od tego, czy zdecydujesz się zlecić nam naprawę, zrobić to swoim zespołem, czy zlecić komuś innemu. Nie ukrywamy w audycie rzeczy, które sami moglibyśmy naprawić najlepiej — to nie miałoby sensu wizerunkowo ani etycznie.

Ile trwa audyt kodu średniej wielkości aplikacji?

Dla projektu w skali kilkudziesięciu tysięcy linii kodu to zwykle 3-5 dni roboczych: przegląd architektury, najważniejszych ścieżek w kodzie, zależności, testów (jeśli są) i konfiguracji infrastruktury. Większe systemy (mikroserwisy, wiele repozytoriów) wymagają więcej czasu — wyceniamy to indywidualnie po wstępnym przeglądzie zakresu.

Co dostaję na koniec audytu?

Dokument z konkretnymi znaleziskami, każde z lokalizacją w kodzie (plik, linia) i oceną wagi problemu (krytyczny / ważny / kosmetyczny). Nie ogólniki typu "kod mógłby być czystszy" — konkretne "ten endpoint nie waliduje inputu, tu jest N+1 query, ta zależność ma znaną lukę bezpieczeństwa".

Robicie też audyty bezpieczeństwa, czy tylko jakości kodu?

Podstawowy przegląd pod kątem OWASP Top 10 (SQL injection, XSS, niezabezpieczone endpointy, przechowywanie haseł) jest częścią standardowego audytu. Pełny penetration test to osobna usługa, wymagająca innych narzędzi i uprawnień — jeśli Twój projekt tego wymaga, powiemy to wprost i pomożemy znaleźć odpowiedni zespół, jeśli sami nie mamy w danym momencie takich zasobów.

Czy pomagacie przy wyborze technologii przed startem nowego projektu, czy tylko naprawiacie istniejące?

Obie sytuacje. Konsulting przed startem projektu (wybór stacku, architektury, dostawcy hostingu) kosztuje ułamek tego, co kosztuje poprawianie złej decyzji po 6 miesiącach developmentu — to jedna z bardziej opłacalnych rzeczy, jakie można zrobić na starcie projektu.