Obawa, że ​​aplikacja internetowa nie będzie „przyszłościowa”

Jestem programistą małej lokalnej aplikacji SaaS. Obecnie ma około pół tuzina klientów.

W miarę projektowania aplikacji coraz trudniej mi przekonać się do poświęcenia czasu na projekt, co miało miejsce w początkowej fazie. Po przywiązaniu do projektu i kodu, który już napisałem, obawiam się, że wszelkie dodatkowe prace, które popełniam, zostaną w najbliższej przyszłości unieważnione, gdy okaże się, że aplikacja nie skaluje się dobrze wraz z rozwojem firmy.

Jako student uniwersytetu ubiegający się o staż, pracodawcy kwestionują mój wybór polegający na tym, że nie używam ram internetowych podczas wywiadów, co spowodowało, że jeszcze bardziej wątpiłem w moją poprzednią pracę. Po prostu nie znam żadnych frameworków internetowych i nie wiem, z których zacząć korzystać.

W styczniu odbyłem staż jako programista z pełnym stosem, gdzie zacznę uczyć się frameworków front-end, ale narasta presja na ukończenie aplikacji i zastanawiam się nad całkowitym złomowaniem aplikacji i rozpoczynaniem od nowa, co zrobiłem wcześniej. Aplikacja jest obecnie wbudowana w PHP i jQuery (dla wywołań AJAX) i używa MySQL do swojej bazy danych. Czy są jakieś przemyślenia na temat tego, jak mogę przezwyciężyć ten blok mentalny i upewnić się, że moja aplikacja będzie skalowalna? Z góry dziękuję.

Idealny jest wrogiem dobra.

Lub inaczej: nie martw się dzisiaj. Jeśli Twoja aplikacja robi to, co musi, to jest w porządku. Przepisywanie części oprogramowania w dalszej kolejności nie jest niczym złym; w tym momencie 1) wiesz lepiej, co próbujesz zbudować i 2) wiesz, które bity są w rzeczywistości wąskim gardłem. Możesz poświęcić ogromną ilość czasu na napisanie aplikacji, która byłaby skalowana do miliona użytkowników, ale dla obecnych sześciu klientów nie byłoby to lepsze niż to, co masz dzisiaj .

Czy są jakieś przemyślenia na temat tego, jak mogę przezwyciężyć ten blok mentalny i upewnić się, że moja aplikacja będzie skalowalna?

Sednem problemu nie jest skalowalność. Sednem problemu jest myślenie, że rozwiążesz go za pierwszym razem .

Powinieneś skupić się na pisaniu czystego kodu. Ponieważ czysty kod maksymalizuje wygodę, gdy (nieuchronnie) trzeba coś zmienić w przyszłości. I to jest prawdziwy cel, który powinieneś mieć.

Teraz próbujesz wymyślić idealny kod do napisania. Ale nawet jeśli uda ci się to zrobić, kto powie, że wymagania się nie zmienią, a może podejmowałeś decyzje na podstawie złych informacji lub złej komunikacji?

Nie możesz uniknąć błędów, nawet jeśli nie są to twoja wina. Skoncentruj się na pisaniu kodu, w którym łatwo będzie później zmienić rzeczy, zamiast mieć nadzieję na napisanie kodu, którego nie będziesz musiał zmieniać w przyszłości.

Po przywiązaniu do projektu i kodu, który już napisałem,

Absolutnie sympatyzuję z tym sentymentem. Ale przywiązanie do napisanego kodu jest problemem.

Jedyną rzeczą, która powinna być stała, jest chęć rozwiązania określonego problemu . Sposób, w jaki rozwiązujesz ten problem, jest tylko drugorzędną kwestią.

Jeśli jutro zostanie wydane nowe narzędzie, które zmniejszy bazę kodów o 80%, czy będzie ci przykro, że Twój kod nie jest już używany; czy będziesz szczęśliwy, że twoja baza kodu stała się mniejsza i dużo czystsza / łatwiejsza w zarządzaniu?

