Wyślij lub zgiń (choć z jakością lub bez?)

Jednym z pomysłów, które mnie intrygują, jest mentalność „wyślij to albo zgiń". Jeśli chodzi o to, jak się to nazywa, istnieją jej odmiany, ale idea stojąca za tą frazą jest prosta:

Jeśli masz pomysł, przeprowadź go od pomysłu do produktu tak szybko, jak to możliwe.

Jasne, pomysł dotarcia do koncepcji produktu można również nazwać „koncepcją na gotówkę”, ale nigdy nie ma gwarancji, że wygenerujesz gotówkę, prawda? Jest jednak gwarancja, że ​​uda się z niego zrobić namacalny produkt.

A w kręgach programistycznych zawsze jest wiele rzeczy, które dana osoba może argumentować za lub przeciw pomysłowi. W mojej głowie dwa plusy i minusy, które przychodzą mi od razu do głowy, to:

1. Zawodowiec. Szybkie wykonanie czegoś, co działa i [potencjalnie] generuje przychody.
2. Con. Słaba architektura, konserwacja, skalowalność, testowalność i tak dalej.

Krótko mówiąc, może istnieć kompromis między tym, jak szybko można wysłać coś na rynek, a architekturą projektu. Czasami jest, czasami nie. Ogólnie rzecz biorąc, uważam, że można bezpiecznie założyć to pierwsze.

Co więcej, niektórzy mogą postrzegać to pierwsze jako łatwe wyjście, inni mogą postrzegać to drugie jako ćwiczenie w YAGNI lub, jeszcze prościej, że problem można rozwiązać, gdy tylko się pojawi.

Ale co to ma teraz wspólnego z czymkolwiek?

Wyślij lub zgiń?

Cały powód, dla którego poświęcam czas na pisanie o tym, jest taki, że jest to coś, o czym ja i podejrzewam, że inni w naszej dziedzinie przynajmniej trochę się zastanawiam. Wszystko to jest dobre, gdy mówimy o tym w sensie abstrakcyjnym, ale spróbuję powiązać to z czymś bardziej realistycznym.

Pewnego razu…

Kilka lat temu rozwój front-endu polegał na zawijaniu treści w elementy inline lub blokowe i stylizowaniu ich za pomocą podstawowego CSS?

Mieliśmy zaawansowane narzędzia do pracy z naszym backendowym kodem, ale front-end był stosunkowo prosty, pomijając być może standardy kodowania narzucone przez firmę lub zespół, z którym współpracowaliśmy.

Ale wtedy…

Nasze urządzenia rozwinęły się (co dla przypomnienia uważam za dobrą, a nawet naturalną rzecz w technologii). Wraz ze wspomnianym postępem, mamy teraz narzędzia przeznaczone specjalnie do programowania front-end, które są tak samo zaawansowane pod pewnymi względami, jak te, których używamy do oprogramowania zaplecza.

Jasne, mamy takich, którzy są „pełnymi programistami”, ale z radością przyznaję, że o wiele wygodniej jest mi pracować po stronie serwera niż front-endu. Jeśli pracuję na froncie, zwykle trzymam się narzędzi, z którymi jestem zaznajomiony i staram się trzymać barierek wyznaczonych przez pas, na którym pracuję.

Pomaga skoncentrować się na rozwoju, szybko i spójnie we wszystkich projektach.

Ok, więc po co?

Ta sekcja sama w sobie może być długim postem, ale nie jestem zainteresowany posuwaniem się tak daleko. Zamiast tego wezmę teraz jeden wycinek tego, jak działa programowanie front-end i zobaczę, czy nie mogę go użyć, aby wyjaśnić swój punkt widzenia.

Coraz bezczelny

Weźmy na przykład to, czym stał się CSS. Mamy języki nad językami (takie jak Sass, który znajduje się na szczycie lub dodaje do podstawowego CSS).

