Podążasz ścieżką tego, co wiem, a następnie spróbuj wdrożyć prawidłowe praktyki kodowania lub zacząć od dobrych praktyk kodowania i próbować kroczyć moją drogą?

Po pierwsze, chcę powiedzieć, że jestem przyzwyczajony do programowania proceduralnego jako hobby - staram się uczyć OOP w kilku językach i rozumiem teorię , a nie praktykę.

Mam projekt zwierzaka, który chciałem zbudować, szczególnie w PHP z zapleczem bazy danych (nie obchodziło mnie co). Moim głównym powodem było użycie aplikacji na dowolnym urządzeniu, więc WebApp wydawał się logicznym wyborem.

Rozumiem, że do budowania łatwych w utrzymaniu PHP aplikacji internetowych powinno używać OOP, klas, frameworków, bibliotek itp. Brzmi to logicznie, więc postanowiłem wypróbować niektóre z popularnych. Jednak po całym weekendzie po prostu próbowania ich i przechodzenia przez samouczki, jestem zdezorientowany i sfrustrowany próbą dostosowania samouczków do mojego małego projektu.

Postanowiłem, głównie w celu weryfikacji koncepcji, zbudować aplikację w innym programie (Microsoft Access) i osiągnąłem moje główne cele w ciągu zaledwie kilku godzin - z wyjątkiem części Web Part.

Moje pytanie brzmi: czy powinienem podążać ścieżką tego, co wiem, a następnie spróbować wdrożyć poprawne praktyki kodowania, czy też powinienem zacząć od dobrych praktyk kodowania i spróbować przejść przez moją drogę? W przypadku tego projektu chciałbym, aby był on Open Sourced na GitHub, więc byłbym otwarty na inne osoby używające i zmieniające mój kod, ale wiem również, że jeśli kod zostanie napisany źle, trudno będzie zebrać kodery, które pomogą.

Najlepsze praktyki to głównie sugestie i propozycje zebrane z doświadczenia, aby ułatwić * realizację projektów.

Kluczowymi aspektami tego IMHO jest część dotycząca doświadczenia. Chociaż te najlepsze praktyki są dobrym sposobem dla osób z większym doświadczeniem, aby dzielić się nimi z początkującymi, myślę, że nadal potrzebny jest minimalny poziom doświadczenia, aby naprawdę zrozumieć, co sprawia, że ​​jest to najlepsza praktyka. Postępowanie w inny sposób sprowadza się do ślepego ich przestrzegania jako zasady prawa, która, jak sądzę, spowolni waszą naukę, gdy powoli pozwalacie innym myśleć za was.

W każdym razie absolutnie najważniejszą rzeczą, jaką należy zrobić w projekcie oprogramowania jest dla mnie ... no cóż ... dokończ go, wyślij ... krótko mówiąc, spraw, by działał!

Wszystko przed tym punktem jest vaporware, wymysłem twojej wyobraźni. Tylko wtedy, gdy masz coś, co działa, możesz naprawdę ocenić, czy jest to powolne, trudne w utrzymaniu, trudne do przetestowania itp. Proces uruchamiania go ujawni rzeczy, dla których być może istnieje najlepsza praktyka, która pomogłaby Ci przemyśleć w sposób, który ułatwia osiągnięcie tego celu.

Więc tak, zacznij od tego, co wiesz najpierw, zwróć uwagę na rzeczy, które robisz, które są trudne. Kiedy uderzysz o ścianę, cofnij się o krok i spójrz na tę ścianę, dowiedz się, z czego jest wykonana. W bardzo wielu przypadkach zdasz sobie sprawę, że TY jesteś źródłem problemu. Twój brak zrozumienia części problemu, który próbujesz rozwiązać, brak wiedzy na temat tego, w jaki sposób możesz lepiej wykorzystać posiadane narzędzia lub ignorowanie innych narzędzi, które są cały czas pod twoim nosem, ale nie były gotowe rozpocząć ich opanowanie.

Jednocześnie czytaj dalej o nowych sposobach robienia rzeczy. Zapoznaj się z tymi najlepszymi praktykami i spróbuj sprawdzić, czy odnoszą się one do czegoś, co jest dla ciebie trudne w projekcie. Jeśli nie, pamiętaj o ich istnieniu i odwiedzaj je od czasu do czasu. Pozostań ciekawy. Z czasem przekonasz się, że powyższe obserwacje po prostu klikają naturalnie, zdobywając wiedzę tutaj.

Na koniec eksperymentuj z tym, czego się nauczyłeś i sprawdź, czy to upraszcza sprawę. trzymaj się tego, a ostatecznie zapoznasz się z najlepszymi praktykami takimi, jakie są. Po prostu prosta rada od osób, które ucierpiały i nauczyły się, jak to ułatwić. Heck, możesz nawet nie zgodzić się z niektórymi z nich i przekonać się, że twoja droga faktycznie działa lepiej dla Ciebie. Ale bez wiedzy po prostu chodzicie ślepi.

powodzenia

TL; DR