Jeśli to pierwsze, masz problem: nie widzisz rozwiązania dla kodu . Innymi słowy, skupiasz się na kodzie i nie widzisz większego obrazu (rozwiązania, które ma zapewnić).

Obawiam się, że wszelkie dodatkowe prace, które popełniam, zostaną w najbliższej przyszłości unieważnione, gdy okaże się, że aplikacja nie skaluje się dobrze wraz z rozwojem firmy.

To inny problem na inny dzień.

Po pierwsze, budujesz coś, co działa. Po drugie , poprawiasz kod, aby naprawić wszelkie błędy, które wciąż mogą się wyświetlać. To, co obecnie robisz, to powstrzymywanie się przed pierwszym zadaniem ze strachu przed koniecznością wykonania drugiego zadania.

Ale jaka jest inna opcja? Nie możesz powiedzieć przyszłości . Jeśli poświęcisz czas na zastanawianie się nad przyszłymi możliwościami, i tak zgadniesz . Zgadywanie jest zawsze podatne na popełnienie błędu.

Zamiast tego skompiluj aplikację i udowodnij , że rzeczywiście istnieje problem. A gdy problem zostanie wyjaśniony, zaczniesz go rozwiązywać.

Innymi słowy: Henry Ford nigdy nie zbudował samochodu zgodnego ze standardami / oczekiwaniami z 2018 roku. Ale gdyby nie zbudował Modelu T, wadliwego samochodu według współczesnych standardów, nikt nie zacząłby korzystać z samochodów, nie byłoby przemysłu motoryzacyjnego i nikt nie miałby samochodu, który mógłby następnie ulepszyć.

Poprosiłem pracodawców o kwestionowanie mojego wyboru polegającego na tym, że nie korzystam z ram frameworka podczas wywiadów, co spowodowało, że jeszcze bardziej wątpiłem w moją poprzednią pracę.

Ważną częścią tutaj nie jest to, z jakiego systemu korzystasz (każdy pracodawca, który cię ocenia, że ​​nie wykonuje swojej pracy właściwie). Ważną częścią tutaj jest wiedza o tym, co robisz i dlaczego to robisz .

Na przykład możesz uniknąć istniejącego frameworka, ponieważ chcesz dowiedzieć się, dlaczego jest on przydatny, robiąc to najpierw. Lub możesz próbować stworzyć własny framework.

Jedyną złą odpowiedzią tutaj jest „nie wiem”, ponieważ pokazuje brak podejmowania świadomych decyzji. Że jest czerwona flaga dla pracodawcy.

Po prostu nie znam żadnych frameworków internetowych i nie wiem, z których zacząć korzystać.

Ten sam problem pojawia się tutaj. Rozwiązaniem jest nie myśleć więcej, ale działać:

• Przestań zastanawiać się nad idealną odpowiedzią .
• Wybierz ramy. Jeśli nie masz preferencji, wybierz losową. Użyj tarczy, rzuć kostką, rzuć monetą, wybierz kartę.
• Użyj tego.
• Podobało ci się to? Czy było coś, co cię denerwowało?
• Sprawdź, jak zapobiegać tym złym elementom. Czy niewłaściwie używałeś frameworka, czy może właśnie tak ma on działać?
• Gdy poczujesz, że masz kontrolę nad ramą (niezależnie od tego, czy ci się to podoba, czy nie), wybierz nową ramę i powtórz cykl.

Aby przeczytać więcej na ten temat, przeczytaj Sposób myślenia> sposób myślenia . Autor wyjaśnia to lepiej niż ja.

ale presja na ukończenie aplikacji rośnie, i rozważam złomowanie aplikacji całkowicie od nowa

Chyba że obecna baza kodów jest absolutnie niemożliwym do utrzymania bałaganem; podejmujesz odwrotną decyzję.
Programiści często myślą, że wyrzucenie rzeczy byłoby lepszym wyborem. To bardzo powszechne uczucie. Ale rzadko jest to właściwy wybór.