Mamy też procesory, które kompilują, minimalizują, szarpią i uniemożliwiają nam zobaczenie naszej pracy, zanim pewne błędy i ostrzeżenia zostaną naprawione ze względu na jakość. (Nie uważam tego za coś złego, ale pokazuje rosnący poziom złożoności – a może dojrzałości – naszego oprzyrządowania front-endowego).

Rozwój front-endu jest zbyt łatwy, zróbmy to bardziej złożonym, abyśmy mogli czuć się mądrzejsi wśród naszych współpracowników, którzy najwyraźniej mają do czynienia z bardziej „krytycznymi” aspektami biznesu. Pamiętaj, że to konkurs.

Ten artykuł ma humorystyczne podejście do całej sprawy.

Rozsądny stopień jakości

Żeby było jasne, nie mówię, że to zła rzecz, ale mówię, że rzeczy, które kiedyś były zdegradowane po stronie serwera lub do języków skompilowanych, teraz rozciągają się na cały stos programistyczny aplikacji internetowej.

Aby być tak krystalicznie czystym, jak to tylko możliwe: jestem za jakością. Wysyłanie rzeczy bez jakiegokolwiek stopnia może być postrzegane jako ćwiczenie z nieodpowiedzialności.

Ale wierzę również, że należy zachować równowagę między pisaniem najbardziej optymalnego, funkcjonalnego i wydajnego kodu możliwego przy ograniczeniach czasowych i budżetowych.

Nie wierzę, że bez względu na to, jak bardzo staramy się to narzucać sobie, żyjemy w deweloperskiej utopii, w której możemy optymalizować, projektować i wdrażać nieskazitelne systemy w każdym projekcie.

Wydaje się jednak, że staraliśmy się, aby go stworzyć, czyż nie?

Ale czy w pewnym momencie nie warto zapytać, czy wszystkie narzędzia, które tworzymy i wszystkie rzeczy, które dodajemy do naszych projektów, usuwają to, co w pierwszej kolejności wprowadziło nas do branży? To prawda, dla niektórych z nas jest to prawdopodobnie inne. Czy uczciwie jest zapytać, że posiadanie pomysłu, napisanie kodu, który go urzeczywistni, i zobaczenie, jak rozwiązuje problem, jest tym, co sprowadziło nas do owczarni?

W tym momencie jednak wprowadziliśmy tak wiele narzędzi, że uruchomienie środowiska programistycznego dla aplikacji internetowej działającej od bazy danych do przeglądarki jest trudnym zadaniem.

Tak wiele rzeczy musi się wydarzyć, zanim będziemy faktycznie gotowi do pisania kodu, że samo podjęcie pierwszych kroków może stać się nużące, a nawet nieco wyczerpujące.

Osobista, ostateczna opinia

Skłaniam się ku egzekwowaniu silnych praktyk i narzędzi zorientowanych obiektowo w wielu projektach, nad którymi pracuję z moim zespołem i które wysyłam dla innych, ponieważ wiem z doświadczenia, że ​​czas, pieniądze i dane mogą zostać utracone z powodu „ t adresowany ze wszystkich stron.

Nie oznacza to, że wysyłka czegoś szybko neguje to wszystko. Ale proces i organizacja kodu stojącego za projektem to coś, co bardzo trudno mi zignorować do tego stopnia, że ​​wydaje mi się prawie paraliżujące, gdy wysyłam coś, co nie zostało przetestowane i zweryfikowane w najwyższym możliwym stopniu (a nawet wtedy są problemy).

Z drugiej strony jest część mnie, która chce poeksperymentować z jednym lub dwoma pomysłami za mentalnością „wyślij lub zgiń”, po prostu zobacz, jak szybko można coś zbudować, wysłać i wygenerować dowolny rodzaj przychodów, niezależnie od tego, jak nieskazitelne podstawą kodu jest.

I może spróbuję tego z kilkoma nadchodzącymi projektami.