🚀 go-pugleaf

On Wednesday, January 29, 2020 at 2:30:48 PM UTC+1, Mateusz Viste wrote:
> 2020-01-29 o 04:58 -0800, M.M. napisał:
> > (różne mądre rzeczy)
> 
> Bardzo ładnie wypunktowałeś sprawę, i ze wszystkim się zgadzam. Dodam
> tylko jeden aspekt, który przeoczyłeś - a który może być bardzo istotny
> w ramach pracy zespołowej.

Dziękuję.

 
> > 2) W C++ mamy praktycznie to samo co w C, plus wiele dodatkowych
> > rzeczy. Więc jakby nawet się uprzeć, to w C++ można programować tak
> > jak w C jeśliby te dodatkowe cechy nic nie wnosiły.
> 
> Zdarzało mi się widzieć projekty napisane w C - jak Pan Bóg przykazał.
> Później ktoś powiedział "no tak, C jest fajne, ale może kompilujmy go
> jako C++, ale dalej pisząc C". No i git, whatever.

No tak, czemu nie. Jest kilka wyjątków. W C++ jest jedna przestrzeń nazw
dla typów i zmiennych, a w C są dwie, bo kompilator rozpoznaje po obowiązkowym
słowie kluczowym struct że chodzi o typ a nie o zmienną. Podobnie sprawa
ma się ze słowem kluczowym class, w C można było tak nazwać zmienną, a C++
już tego nie skompiluje. C też łagodniej podochodzi do konwersji typów...
ale jeśli było pisane PO BOŻEMU, to przejście na kompilator C++ może
być nawet bez żadnej poprawki.


> Później ktoś (inny) powiedział "a może rozluźnijmy trochę portki i
> skorzystajmy z 'new'? To będzie takie 'C z new', tu i ówdzie usprawni
> pisanie tego i owego, czysty zysk!". No i w sumie - czemu nie.

No tak, czemu nie? New samo rzutuje na odpowiedni typ i zna rozmiary typów w
przeciwieństwie do malloc. Ale czy realloc współpracuje z new i delete to
nie wiem, myślę że nie.


> Jak łatwo się domyśleć, potem było już z górki. Każdy dodawał coś od
> siebie i projekt który początkowo był składny i konsekwentny, z czasem
> przeistoczył się w potworka, gdzie ten sam problem rozwiązuje się na
> kilka różnych sposobów w zależności od tego w jakim czasie i przez kogo
> został napisany.

Trudno jest mi się ustosunkować w krótkiej wypowiedzi.

W jednym ze swoich projektów wydzieliłem pewne specyficzne pojęcie modułu. 
Moduł był pewnym szablonem, zestawem klas i metod wirtualnych. Gdy programista
próbował pisać niezgodnie z szablonem, to się nie uruchomiło. Ale swoje
pliki, metody i klasy mógł dodawać jak lubi, byle minimalnie przejrzyście.
W zamian za lekki bałagan każdy miał trochę wolności i projekt moim zdaniem
szybciej się rozwijał. Gdy poprawka jakiegoś moduł stawała się bardzo trudna, to
bezboleśnie dla całego projektu można było wywalić tylko jeden moduł - ale 
takie ryzyko było małe.

> > potocznie zazwyczaj ma się na myśli programowanie w C++ pełną gębą.
> 
> Do tego to niechybnie zmierza. Jeśli robi to jedna osoba która
> dokładnie wie co robi i trzyma się jakichś ustalonych zasad, to nie ma
> problemu. 
> Gorzej, kiedy mamy do czynienie z większym zespołem, w którym
> znajomość C++ i jego wszelakich uaktualnień oraz najrozmaitszych
> rozszerzeń jest bardzo niejednolita. Ktoś powie, że to wirtualny
> problem, bo od tego jest PM lub wzorce projektowe, żeby takie rzeczy
> uściślać i egzekwować...      a życie życiem.

No więc właśnie, bałagan bałaganowi nierówny. Bałagan globalny źle wróży
kolejnej rozbudowie projektu, bałagan lokalny oznacza tylko trochę większy
nakład pracy w zamian za to że kiedyś trochę czasu zaoszczędziliśmy na
porządkowaniu kodu. Poza tym komentarze rekompensują bałagan. Bałagan ma
też swoje zalety. Szybciej dostarczamy cokolwiek co działa. Gdy porządkujemy, 
to mamy okazję jak ulał do testów regresywnych. Osobiście zostawiam wersję
bałaganiarską, nie kasuję jej, ale używam potem do porównania czy daje takie
same wyniki jak wersja uporządkowana. Gdy jest konieczność optymalizacji, to
mam wersję trzecią kodu który robi to samo i w testach mogę porównywać wyniki
trzech procedur.

Ale odpisuję po łebkach na pewno popełniając wiele niedomówień. Rozwijanie 
aplikacji to ogromny temat. Zwykle mamy zestaw wytycznych:
w1, w2, wN

Zestaw prawdopodobnych kierunków rozwoju aplikacji:
z1, z2, zM

i ich prawdopodobieństw
p1, p2, pM

I możliwe technologie w którym rozwiążemy dane zadanie:
r1, r2, rK

Przy użyciu danej technologii znamy tylko przybliżony koszt: 
k1 = r1(w1,w2,wN,z1*p1,z2*p2,zM*pM)

Do tego koszt jest kosztem wielokryterialnym, dla jednego czas wykonania
jest liniowy i jeden dzień oczekiwania na produkt to 200zł, dla drugiego
dzień oczekiwania na ten sam produkt to 1000zł, dla innego oczekiwanie
powyżej pewnej ilości dni oznacza podniesienie dotychczasowych kosztów razy
dziesięć bo ma karę, a inny zatrudnia 200% nadmiarowych programistów bo
od jednego produktu będzie zależał kontrakt na 100 kolejnych zamówień...

Jak w obliczu tylu niepewności można się merytorycznie spierać o to, czy 
dalsze upiększanie kodu, szukanie lepszych bibliotek, przejście na inny 
język programowania, kolejna refaktoryzacja, 
spowoduje że ki < min( k1, k2, k{i-1} )
?

Pisanie jednej procedury to inżynieria, ale pisanie całego systemu to w
dużej mierze sztuka i intuicja. 


Pozdrawiam