Wyrzucanie kodu i rozpoczynanie od zera jest jak utknięcie w korku na drodze do pracy, martwienie się, że spóźnisz się do pracy (spóźnisz się na termin), zamiast tego jedź do domu i spróbuj ponownie jechać tą samą drogą. To nie ma sensu. Możesz utknąć w korku, ale nadal jesteś bliżej pracy niż w domu.

Pomimo ogromnej kwoty pieniędzy, które Facebook i Google włożyły w marketing, aby przekonać cię, że jest inaczej, frameworki istnieją z dwóch głównych powodów:

• Po pierwsze, odciążenie sprzętu / sieci do operacji po stronie klienta poprzez wprowadzenie stanu i logiki do klienta
• Po drugie, stosownie do dodatkowej logiki klienta niezbędnej do obsługi pierwszego punktu, zapewniają izolowane konteksty wykonania, dzięki czemu można wcisnąć kod innej osoby na stronę bez niszczenia czegokolwiek.

Prawdopodobnie musisz sięgnąć po ramę, aby rozwiązać te problemy, jeśli aplikacja jest z natury stanowa, jeśli ilość stanu aplikacji, który zapisujesz po stronie klienta, jest dość złożona, jeśli oczekujesz bardzo dużej liczby klientów ze słabym opóźnieniem sieci (urządzenia mobilne, lub z dala od serwera) lub jeśli istnieje silna potrzeba biznesowa do obsługi szczególnie zaawansowanego CSS lub dynamicznego tworzenia elementów.

Framework marketing chce, abyś wierzył, że ich specjalna metoda architektury przyspiesza rozwój i ułatwia konserwację. Jest to oczywiście nieprawdziwe dla małych zespołów pracujących nad prostymi projektami. Izolowanie kodu i organizowanie importu może pomóc dużemu zespołowi szybciej wprowadzić produkt na rynek. Zapewnia znacznie mniej dla jednoosobowego zespołu programistów pracującego nad już funkcjonalnym projektem.

Poświęcisz więcej czasu na naukę, jak dopasować istniejący, funkcjonalny kod do frameworka, niż w rzeczywistości wdrożysz funkcje, i są całkiem spore szanse, że ktoś gdzieś coś zaktualizuje, a kod napisany w tym framterze przestanie działać w ciągu 18 miesięcy, chyba że ktoś tam jest, żeby to stale utrzymywać.

Vanilla JS i w mniejszym, ale wciąż znaczącym stopniu JQuery, nie cierpią z powodu tych problemów. Z pewnymi znaczącymi wyjątkami, aplikacje JQuery + AJAX, które nie polegają na specyficznych zachowaniach przeglądarki i rezygnują z zewnętrznych zależności tam, gdzie jest to uzasadnione, kontynuują pracę 10-15 lat po ich pierwotnym napisaniu z bardzo niewielkimi zmianami.

Frameworki są idealne dla typowych startupów obsługujących bieżące, złożone, publicznie dostępne aplikacje internetowe. Pozwalają dużym zespołom na dobrą koordynację, ładną integrację z platformami dodawania dostawców oraz obsługę nowych widżetów i paradygmatów projektowych, aby pomóc Ci pozostać konkurencyjnym.

Nic z tego nie ma znaczenia w przypadku małego narzędzia programowego ze stałą grupą odbiorców, którego zamierzasz porzucić. Przyjmowanie frameworku spowalnia tempo rozwoju w miarę dostosowywania się do nowego paradygmatu i stwarza niepotrzebne ryzyko kompatybilności. Utrzymanie prostego kodu po stronie klienta (i idealnie hostowanego) oznacza, że ​​obszar ryzyka zgodności znacznie spada. Przeglądarki się zmienią, adresy URL CDN przestaną działać, zależności przestaną być aktualne - Ale nikt nie dotyka tego serwera i będzie działał dobrze.

