Liczby magiczne potrzebny link

Potrzebuje jakiegoś dobrego artykułu/filmiku czemu nie powinno się używać liczb magicznych w profesjonalnym kodzie.
Mam w zespole takiego jełopa, którego nie jestem w stanie przekonać ani rzeczowymi argumentami, ani demokratycznymi (5:1), więc potrzebny jest "szacowny" link, żeby głąb nie mógł znaleźć kolejne durnej wymówki podczas następnego review.

Ktoś zapodał coś takiego w dziel humor, ale to jest tylko wycinek z wykładów (przeszukałem z 8 wykładów tego gościa, by odleźć ten fragment i na razie bez powodzenia szczególnie, że nie ma spisu treści).

przy następnej stałej zapiszcie ją jako liczbę w programie i postarajcie się żeby tylko wasza piątka wiedziała co ta liczba znaczy
zło złem zwyciężaj

o, chyba trafiłem na interesujący Cię fragment:

Co szef na to?

!*@#%&!@$
Sprawa sie komplikuje.
Nie jestem w stanie przekonać do prostych zasad, a co gorsza szef mnie nie poprał tylko uległ bardziej pyskatemu (gość poleciał do właściciela firny na żale, że się czepiam).
Potrzebuje dobrego linka na tematy:

• magic numbers
• good API (gość walnął konstruktor z 8 argumentami i nie widzi problemu)
• good naming, nazwał enum SharingObject w znaczeniu że coś jest thread safe
• gość nagminnie przeciąża operatory == i !=, nawet w interfejsach

Żadne rzeczowe argumenty nie docierają, wiec potrzebne mi szacowne linki, by nie być wciąganym we flame wars, które gość regularnie rozpętuje (ma jeszcze wsparcie od gościa z innego teamu).

Jak tak dalej pójdzie to trzeba będzie CV porozsyłać, bo nie mam ochoty tracić nerwów.

@MarekR22 "Clean Code"? Zresztą przecież jak puscisz Sonara na takim projekcie to wyświetli ze 2 lata na fixowanie bugów :D

@MarekR22 jesteśmy z Tobą!!!!!!!!!

Wujek Bob. Książki, prezentacje, nagrania, blog.
Albo napisz sam wpis na ten temat, a potem pokaż im ;-)

Generalnie to code review powinno być samo w sobie autorytetem dla niego...

Liczby magiczne:
Poszukałem, nie mam pojęcia czy ten człowiek będzie brał tego autora jako autorytet, ale może?
Bruce Eckel - Thinking in C++ , strona 267 "Podstawianie wartości".

Miałem kiedyś podobny problem, z tym że szef (całe szczęscie) był/jest bardziej ogarnięty. Zrozumiał i naprostował delikwenta rozwiązując umowę. Możesz starać się w jakiś sposób obrzydzać mu życie, ale na dłuższą metę może to okazać się bardzo tragiczne (ale może być całkowicie odwrotnie).

@MarekR22 a tak całkiem serio to jeśli w robocie musisz się o takie rzeczy kłócić i nie ma tam architekta / tech leada / seniorów którzy od razu by cię poparli to siedzisz w jakimś JanuszSofcie i zalecam uciekać i nawet się nie zastanawiać. Serio, siedzenie w takim projekcie ani nie pomoże ci sie rozwijać, ani nie będzie przyjemne. A i tak nikt nie doceni że próbujesz poprawić jakość ;) Nawet sie nie zastanawiaj tylko ślij cv.

@Shalom wiesz co jest zabawne, miesiąc temu zmienił się PM i od niego dostałem tytuł "tech leada".
Dziś na Skype jeden z tych dwóch (od magicznych liczb linii na 200 kolumn itp) marudził że się czepiamy o bzdety. Szczena mi opadła kiedy PM odpowiedział mu w końcu: "Skoro klient nie ma wytycznych co do tych rzeczy to ignorujmy je w CI".
Mam wrażenie, że zostałem Beatą Szydło informatyki (tytuł i odpowiedzialność jest, ale decydować mi nie wolno).

Pracuję w tej firmie już 3 lata, poza jedną nerwową sytuacją z szefem (jednorazowy, ale mocny incydent) było super i poleciłbym firmę.
W obecnym układzie, gdzie widzę, że będę się irytował regularnie, to lepiej może zawczasu zmienić firmę. Zabawne, że z powodu gościa, którego w zasadzie nie widzę na oczy, bo pracuje w innym mieście (może łatwiej się by było z nim dogadać face to face).

Skoro klient nie ma wytycznych co do tych rzeczy to ignorujmy je w CI

