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:

https://devenv.pl/wp-content/uploads/2018/10/97-rzeczy-kt%C3%B3re-ka%C5%BCdy-programista-powinien-wiedzie%C4%87-DEVENV.pdf

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:

:bathtub: Clean Code concepts adapted for PHP
https://github.com/piotrplenik/clean-code-php
2 276 forks.
12 304 stars.
28 open issues.

Recent commits:

 

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.
Tom
Latest posts by Tom (see all)
Tagi: , ,