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

106

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ę.

cameraguy258
źródło
93
Korzystanie z frameworka ma być tańsze, a nie obiektywnie lepsze. Biznes zawsze będzie pytał „dlaczego nie taniej”, bo to ich praca. Potrzeba wielu lat doświadczenia, aby odpowiedzieć „dlaczego ten framework nie jest taki, ani niestandardowy”. Nie możesz udzielić żadnej znaczącej odpowiedzi na to pytanie jako student / stażysta, po prostu dlatego, że nie wziąłeś udziału w wystarczającej liczbie projektów, aby być świadkiem, jak dany system działa dla danego problemu. Bez takiego doświadczenia jedyne, co możesz zrobić, to paść ofiarą danego marketingu ramowego.
Agent_L,
24
Jedyną rzeczą, którą wiesz o przyszłości, jest to, że nic o niej nie wiesz. Więc po prostu kontynuuj życie w teraźniejszości. Przyszłość znajdzie sposób, aby cię skopać w *** bez względu na to, ile czasu tracisz, próbując tego uniknąć!
alephzero,
20
„Przyzwyczaiłem się do ... kodu, który już napisałem”. Naszą naturą jest przywiązanie do naszej pracy i odporność na jej zmianę. Ale nawet jeśli to zrobisz, pozostanie w kontroli wersji. Oprogramowanie ma być zmieniane, podobnie jak prawdziwy świat. Nie obawiaj się usunąć kodu lub zmienić go znacznie podczas budowania na nim.
bitsoflogic
8
Jeśli chodzi o złomowanie projektu, odradzałbym go. Zazwyczaj dobrze jest zacząć od zera, ponieważ masz dużo rozpędu w obliczu wielu problemów, które już rozwiązałeś. W końcu jednak wróciłeś do nowego problemu, który nie pasuje do modelu. Zamiast tego można poświęcić czas na jego rozwiązanie. Zawsze możesz rozwiązać problem wąskich gardeł, gdy wiesz, co to jest.
bitsoflogic
6
@james_pic Robisz projekty bez podstawowego frameworka (powiedzmy rdzeń asp.net w .NET i tak dalej)? A więc reimplementujesz logikę routingu i wszystkie inne rzeczy na prostej bibliotece http? To wydaje się przesadne i nie rozumiem, jaką przewagę powinno to dać.
Voo

Odpowiedzi:

201

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 .

Philip Kendall
źródło
23
Słuszna uwaga. Jeśli spędzasz 2 miesiące, starając się zabezpieczyć się przed przyszłymi zmianami na 1 tydzień, straciłeś 7 tygodni swojego czasu. Zaakceptuj, że będą zmiany, i udowodnij to w przyszłości tylko wtedy, gdy jest prawie pewne, że trzeba będzie to zrobić.
Neil,
83
YAGNI, kochanie, YAGNI
Kevin
32
Kolejny przypadek „ Przedwczesnej optymalizacji jest źródłem wszelkiego zła ”. Może warto wspomnieć, że nie przeskoczysz z 6 użytkowników na milion. Jeśli wystarczy 6 klientów, aby zapłacić za jednego programistę, to nawet zanim osiągniesz 100 klientów, kod może potrzebować innej struktury, aby umożliwić wielu programistom pracę nad nim w tym samym czasie. Różni się to od optymalizacji wydajności i dzieje się o wiele wcześniej niż żonglowanie milionem użytkowników.
R. Schmitz
22
@ R. Schchitz Ten cytat przydaje się obecnie w zupełnie innym kontekście niż sposób, w jaki Knuth używał go w programowaniu komputerowym jako sztuce. Knuth zdecydowanie sprzeciwia się całemu „po prostu zacznij programować i martw się o optymalizację później”. Mówi, że ludzie optymalizują niewłaściwe części kodu w niewłaściwym czasie. W żaden sposób nie oznacza to, że nie powinieneś tracić czasu na myślenie o swojej architekturze, aby upewnić się, że jest ona wydajna, zanim zaczniesz pisać kod. Może wolisz inne zdanie, ale nie powinieneś cytować Knutha jako obrońcy.
Voo
20
@ R. Schmitz Kiedy Hoare / Knuth wypowiedzieli to stwierdzenie, „optymalizacja” oznaczała zliczanie cykli i inne rzeczy, których i tak już dziś nie robimy, a nie „pomyśl o dobrej architekturze przed rozpoczęciem kodowania”. Wykorzystanie cytatu jako wymówki, aby po prostu nie myśleć o dobrym projekcie systemu, po prostu nie jest tym, co mieli na myśli.
Voo
110

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.