Nigdy nie poznasz tego wszystkiego. Prawie zawsze jest więcej głębi i szerokości wokół każdej „rzeczy”, którą możesz znać. Ucz się na bieżąco. Zastosuj „najlepsze praktyki”, które Twoim zdaniem są teraz istotne . Robić błędy. Staraj się tylko unikać naprawdę kosztownych błędów. Znajdź mentorów, jeśli Twój projekt może prowadzić do kosztownych błędów.

A teraz długa odpowiedź ...

1. „Działające oprogramowanie jest podstawową miarą postępu”. ( Manifest zwinny )

Jeśli widzisz granice swojej wiedzy, to niesamowite! Dąż do krawędzi! Ucz się! Pamiętaj jednak, że możesz uczyć się i analizować na zawsze .

Zbuduj coś.

2. Naucz się i popełniaj błędy; ale nie rób „złych”. *

Przekraczaj granice swojej wiedzy / umiejętności. Ci będą popełniać błędy. Możesz się od nich uczyć. Ale nie musisz być lekkomyślny .

Czas spędzony na poszukiwaniu i pracy z bardziej doświadczonymi programistami i mentorami powinien wzrosnąć proporcjonalnie do wartości biznesowej i profilu ryzyka projektu.

Jeśli tworzysz mały CLI dla siebie : działaj tak, jak chcesz.

Jeśli piszesz portal internetowy banku: Otocz się bardzo doświadczonymi programistami.

3. „Najlepsze praktyki” powinny być pisane w cudzysłowie i mrugać.

„Praktyki” są promowane jako „najlepsze praktyki”, gdy zaobserwuje się, że osiągają X przynajmniej w niektórych przypadkach. Ktoś uznaje korzyść z praktyki A dla osiągnięcia korzyści X i deklaruje, że jest to „najlepsza praktyka” w Internecie. Inni się zgadzają - często z ważnego powodu. Ale od tego momentu na ogół tracimy z oczu, dlaczego niektóre praktyki są „najlepszymi praktykami”, a inne „antypatternami” lub „śmierdzącymi”.

Problem polega na tym, że „najlepsza praktyka” nigdy nie jest samolubna. „Antypatterny” same w sobie nie są diabelskie. I nawet „smród” tylko czasami pochodzi od zgnilizny. Czasami ten smród to tylko wymyślny, pyszny ser ...

Nie ćwiczysz takich rzeczy jak „wstrzykiwanie zależności”, ponieważ „zastrzyk zależności” jest z natury wartościowy dla firmy. Nie jest nawet zdalnie niezbędny do zbudowania działającego produktu. Osiąga coś , czego możesz chcieć w swoim produkcie końcowym. Ale może to również spowodować, że Twoja praca potrwa dłużej bez żadnych korzyści ...

Hmm ...

Czy zatem powinieneś stosować „najlepsze praktyki”? Nawet jeśli ich nie rozumiesz? ... Err ... tak. Myślę że nie. Ale tak. Ale tylko te, które naprawdę dotyczą Ciebie i Twojego oprogramowania oraz jego celu.

Wywołaj POAP ! ^{(Tak. Mój blog.)}

Zasady, wzorce i praktyki nie są ostatecznymi celami.

Dobre i właściwe stosowanie każdego z nich jest zatem inspirowane i ograniczane przez nadrzędny, bardziej ostateczny cel. Musisz zrozumieć, dlaczego robisz to, co robisz!

(POAP nie jest zwolniony z POAP.)

Na przykład możesz nie do końca zrozumieć każdy niuans DI. Ale jeśli zrozumiesz intencję, będziesz wiedział, czy „powinieneś” użyć DI, i w pewnym sensie lepiej zrozumiesz DI.

Po wydaniu produktu możesz zastanowić się, czy DI (lub cokolwiek innego) był naprawdę korzystny. Jeśli tak, to proszę uzasadnić na piśmie. Jeśli nie, należy podać dlaczego na piśmie ...

Czytanie bonusów / Trochę istotne:

Paraliż analizy jest rzeczą. Musisz analizować i uczyć się; ale musisz też załatwić sprawę. Saldo.

Zawsze możesz poczuć się jak kowbojski programista .

^{* Ty faktycznie będzie robić złe błędów, jeśli nie nic godne uwagi. Ale zakładam, że jesteś człowiekiem. Więc wybaczamy ci z wyprzedzeniem ... A przynajmniej tak robię. Może. ... Cóż ... Zobaczymy.}

Moje pytanie brzmi: czy powinienem podążać ścieżką tego, co wiem, a następnie spróbować wdrożyć poprawne praktyki kodowania, czy też powinienem zacząć od dobrych praktyk kodowania i spróbować przejść przez moją drogę?

Może postaraj się jak najlepiej, ale nadal coś wysyłaj? Istnieją dwie różne siły między tym, jak użytkownicy oceniają jakość i atrakcyjność produktu, a tym, jak programiści za nim oceniają jakość kodu. Staraj się, aby te dwie siły były jak najbardziej harmonijne. Koncentrowanie się na jednym za dużo kosztem drugiego jest zwykle sposobem, w jaki uzyskuje się najbardziej nieproduktywne trasy.