Widać że Janusz bez doświadczenia w IT albo idiota. To nie klient będzie ten soft utrzymywał i tracił godziny za łatanie bugów w słabym kodzie.
A tytuł niestety dostałeś w takim razie tylko na papierze. Serio, nie ma sensu tracić czasu. Poza tym 3 lata w jednej firmie to i tak za długo :P

Cały przebieg tego wątku jest bardzo przykry. Nikt nie jest doskonały i wszyscy popełniamy błędy. Nie inaczej było w tym przypadku.

Na pewno niejeden z nas pamięta, jak poczuł się urażony lub zrobiło mu się przykro, gdy jego kod został skrytykowany. Przyjmowanie krytyki jest bardzo trudne, zwłaszcza że, nie ma co ukrywać, podchodzimy emocjonalnie do tego co robimy (kod to coś nad czym ciężko pracowaliśmy, niekiedy po godzinach i jeszcze spędziliśmy trochę czasu, aby to dopieścić). Mimo to, uwielbiamy oceniać innych i wytykać im błędy - nasze ego szybuje coraz wyżej z każdym znalezionym uchybieniem. Ta sprzeczność powoduje konflikty i właśnie w tym miejscu potrzebny jest dobry lider. Dobry, czyli nie tylko taki, który zna doskonale zagadnienia techniczne, ale też taki, który jest w stanie sprawić, aby review nie skupiało się wyłącznie na negatywach i żeby uwagi były przekazywane w odpowiedni sposób. Jeśli wszyscy reviewerzy zaczynają agresywną krytykę, to osobie reviuowanej automatycznie załącza się odruch obronny. Tak pewnie było i w tym przypadku. To lider decyduje o tym jak te spotkania wyglądają. Nawet jeśli było wiele błędów, to można dać na koniec feedback, że mimo tego, że trochę rzeczy jest do poprawy, to całość była bardzo fajna albo że zastosowanie czegoś było pomysłowe. Jeśli się tego nie zrobi, to wówczas ten ktoś wraca do biurka przybity i pełen negatywnych emocji. Taki jeden komentarz na koniec może całkowicie zmienić odbiór całego review.

A teraz przeanalizujmy co się stało. 5 osób rzuciło się na jedną. Pokłócili się o definy (czy uwagi były słuszne czy nie - nie oceniam, nie zawsze opinia większości jest słuszna). Wszyscy zdenerwowani. Przykro mi, że to powiem, ale to Twoja porażka (ale i cenna nauka na przyszłość!). Pozwoliłeś, by błahostka doprowadziła do konfliktu w zespole. Powinieneś być pierwszym, który załagodzi sytuację. Pozwoliłeś, by problem był eskalowany powyżej. Czy project managera albo właściciela firmy obchodzą takie szczegóły jak używanie magic numberów? Nazywania swojego podopiecznego "głąbem" nawet nie skomentuję. Zwalnianie się z tego powodu też będzie porażką i będzie dowodem tego, że jednak pozycja lidera została Ci przyznana niesłusznie. Przekonywanie kogoś na siłę do swoich racji też uważam bez sensu. U niego teraz działa mechanizm obronny.

Co oprócz powyższych rad można zrobić, aby ustrzec się takich sytuacji w przyszłości?

1. Napisać wspólnie coding standard - Wasz własny, którego będziecie się trzymać. Wtedy jeśli argumenty rzeczowe nie działają i ktoś jest mocno oporny, to można mu powiedzieć, że Wasz coding standard tak przewiduje.

2. Podsumowując spotkanie powiedzieć, że oczekujesz, że wspólnie ustalone zmiany zostaną zastosowane. Jeśli jest opór, to mówisz wprost, że nie zezwalasz na wrzucanie tych zmian, ponieważ review jest odrzucone. Jednak to ostateczność i jeśli zadbasz o odpowiednią atmosferę, to nie powinieneś mieć tego problemu.

Co proponuję Tobie zrobić w sytuacji, w której się znalazłeś?

1. Porozmawiać 1:1 z tym developerem, że być może obaj popełniliście błędy (jeśli oczywiście po tym, co napisałem też tak czujesz) i warto zacząć od nowa. Jak atmosfera się rozluźni zaproponuj jakieś spotkanie 1:1 lub z całym zespołem o tych magic numberach, jednak uprzedź resztę zespołu, jaki charakter ma mieć to spotkanie.

2. Porozmawiać 1:1 z managerem / właścicielem, który podważył twoją decyzję, aby tego więcej nie robił. Tylko uprzedzam, że powinno to być zrobione na spokojnie, żeby nie było kolejnego konfliktu.

3. Na pewno nie próbować się mścić. Co było, minęło i trzeba żyć dalej. Najlepiej w dobrej atmosferze. Sukcesy Twoich podopiecznych to Twoje sukcesy.