Kiedy znajdziesz nową bibliotekę / projekt open source, na jakie kryteria patrzysz przed włączeniem jej do bazy źródłowej.
Czy są pytania prawne, na które musisz odpowiedzieć?
Czy szukasz pewnej prędkości rozwoju?
Czy szum społeczności jest wystarczająco dobrym powodem?
Czy twoja decyzja zmienia się, jeśli jesteś osobą odpowiedzialną za projekt?
Czy złożoność domeny lub kodu zmienia Twój sposób myślenia o tym?
Odpowiedzi:
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:
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:
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?
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.
Oprócz odpowiedzi Yannisa Rizosa, wypróbuję ją w skrócie lub przetestuję projekt, jeśli to możliwe. Pozwoli ci to zapoznać się z dziwactwami związanymi z produktem, zanim w grę wejdzie jakikolwiek ważny element. Projekt nie powinien być zbyt mały, ponieważ pozostawiłoby to zbyt wiele baz kodowych do niezbadania. Spróbuj, aby przekonać się, czy możesz zrobić to, co chcesz bez większego problemu. Jeśli nie możesz samodzielnie opanować podstaw przy pomocy dokumentacji i pytania lub dwóch dla społeczności projektowej, możesz rozważyć skorzystanie z bardziej odpowiednio obsługiwanej bazy kodu. Jeśli pierwszy test Ci się powiedzie, możesz zacząć go używać naprawdę. W przeszłości miałem do czynienia z tym problemem i po dwóch pierwszych razach postanowiłem przetestować nowe rzeczy przed ich wprowadzeniem do produkcji,
BP mądry: wprowadzanie nowych rzeczy nigdy nie powinno odbywać się bez jakiejś formy fazy przygotowawczej / uczenia się.