Przede wszystkim sugerowałbym, że stosowanie dobrych praktyk kodowania nie jest marnowaniem ... Sztuką jest zrozumienie celu każdej praktyki i tego, jak właściwie ją wdrożyć.

Środowiska szybkiego tworzenia aplikacji są uwodzicielskie, ponieważ w bardzo krótkim czasie można wiele zrobić. Raz zbudowałem cały system księgowy w Access. Ale sam to powiedziałeś: nie możesz przenieść takiej aplikacji do Internetu bez przepisywania, a narzędzia, których potrzebujesz, są naprawdę różne.

Istnieją powody, dla których nikt już nie używa narzędzi do projektowania wizualnego, takich jak Access lub Visual Basic. Mają tendencję do izolowania cię od kodu, który naprawdę coś osiąga. Dostęp jest dobrym narzędziem, ale wymaga tego, aby aplikacje internetowe zostały zaprojektowane specjalnie w celu uniknięcia: instalacji. Dostosowanie jego wyglądu może być trudne; nawet jeśli nie potrzebujesz go w Internecie, aplikacja Access zawsze będzie wyglądać bardzo podobnie jak każda inna aplikacja Access. Większość osób, które piszą swoją pierwszą aplikację Access, nie wie wystarczająco dużo, aby napisać dobrą aplikację, a Access ułatwia napisanie złej.

Więc teraz zrezygnowałeś z nauki nowej technologii, aby uzyskać aplikację w Internecie. Czy powinieneś zbudować go od samego początku? Oczywiście. Ale uczenie się nowego środowiska programistycznego i filozofii jest jak uczenie się jakiejkolwiek innej rzeczy; musisz na jakiś czas go spowolnić, aby wszystko było w porządku.

Dlatego myślę, że podałeś fałszywą dychotomię. Najpierw nikt nie uczy się wszystkich „najlepszych praktyk”. Uczą się ich na bieżąco. Ale żeby być produktywnym w dowolnym języku OOP, myślę, że musisz znać trochę OOP, a przynajmniej jak zasadniczo działają klasy.

Jeśli chodzi o wartość, nie sądzę, że PHP jest najlepszym wyborem. PHP jest atrakcyjny, ponieważ jest „płytki”, co oznacza, że ​​nie musisz dużo wiedzieć, aby napisać działający program. Najlepsze praktyki są w dużej mierze zależne od programisty, co oznacza, że ​​PHP nie pomoże ci pisać „dobrych” programów. Nie jest to konieczne złe, ale oznacza to, że podobnie jak Access, możesz także porzucić PHP na bardziej niezawodną platformę.

Traktuj OOP jako kolejny wzór, który możesz zastosować we właściwym czasie. OOP nie jest strukturą, która może metodycznie rozwiązać każde zadanie. Takiej rzeczy nie ma w inżynierii oprogramowania.

Zauważ również, że to, co ludzie twierdzą, że są dobrymi praktykami, jest czasem wątpliwe. Często widziałem niedoświadczonych programistów, którzy przyjmują bardzo skomplikowane wzorce programowe, które nie były konieczne dla danego problemu. Złożoność kodu powinna być odpowiednia do złożoności problemu. Prostota jest ważną wartością.

Artykuły w Internecie, wypowiedzi ekspertów branżowych i porady starszych współpracowników mogą się mylić. Często to widziałem.

Dlatego zalecam zastosowanie najprostszego rozwiązania, które rozwiązuje problem. Prawdopodobnie obejmie to użycie jednego z popularnych frameworków w twojej przestrzeni. W ramach tego ograniczenia możesz swobodnie wybierać, jaki rodzaj kodu lubisz. Nie myśl po prostu, że ich sposób na zrobienie tego jest odpowiedni dla twojej sprawy.

Ponadto zrozum, dlaczego niektóre techniki są zalecane. Na przykład OOP dotyczy enkapsulacji. Możesz enkapsulować na inne sposoby (procedury dotyczą także enkapsulacji).

Negatywny przykład: czasami ludzie piszą warstwę dostępu do danych, aby wyodrębnić bazę danych. Istotą tego wzorca jest uniezależnienie się od konkretnego magazynu danych i udostępnienie prostszego interfejsu wyższym warstwom kodu. Ale jeśli nie potrzebujesz tych korzyści, nie potrzebujesz warstwy dostępu do danych i możesz zaoszczędzić pracę. Jednak wielu ekspertów zaleca zawsze stosowanie DAL, co jest niewłaściwym zaleceniem.

Uważam, że dobry kod często sprawia przyjemność w pracy. To zabawne, ponieważ możesz zająć się rzeczywistymi wymaganiami zamiast zajmować się problemami z infrastrukturą. Jeśli okaże się, że to, co robisz, to zbyt dużo chrząkania, prawdopodobnie wybrałeś niewłaściwy zestaw wzorców.