Nie przyjmuj ram, chyba że rozwiążą one konkretny problem architektoniczny, który masz dzisiaj lub możesz szybko przewidzieć, i zdecydowanie rozważ rozważenie tej kwestii w inny sposób, jeśli jest to w ogóle możliwe.

Najlepszą rzeczą, jaką możesz zrobić, aby „zabezpieczyć swoją przyszłość”, jest przestrzeganie najlepszych praktyk w zakresie projektowania systemu, aby zmaksymalizować luźne połączenie i rozdzielenie problemów. Nie ma żadnej części aplikacji, która byłaby bezpieczna przed starzeniem się, ale możesz wiele zrobić, aby odizolować kod, który staje się przestarzały z powodu X od kodu, który niekoniecznie musi być pod wpływem X.

Uważam jednak, że twoja troska powinna być mniejsza o wzrost / skalowalność twojej aplikacji niż tempo wzrostu własnego doświadczenia i możliwości. Blok mentalny, który opisujesz, brzmi dla mnie jak uczenie się stagnacji lub świadomość wielu znanych niewiadomych bez strategii lub narzędzi do ich rozwiązania.

Ramy nie nadają się szczególnie dobrze do rozwiązania wyzwania „zabezpieczenia na przyszłość”, chociaż mogą dostarczyć odpowiednich wskazówek początkowych niedoświadczonym, zwykle za pośrednictwem wzorców projektowych wysokiego poziomu, takich jak MVC. Raczej są one bardziej przydatne jako sposoby przyspieszenia rozwoju poprzez zapewnienie silnej spójności i często kosztem ściślejszego sprzężenia. Załóżmy na przykład, że korzystasz z dostarczonego przez framework systemu mapowania obiektowo-relacyjnego w całej aplikacji do interakcji z bazą danych, wraz z integracją z systemem buforowania. Być może później musisz przełączyć się na nierelacyjny magazyn danych, a teraz ma to wpływ na wszystko , co go używa.

Bałagan, którego teraz nie masz, nie pochodzi z tego, z czego korzystałeś, ale z tego , gdzie go użyłeś (prawdopodobnie prawie wszędzie na zapleczu). O ileż lepiej będziesz, jeśli kod, który wyświetla stronę, nigdy nie pobiera danych, które renderuje.

Załóżmy, że chcesz dodać jakiś mały widget do strony, która wymaga dodatkowych skryptów i zasobów do poprawnego działania. Jeśli używasz frameworka, możesz zapytać: „W jaki sposób chcę dodać zależności do strony w tym celu?” Jeśli nie, to pytanie jest bardziej otwarte: „Jakie problemy techniczne dotykam, które należy jakoś rozdzielić?” Odpowiedź na to pytanie wymaga większego doświadczenia, ale oto kilka wskazówek:

• Co by się stało, gdybyś jutro przeniósł wszystkie zasoby statyczne (skrypty, obrazy itp.) Na osobny serwer, sieć dostarczania treści itp. Lub zaczął próbować spakować je wszystkie, aby poprawić wydajność?
• Co by się stało, gdybyś zaczął umieszczać ten widget na różnych stronach lub wiele jego wystąpień na tej samej stronie?
• Jak rozpocząć wykonywanie testów AB na różnych wersjach widżetu?

Jeśli coś z tego brzmi przytłaczająco, sugeruję, abyś na razie używał frameworka, nie tyle ze względu na swoją aplikację, co ze względu na własny rozwój. Jednak niekoniecznie zacznij od nowa. Zamiast tego używaj ram jako programu nauczania, aby pomóc w ewolucji Twojej aplikacji.

Są tylko dwa sposoby uczenia się. Jedna polega na próbach i błędach, a druga na uczeniu się z doświadczeń innych. Próby i błędów nie można wyeliminować. Tworzenie oprogramowania jest z natury ciągłym obszarem nauki, a każdy kod, który nie robi niczego nowego lub innego, jest z definicji zbędny. (Zamiast tego użyj kodu, który jest już napisany.)