Flater
źródło
9
Zaczynając od zera rzadko jest właściwym wyborem: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
Martin Bonner
10
@MartinBonner Chociaż jest to z pewnością prawda w kontekście, o którym Joel mówi w tym artykule, jeśli jest to dosłownie pierwszy projekt, nad którym pracowałeś, a ty jesteś jedyną osobą, która nad nim pracowała, to bardzo możliwe, że będziesz w stanie napisać coś lepszego. Pamiętam, że przepisałem pierwszy duży osobisty projekt, nad którym pracowałem, i wtedy była to prawdopodobnie słuszna decyzja - oryginalny prototyp został zepsuty nie do naprawy, ponieważ nie wiedziałem, co robię, kiedy go napisałem.
James_pic
4
@ Później zgadzam się z większością tego, co tu napisano, z wyjątkiem jednej rzeczy: jeśli wybierzesz ramę i nie wiesz nic o żadnej z nich, możesz przynajmniej sprawdzić poziom przyjęcia tych ram. Na przykład, ile gwiazdek ma na githubie? Ile tam jest problemów? Ilu współpracowników? Kiedy była ostatnia aktualizacja? Odpowiedzi na te pytania mogą przynajmniej pomóc w wyborze frameworka, w którym można uzyskać pomoc, zatrudnić facetów, którzy znają ją lepiej itp.
Jalayn,
@Jayayn Można by założyć, że początkujący, który nie ma wcześniejszej wiedzy, prawdopodobnie natknie się na dobrze znane frameworki.
Flater,
3
To świetna odpowiedź, ponieważ zachęca do zdyscyplinowanego i metodycznego podejścia. Minęło wiele lat, zanim mogłem w pełni docenić takie porady!
kashiraja
18

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.

Żelazny Gremlin
źródło
2
Kiedy myślę o „frameworku”, myślę o takich rzeczach, jak jQuery, Angular lub React, gdzie zapewnia wiele elementów składowych rzeczy, które byłyby denerwujące w implementacji (i często trudne w implementacji poprawnie i kompatybilnej z różnymi przeglądarkami).
puszysty
@fluffy Co, według Ciebie, robi Angular lub React, co jest znacznie łatwiejsze niż robienie tego samego w waniliowym JS lub JQuery w 2018 roku w przeglądarkach innych niż mobilne? FF / Chrome / Edge mają więcej niż wystarczającą powierzchnię wspólną, aby w dzisiejszych czasach tworzyć w pełni funkcjonalne, małe aplikacje bez podkładek.
Żelazny Gremlin,
3
@IronGremlin Żartujesz? Czy kiedykolwiek używałeś dwukierunkowych powiązań danych lub szablonów Angular / Vue / cokolwiek? W przypadku aplikacji, w których te funkcje są przydatne, stanowią ogromne uproszczenie i pozwalają pozbyć się łamliwego kodu opartego na zdarzeniach. Następnie procesor. Jasne, użycie frameworka JS zwykle pobiera trochę obciążenia z serwera, ale jest to wyłącznie produkt uboczny , i mówisz, że jest to główny powód. Następnie „Prosta architektura (...) wydaje się lepiej pasować do tego projektu”. Cóż, to dość przesadne stwierdzenie, biorąc pod uwagę, jak mało wiemy o projekcie.
Frax,
2
To znaczy, mówisz, że twoim głównym celem jest „nie wszystko musi być lub powinno być„ bogatą aplikacją js ”. Zgadzam się z tym punktem. Myślę jednak, że twoja odpowiedź nie przekazuje jej poprawnie - byłoby znacznie lepiej, gdybyś ją edytował.
Frax,
1
Nigdy nie słyszałem o odciążaniu procesora do klienta jako powodu do korzystania z JS - powiedziałbym, że historyczny trend używania JS na kliencie sugeruje właśnie to (nie mówię, że (jeden, nadrzędny) powód) i wydaje się rosnąć wykładniczo odkąd jQuery przeciął węzeł gordyjski niezgodności przeglądarki.
radarbob
7

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).

HonoredMule
źródło
5

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.

Mike Robinson
źródło
3

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.

akostadinov
źródło
3

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.

Frax
źródło
2

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.

jasonszhao
źródło
-1

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.

RandomUs1r
źródło