Antyporadnik. Osiem sposobów na utopienie własnego startupu (cz. 2)

Pierwszą część antyporadnika, z którego dowiesz się, jak utopić własny startup, przeczytasz tutaj.

5. Zadbaj o niedopasowane narzędzia

Skomplikowany produkt może wymagać skomplikowanej technologii. Analogicznie: do postawienia zwykłego sklepu wcale nie potrzebujesz machine learningu. Jeśli z jakiegoś powodu w projekcie chcesz użyć technologii, która niekoniecznie się do tego nadaje, wiedz, że zamiast rozwiązać problem – coraz bardziej go skomplikujesz. Brzmi obiecująco?

Przypadek: klient X

Majowy, słoneczny poranek – czas, kiedy startupy rozkwitają po wiosennym deszczu. Przybywa do nas klient X, który chce postawić dość złożony CMS z różnymi bajerami – wszystkie komponenty strony modyfikowalne, tu ma migać, tam świecić, serpentyny, a na to wszystko zasmażka. Mówiąc bardziej precyzyjnie: 75% funkcjonalności z platformy Magento (e-commerce) chciał przenieść do Railsów. Budowanie takiego Frankensteina w Railsach sprowadzałoby się do pisania Railsów od nowa. Odmówiliśmy.

6. Wybranej na początku technologii używaj do końca życia. Swojego albo projektu

Przypuśćmy, że zaczynasz budować produkt w Railsach. Z czasem okazuje się, że coś w działaniu aplikacji przestaje być efektywne: wchodzą kolejne funkcjonalności albo zmienia się skala projektu. Żeby produkt dalej się rozwijał, powinieneś/powinnaś przenieść jakąś część aplikacji do innej technologii lub wydzielić z niej mikroserwis. Żeby zrobić to bezboleśnie, trzeba założyć taki scenariusz już na samym początku. Mądry zespół programistów będzie wiedział, które klocki z danej układanki będzie można później podmienić. Ale czy mądry programista jest ci rzeczywiście potrzebny..? 😉

7. Zablokuj modularność aplikacji

Jeśli od początku masz elastyczne podejście do wybranej technologii, modularność będzie tego naturalną konsekwencją. W projekcie pisanym modularnie wszelkie zmiany przyjdą bezboleśnie. Jeśli nie, z czasem będziesz musiał płacić za zrobienie czegoś od nowa. To nieuniknione. I to wygeneruje olbrzymie koszty.

Wyobraź sobie taką sytuację: w twoim produkcie nie działa jeden mały element i aplikacja ładuje się w nieskończoność. Jeśli nie była od początku pisana modularnie, to ten jeden drobiazg może spowodować, że trzeba będzie wszystko przepisać. Railsy niestety zachęcają do krótkowzrocznego podejścia. Dobry zespół programistów zna tę słabość RoR i zawsze się zabezpieczy. Jeśli nie – klęska murowana.

Przypadek: wzorzec projektowy

Wzorcem projektowym, na którym opierają się Railsy, jest MVC. Wdraża się go błyskawicznie, ale wprowadzanie poprawek na kolejnych etapach rozwijania produktu jest żmudne, kosztowne i ryzykowne. Doświadczeni programiści obejdą ten problem tak, że wykorzystają również inny wzorzec, np. CQRS, który wdraża się minimalnie dłużej, ale koniecznie poprawki łatwo w nim zaimplementować. Zmiany będą zawsze, więc jeśli zależy ci położeniu projektu na tym etapie – that’s the way I like it!

8. Spektakularnie utrać zaufanie użytkownika

Zabezpieczenie jakości oprogramowania to temat rzeka. I zbiór znakomitych sposobów, żeby się wyłożyć w najgorszym momencie: kiedy aplikacja działa i masz już grono zaufanych użytkowników.

Żeby zabezpieczyć software, możesz: stosować testy automatyczne, code review i wdrożyć dział Q&A. Zobaczmy, jak to działa w przypadku logowania.

Przypadek: logowanie

Opracowałeś już system logowania. Sprawdzasz, jak działa – jest ok. Tymczasem jakiś czas później, w zupełnie innym miejscu, wprowadzasz zmiany. Jeśli nie stosujesz testów automatycznych, nie jesteś w stanie sprawdzić, czy ta odległa zmiana nie będzie w jakiś sposób wpływać na poprawność działania logowania. Mówiąc potocznie: czy coś się nie wysypie. Jeśli logowanie nie przejdzie testów, wówczas okaże się, co dokładnie trzeba zmienić, żeby proces działał poprawnie. Schemat działa podobnie w przypadku code review (sprawdzanie, czy programista nie pomylił się w kodzie, czy dane rozwiązanie jest najlepsze itd.). Podobnie dział Q&A, który wciela się w rolę użytkownika i wyłapuje takie błędy, których testy automatyczne nie są w stanie przewidzieć. 

Na zakończenie złota myśl na dziś: trudno jest pozyskać zaufanie, ale bardzo łatwo je stracić. Do dzieła!

–

Michał Brodecki

CTO w Binar Apps

Mgr inż. informatyki (Wydział FTIMS Politechniki Łódzkiej). Weteran Ruby – programuje od 6 lat. Ma żonę, jest tatą. Człowiek doświadczony życiowo – był sędzią piłkarskim w lidze okręgowej 🙂 Gra w gry i w planszówki, nie pogardzi dobrym filmem ani serialem. Zawodowo coraz częściej szkoli programistów: na Łódź Jungle Web, na 4Developers, podczas spotkań Łódź Ruby User Group.