Sztuką jest zminimalizowanie go poprzez proaktywne wyszukiwanie istniejącej wiedzy (strategie, najlepsze praktyki oraz kod / biblioteki / frameworki) na każdym etapie procesu programowania, abyś nie musiał ciągle wymyślać na nowo koła.

Co do aplikacji aktualnie pisanie, jednak swoją pierwszą troską powinno być po prostu zrobić to z minimum przyziemne wysiłku (co jest trochę jak zapachy kodu, ale dla procesu rozwoju). Biorąc pod uwagę naturę uczenia się przez ludzi, najszybszym sposobem na osiągnięcie wysokiej jakości jest rozpoczęcie od czegoś . O wiele łatwiej jest zrozumieć cel, kiedy można go ukształtować, krytykując coś, co już masz.

Jeśli możesz zaakceptować fakt, że duża część kodu, który piszesz, jest procesem uczenia się jednorazowego użytku i niezbędnym do znalezienia dobrych projektów, które pomogą Ci to utrzymać. W końcu to wyzwanie związane z rozwiązywaniem problemów sprawia, że ​​tworzenie oprogramowania jest angażujące, a wyzwanie to jest zawsze obecne, jeśli to, co robisz, jest warte zachodu (patrz stwierdzenie „ciągłe uczenie się” powyżej).

Przede wszystkim „złomowanie rzeczy i zaczyna od nowa” to nigdy opcją ... mimo wszystko, nie można powiedzieć, że masz „pół tuzina klientów?” Masz jeszcze zatrzymał się, by zastanowić się, co oni mogą myśleć o swoim orzeczeniem, biorąc pod uwagę, że są one teraz (prawdopodobnie) „całkowicie zadowolony ze swojej pracy ?!”

Oto analogia, której lubię używać:

• „Moim zadaniem jest budowanie domów dla ludzi, w których ludzie będą mieszkać, dla ludzi, którzy chcą budować firmy i tak dalej”. Moje zadanie polega na tym, aby „te niewiarygodnie małe, zbyt wysławione kawałki piasku” wykonały pożyteczną pracę. (Podobnie jak budowniczowie domów wytwarzają domy z płyt gipsowo-kartonowych, płytek ceramicznych, bloczków betonowych i 2x4).

• Jednak o ile „gwoździe”, których używają budowniczowie domów, nie zmieniły się wiele od dwustu lat (z wyjątkiem przejścia z „kwadratowego” na „okrągły”, a następnie przydatnego w pneumatycznych maszynach do wbijania gwoździ), technologia którego używamy, ciągle się zmienia i czasami przechodzi bardzo głęboką zmianę. ("Tak to idzie.")

• „Niemniej jednak, każdy dom, wybudowany raz, na zawsze-after być mieszkał w.” Nie możesz ich eksmitować. Kiedy go zbudujesz i oddasz klucze, „to już nie jest twój dom”. Jest tym, czym jest teraz i będzie trwać bardzo długo.

Obecnie dużą częścią mojej działalności jest pomaganie klientom w radzeniu sobie z oprogramowaniem, które zostało zbudowane dziesięć, dwadzieścia, trzydzieści lub więcej lat temu, z wykorzystaniem technologii „najnowocześniejszych”, które istniały w tamtych czasach - (i Pamiętam) - i które są nadal w użyciu (!) Dzisiaj.

Zapewnienie, że coś jest na przyszłość, jest prawie niemożliwe. Sprawdzanie, czy aplikacja jest skalowalna, nie jest jednak zbyt trudne. Wystarczy napisać test wydajności aplikacji i zobaczyć, ile klientów może obsłużyć. Testy pisemne z pewnością sprawią, że Twoja aplikacja będzie bardziej przyszłościowa, ponieważ będziesz mógł ocenić, jak zachowuje się aplikacja po wprowadzeniu do niej kolejnych zmian.

