Oto moja lista kontrolna dotycząca dojrzałości projektu:
Czy projekt osiągnął swój początkowy kamień milowy?
Unikałbym dodawania jakiegokolwiek kodu, jeśli nie osiągnąłby swojego opisanego początkowego kamienia milowego. Nie sugeruję, abyś zawsze ufał programistom twierdzącym, że jego projekt jest gotowy do produkcji i zawsze starał się oceniać takie twierdzenia, ale zdecydowanie powinieneś jej zaufać, kiedy ona ci to mówi, tj. Oznaczając oprogramowanie jako wersję 0.x, alfa, beta, kandydat do wydania i tak dalej.
Czy istnieje odpowiednia dokumentacja?
Idealny projekt oferowałby:
- Podręcznik użytkownika pełen przykładów
- Podręcznik integracji / rozszerzenia, jeśli jest to biblioteka
- Dokumentacja API
- W pełni udokumentowany kod źródłowy
- Śledzenie problemów publicznych
Czy programiści nadal są zaangażowani w projekt?
Nigdy nie wiadomo, czy programiści pozostaną zaangażowani w przyszłość, chyba że jest to projekt wspierany przez fundację / firmę. Ale prawie zawsze możesz stwierdzić, czy są one teraz popełnione, sprawdzając, czy:
- Ostatnia aktywność zatwierdzania
- Najnowsze funkcje (nie tylko poprawki błędów)
- Ostatnia aktywność związana z dokumentacją (aktualizacje dokumentów, posty na blogach itp.)
Dobrym wskaźnikiem dojrzałości projektu jest także druga generacja programistów, aktywnych programistów, którzy zaangażowali się po początkowych etapach.
Czy programiści są osiągalni?
- Czy reagują na błędy?
- Czy zapewniają one inne środki kontaktu oprócz ogólnego narzędzia do śledzenia problemów? Jest to drobna pozycja na liście kontrolnej, ale w przypadku projektów z jednym deweloperem alternatywne sposoby kontaktu mogłyby pomóc w przypadkach takich jak „sprawa zaginionego programisty” .
Teraz, dla bardziej szczegółowych pytań:
Prędkość
W projekcie z publicznym narzędziem do śledzenia problemów zdecydowanie sprawdziłbym, ile czasu zajmuje zamknięcie problemów. Oczywiście szybkość nie zawsze oznacza jakość, więc prawdopodobnie przejrzałbym zamknięte problemy, wybrałem kilka, które uważam za ważne, i oceniam czas reakcji programistów oraz jakość.
Kompatybilność licencji
Jeśli chodzi o kwestie prawne, nigdy nie włączaj projektu open source do bazy kodu, jeśli nie masz 100% pewności, że korzystanie z niego jest zgodne z jego licencją. W razie wątpliwości zawsze możesz zapytać twórców projektu, a nawet zapytać tutaj.
Hype społeczności
Zawsze powinieneś oceniać szum. Zalecenia od innych programistów są prawie zawsze wystarczająco dobrym wskaźnikiem dojrzałości projektu.
Każdy element na liście kontrolnej jest opcjonalny, z wyjątkiem zgodności licencji. Zintegrowałem wiele martwych i nieudokumentowanych projektów w moim kodzie, zawsze zależy to od twoich specyficznych potrzeb i tego, jak widzisz swój ewoluujący kod.
