W ciągu ostatnich kilku dni opublikowałem na GitHub pierwszy kod mojej aplikacji CMLNetKit. Od razu dostałem pytanie: “Już napisałeś całość? Tak szybko?“. No nie, aplikacja nie jest skończona. Ona jeszcze mało co potrafi, tak naprawdę zaimplementowałem jedynie jedną z funkcjonalności, o których pisałem w moim poprzednim artykule. Dlaczego zatem zdecydowałem się na pierwsze publiczne udostępnienie kodu już teraz? Jak szybko publikować pierwszy kod własnej aplikacji w repozytorium?
Czy warto udostępniać kod we wczesnej fazie projektu?
Wróćmy na chwilę do moich dwóch poprzednich artykułów. W pierwszym z nich “Zasady budowy mechanizmów automatyzacji” powiedziałem Ci o regule “Start small, grow big“. Zasada ta mówi, byśmy nigdy nie porywali się na pisanie wielkiego narzędzia od razu. Zacznijmy od czegoś małego, rozwiązującego mały problem i w miarę jego rozwoju dodawajmy kolejne funkcjonalności.
Drugim z aspektów pracy nad nowym projektem jest to, że biznes, czyli tak naprawdę jednostka budżetowa w Twojej firmie, która płaci za Twoją pracę, mógł zobaczyć jej efekty. Jeżeli w przeciągu kilku dni pracy jesteśmy w stanie pokazać działający zalążek mechanizmu automatyzacji i zastosować go w praktyce, to już jesteśmy na wygranej pozycji. Osoby, które decydują o tym, czym się zajmujemy na co dzień, na pewno bardziej przychylnie będą patrzyły na Twoją pracę.
Jest jeszcze aspekt czysto praktyczny. Być może w Twojej firmie istnieją procedury związane z rozwojem oprogramowania lub firma ma dział bezpieczeństwa odpowiedzialny za procesy biznesowe i infrastrukturę IT. W takim wypadku zarówno proces samego pisania kodu, jak i wdrażania narzędzia do powszechnego użycia musi przejść odpowiednie ścieżki akceptacji. Być może będzie wymagane wdrożenie dodatkowych narzędzi lub zmiana procedur. Łatwiej nad tego typu problemami pracować na małym projekcie i w ten sposób przetrzeć szlaki, niż od razu na dużym skomplikowanym rozwiązaniu.
Jak wybrałem tą pierwszą funkcjonalność do zaimplementowania?
Gdy zacząłem projektować strukturę mojego programu, bardzo szybko zauważyłem, że składać będzie się on z co najmniej dwóch grup funkcjonalności. Pierwsza z nich to zestaw metod, które odpowiadać będą za komunikację z serwerem CML2 za pośrednictwem API. Druga zaś to metody modyfikujące konfigurację topologi laba według wskazanych parametrów. Ich minimalny zestaw wyszczególniłem w artykule “Jak określam założenia projektu automatyzacji“.
Funkcjonalności z pierwszej grupy musiałem zaimplementować, aby zapewnić komunikację mojego programu z serwerem CML2. Spośród funkcjonalności z drugiej grupy wybrałem najprostszą do zaprogramowania.
Dodatkowo doszedł jeszcze element związany z procesowaniem argumentów, z jakimi aplikacja zostanie wywołana. Mogłem co prawda zaszyć wszystkie niezbędne wartości takie jak adres serwera CML, login i hasło użytkownika w kodzie, postanowiłem jednak szybko zaadaptować kod z innego mojego programu wykorzystujący bibliotekę argparse.
Warto też zauważyć, że jeżeli ktokolwiek będzie chciał się dołączyć do tego projektu, może zgłosić do niego swoje poprawki kodu, lub otworzyć zgłoszenie dotyczące problemu, albo funkcji, którą chciałby, abym dodał.
Na co zwracać uwagę publikując pierwszą wersję?
Pierwsza wersja mojego programu jest daleka od ideału. Brakuje w niej choćby obsługi wyjątków, czy wielu elementów dokumentacji kodu. Ocena, czy znane nam niedopracowania są na tym etapie akceptowalne, czy może zagrażają bezpieczeństwu infrastruktury, w ramach której aplikacja będzie uruchamiana, należy do nas. W przypadku aplikacji, uruchamianej w środowiskach produkcyjnych, a nawet testowych prawdopodobnie szedłby na mniejsze kompromisy.
Pamiętajmy także, aby jasno w dokumentacji zaznaczyć, że projekt jest dopiero w początkowej fazie rozwoju. Takie ostrzeżenie zamieściłem w pliku README.rst
Unikajmy także publikowania niedziałającego kodu lub funkcjonalności, która wiemy, że nie działa poprawnie. Zdecydowanie lepiej pokazać mniejszy, ale w pełni działający kod, niż obietnicę implementacji w przyszłości.