wrt framework, nie martwiłbym się zbytnio wydajnością / skalowalnością. Jest to coś, co można łatwo sprawdzić i najprawdopodobniej naprawić. Większy problem dotyczy bezpieczeństwa. Frameworki internetowe zwykle pomagają pisać odpowiedni kod uwierzytelniający, pliki cookie, ochronę CSRF itp. Zwłaszcza ze względu na brak doświadczenia lepiej skupić się na tym obszarze.

Zacząłem pisać komentarz na temat ram uczenia się, ale ostatecznie stało się coś, co wygląda bardziej jak odpowiedź, więc oto jest.

Brak znajomości ram wydaje się problemem. W zasadzie w każdym zadaniu webdev będziesz musiał pracować z jakimś frameworkiem. Uczenie się innego środowiska po tym, jak go znasz, nie jest aż tak wielkim problemem, ale uczenie się pierwszego może zająć trochę czasu - dlatego pracodawcy mogą się tym przejmować. Unikanie ram może oznaczać syndrom nie wynaleziony tutaj , co jest szeroko niepraktycznym podejściem.

Ponieważ głównym celem poznania swoich pierwszych frameworków jest nauka wspólnego języka, być może po prostu spróbuj nauczyć się czegoś popularnego wśród swoich rówieśników. Możesz spróbować zmodyfikować prosty projekt napisany w frameworku. Rozpoczęcie projektu od podstaw w środowisku, którego nie znasz, jest bardzo nieefektywnym sposobem uczenia się.

Teraz twoje aktualne pytanie dotyczyło konkretnego projektu i przeniesienia go do frameworka. Wydaje się, że odpowiedź brzmi: zależy, a tak naprawdę nie możemy ci powiedzieć. Jednak przeniesienie rzeczy do nieznanego frameworka jest prawie na pewno złym pomysłem, ponieważ nie możesz nawet wiedzieć, czy ma to sens . Dlatego wydaje się, że powinieneś pozostawić ją taką, jaka jest, i powrócić do tej decyzji w pewnym momencie, gdy poznasz i polubisz jakieś ramy. Inne odpowiedzi zawierają dobre informacje na temat tego, na co należy zwracać uwagę przy podejmowaniu takiej decyzji.

Ten artykuł zyskał wiele uwagi w Hacker News 2,5 roku temu: Napisz kod, który można łatwo usunąć, a nie rozszerzyć. Ta perspektywa może, ale nie musi, pomóc ci poradzić sobie z obecną bazą kodu, ale w przyszłości może pomóc uniknąć frustracji wynikającej z perfekcjonizmu / nadmiernej inżynierii.

Jeśli widzimy „wiersze kodu” jako „wydane wiersze”, to kiedy usuwamy wiersze kodu, obniżamy koszty utrzymania. Zamiast budować oprogramowanie wielokrotnego użytku, powinniśmy spróbować zbudować oprogramowanie jednorazowe.

Nie muszę ci mówić, że usuwanie kodu jest przyjemniejsze niż pisanie.

(moje podkreślenie)

W gwint artykułu na Hacker Aktualności może również być warta przeczytania.

Jeśli chodzi o zapewnienie przyszłości i stosowanie zasad skali i frameworka, jest to wysokie zadanie do podjęcia samodzielnie, prawdopodobnie po prostu nie będę się tym martwił, ale jeśli musisz:

Utrzymuj kod w czystości, postępuj zgodnie z zasadami SOLID, DRY> Google.

Zastosuj moduł równoważenia obciążenia tak szybko, jak to możliwe.

Ustaw co najmniej dwa serwery WWW, obsługuj scenariusze równoważenia obciążenia w kodzie.

I na koniec, są lepsze stosy do obsługi miliona użytkowników niż LAMP, ale jestem pewien, że jest to całkowicie wykonalne.

Przypadek i punkt, patrz: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade Punkt jest ważny, ale 10 GB jest banalne jako przedmiot testu.