Inżynieria oprogramowania, Jak wykonać
Pisarz, artysta, poeta i dobre rady oraz wzorce
W dzisiejszym świecie szukamy dobrych i sprawdzonych rozwiązań.
Szukamy wzorców , schematów, modeli do zwiększenia jakości i przejrzystości.
Piszemy własne manifesty i zasady, staramy się je wdrażać, pielęgnować i pilnować ich przestrzegania…
i wszystko jak grochem o ścianę?
Gdzie warto i jak warto wprowadzać te zasady?
Przykładowa lista zasad:
np:
Programiści uwielbiają pisać kod, ale nie lubią go czytać.
– Czytanie kodu bywa trudne, szczególnie cudzego. Następnym razem gdy będziesz czytać czyjś kod
postaraj się z tego coś wyciągnąć i czegoś się nauczyć. Jeśli jest nieczytelny lub źle skonstruowany
zadaj sobie pytanie dlaczego, odpowiedz na nie i nie popełniaj cudzych błędów.
Tutaj kolejne zasady dotyczące samego pisania kodu:
Moim zdaniem warto zasatanowić się szerzej nad tym nie jak coś robimy, ale po co to robimy, bo to zawsze pierwsze pytanie, gdy się do czegoś zabieramy.
Robimy coś aby sprawić sobie, czy komuś przyjemność?
Jeśli poeta-pisarz, tworzy utwór to z pewnością robi to dla własnej przyjemności, aby wylać z siebie te potoki i rzeki poezji, które zalegają jego serce.
Czy programista aż tak się różni od poety?
Czy warto stosować te nakazy i zakazy, aby każdy pisarz i potea pisał tak samo?
Czy nie lepiej zwyczajnie zamknąć każdy tomik poezji w ramach twardego API, które będzie przekazywało informacje?
Czy koniecznie trzeba wchodzić w detale analizy kodu?
A co jeśli to co zostało kiedyś napisane już nam nie odpowieda i nie pasuje?
Czy lepiej refaktoryzować czy lepiej pisać nowe?
Tu istotne jest to jak wielki obszar i co konkretnie wymaga zmiany.
Modułowa architektura pomaga i wówczas czas napisania nie gra takiej roli bo można zwyczajnie napisać od nowa dalszą cześć tego poeamatu.
Doświadczenie
Moje doświadczenia podpowiadają mi, że lepiej tworzyć nowe, bo to jest łatwiejsze i szybsze.
Tym bardziej, że każde oprogramowanie można zamknąć w API.
Każdy ma własny styl, więc po co każdemu narzucać i pisać wedle konkretnych zasad, jeśli jest inna droga, w której aby się porozumieć wystarczy specyfikacja API, chociażby napisana za pomocą swagger.
The Basics
moje zasady to pisanie kodu:
- readable – łatwego do czytania, chodzi o forme, zeby bylo duzo akapitów, czyli funkcji i małe rozdziały, czyli klas
- understable – zrozumiałego w odniesieniu do samego kodu, pisać nazwy zmiennych i funkcji w sposob klarowny, jeśli nazwa jest długa to nie jest to bład, a wręcz pożądane
- manageable, replaceable – zarządzalne, wymianialne, czyli modułowa konstrukcja, łatwa to zastąpienia struktura i architektura, tak by łatwo wymienić poszczególne klasy i biblioteki, itp.
Moim pierwszym (mikro)komputerem był ZX-Spectrum a językiem programowania: Basic.
Od 2010 roku programuję zawodowo, objektowo i funkcjonalnie w architekturach monolitycznych i mikro-usługowych.
Obecnie tworzę architekturę ekosystemów dla liderów rynku w firmie Softreck.
- Prototypy, MVP, eksperymenty… SaaS - 12 stycznia 2024
- Dzięki jakiej technologii aktualnie można zostać uznanym za cudotwórcę, za proroka, osobę o nadprzyrodzonych zdolnościach? - 12 października 2023
- SaaS dla MaaS - 10 września 2023
