On 20/01/2019 21:49, Queequeg wrote:
>> Moja obserwacja jest odwrotna. Czasem trzeba poprawiać po domorosłych
>> hackerach.
> Tzn. kod, z którego nie wynika jasno, co autor miał na myśli, bo autor
> myśli, że jest zdolniejszy, niż faktycznie jest i stosuje sztuczki, które
> zaciemniają kod?

Domorośli hackerzy mają tendencję nie do pisania wydajnie, sprytnie itd.
Mają tendencję do pręzenia mięśni intelektualnych *specjalnie* generując
kod który jest upierdliwy albo przy czytaniu albo refaktorowaniu tak aby
każdy widział że ma do czynienia z hackerem. Skutki są oczywiście
odwrotne, każdy widzi że ma do czynienia z pierdołą. To troche jak
wychodzenie na spacer z amstaffem, od razu widać coś zupełnie odwrotnego
niż się imaginuje właścicielowi. Hackerzy nie nadają się do pisania
niczego poza duperelowatym kodem. Ich rozumienie pojęc projektowania,
testowania, abstrakcji itp jest znikome i wręcz alergiczne. Hacker
będzie miał tendencję do wciskania wszędzie zoptymalizowanych wersji i
unikania abstrakcji ignorując fakt że kompilatory zrobią tą
optymalizację za niego a abstrakcji już nie.

Prosty przykład z szarej rzeczywistości programisty: jest sobie pewna
klasa specjalizowana może pięcioma typami. Jeden z nich nie zadziałał
poprawnie (samoczynnie zdejmuje się const w wyniku buga w VS). Domorosły
hacker napisał cztery ekrany elaboratu dlaczego ma rację powołując się
na detaliczne punkty standardu i kilkanaście klas które obchodzą problem
bokiem aby wyszło na jego. Prawidłowe rozwiązanie wymagało pozbycia się
szablonu i dodaniu dwóch linijek dodatkowego kodu którego nie ma i tak w
release bo to był tylko do debugu.

Problem z hackerami polega na tym że mają za duże ego i za wielkie
pojęcie o swoich umiejętnościach oraz nie potrafią pracować w grupie.
Kod z gatunku foo( (*it++) || ++it==end, *it) leci od razu do śmieci jak
tylko go napotkam, śmierdzi na kilometr i jest bez znaczenia czy działa.

> jakości, który działa w sumie tylko przez przypadek (a często nie działa
> wcale i trzeba łatać i obchodzić coś, co nie my zepsuliśmy).

Od tego sa testy.

> Problem jest taki, że dostarczają nam to inne działy, nad którymi nie mamy
> żadnej kontroli.

Nie ma testów, nie ma kodu. Kwestia wyjaśnienia to kierownictwu.