Jak radzić sobie z „prawie dobrym” kodem od młodszego programisty? [Zamknięte]

95

Mam pytanie dotyczące zarządzania zespołem. Obecnie mam do czynienia z młodszym programistą, który pracuje zdalnie z fabryki kodowania. Facet jest otwarty na krytykę i chętny do nauki, ale mam wątpliwości, jak bardzo powinienem popychać różne rzeczy.

Właśnie teraz, gdy coś jest proste i oczywiste, stanowi naruszenie dobrych praktyk: jak naruszenie SRP, obiektów Boga, nieistotnych nazw metod lub zmiennych; Wskazuję, co musi naprawić, i próbuję wyjaśnić, dlaczego to jest złe.

Moje pytanie brzmi: kiedy przestać? W tej chwili, jeśli wystąpią drobne naruszenia stylu kodowania, takie jak nazwy zmiennych w niewłaściwym języku (poprzedni zespół mieszał hiszpański i angielski i staram się to naprawić), lub drobne problemy strukturalne, pozwalam odejść i naprawić, jeśli Mam wolny czas lub potrzebuję zmodyfikować problematyczną klasę. Wydaje mi się, że jest to dobre dla morale zespołu, więc nie wypycham ciągle kodu, co dla nowicjusza może wydawać się drobnymi szczegółami, co może być dość frustrujące, ale martwię się również, że zbyt „miękki” może powstrzymać faceta od nauki, jak robić różne rzeczy.

Jak zrównoważyć granicę między nauczaniem faceta a nie wypalaniem go ciągłą krytyką? Dla młodszego może być frustrujące, jeśli powiesz mu, żeby powtórzył rzeczy, które działają na jego oczy.

Zalomon
źródło
7
Ile czasu spędziłeś upewniając się, że wie, jakie są twoje oczekiwania?
Blrfl
13
@gnat Myślę, że to nie to samo, mój problem nie polega na tym, że przekraczamy szacunki lub przesadzamy kod. Faktem jest, że jesteśmy przed czasem. Moje pytanie brzmi: jak zrównoważyć granicę między nauczaniem faceta a nie wypalaniem go ciągłą krytyką, dla młodszego może to być frustrujące, jeśli powiesz mu, żeby przerobił rzeczy, które działają na jego oczy.
Zalomon
4
Zredagowałem to, aby było bardziej na temat. Uważam, że jest to również inne niż powiązane duplikat pytania.
enderland
3
Pomogły mi w tym niektóre rzeczy: programowanie parami - uzyskaj wgląd w to, jak on działa i myśli, a może narażaj go na procesy myślowe podczas przeglądania kodu. Znajdź zadania, w których jest dobry - czasem uzyskasz lepsze wyniki, rzucając na niego garść drobnych błędów w porównaniu do pracy nad dużymi funkcjami. Projekty techniczne - daj mu pierwsze doświadczenie w projektowaniu oprogramowania bez dotykania kodu. To pozwala mu zastanowić się nad strukturą i procesem, a nie odłożyć głowę i wyrzucić kod. Na koniec powodzenia. Czasami wymaga więcej wytrwałości, niż się spodziewano, ale jest tego wart, jeśli staje się produktywny.
Sandy Chapman,

Odpowiedzi:

84

Jeśli uważasz, że kod powinien zostać naprawiony przed scaleniem, zrób komentarz. Najlepiej z „dlaczego”, aby twórca mógł się uczyć.

Pamiętaj, że kod jest odczytywany znacznie częściej niż pisany. Rzeczy, które wydają się „niewielkie”, mogą być naprawdę ważne (na przykład nazwy zmiennych).

Jeśli jednak robisz komentarze, które wydają się nużące, może zastanów się:

  • Czy Twój proces CI powinien je złapać?
  • Czy masz czytelny „przewodnik dla programistów”, do którego możesz się odwoływać (czy też wszystko jest udokumentowane w twojej głowie)?
  • Czy te komentarze rzeczywiście wpływają na jakość kodu?

Wiele osób poświęca produktywność na ołtarzu procesu lub doskonałości. Uważaj, aby tego nie zrobić.

Jeśli to możliwe, spróbuj osobiście odwiedzić kolegę. Lub użyj połączeń wideo. Budowanie relacji ułatwia zarządzanie krytyką (nawet recenzjami kodu).

Jeśli okaże się, że w kodzie występuje zbyt wiele błędów w przód / w tył, poproś o przejrzenie mniejszych fragmentów kodu. Zmiany przyrostowe prawdopodobnie unikną niektórych bardziej znaczących problemów projektowych, ponieważ są z definicji mniejsze.

Ale absolutnie nie łącz rzeczy, a następnie wróć i napraw je. Jest to pasywnie agresywne i jeśli deweloper stwierdzi, że to robisz, zabijesz ich morale.

kraina krańca
źródło
65
@ 9000 to niesamowite, jak często ludzie są sfrustrowani
faktem,
32
Nazwy zmiennych są niezwykle ważne przy opisywaniu zamiaru kodu; nazwy metod / funkcji, tym bardziej. Poprawne nazewnictwo nie jest bezużytecznym perfekcjonizmem, jest wymagane do utrzymania.
9000
9
@Zalomon Zdecydowanie wspomnij mu o tym; więcej, zmień to w dyskusję. Jako młodszy programista pracowałem z kilkoma różnymi starszymi programistami. Moim najlepszym doświadczeniem był programista, który omawiał wszystkie moje rekomendacje - nawet te „małe”, jak nieco lepsza nazwa zmiennej. Nie tylko nauczyłem się od niego tony, ale czułem się tak dobrze, że wsłuchiwał się w moje procesy myślowe i włączał mnie do dyskusji - sprawiło, że chciałem, żeby jeszcze bardziej przejrzał mój kod, abym mógł dowiedzieć się więcej. (ciąg dalszy)
dj18
6
@Zalomon (ciąg dalszy) Z drugiej strony, starszy programista, który dokonał zmian za moimi plecami (nawet jeśli powiesz mu później, że wciąż jest za jego plecami), był całkowicie demoralizujący - czułem się, jakbym pracował z autokratą, którego ja musiał wymyślić, jak się zadowolić.
dj18
6
Moje (małe) doświadczenie w mentorowaniu młodszych programistów pokazuje, że warto poświęcić chwilę deweloperowi na przemyślenie właściwej nazwy i wyrażenie celu danych w nazwie zmiennej. Pomaga deweloperowi zrozumieć, co robi ich kod, w znacznie mniej falujący sposób niż są przyzwyczajeni. Czasami prowadzi ich do znalezienia logicznych błędów w zaangażowanym kodzie lub po prostu lepszych sposobów wyrażania rzeczy. (To samo działa dla mnie; różnica polega na tym, że dyscyplina została zinternalizowana dzięki ścisłym recenzentom kodu, które miałem w przeszłości.)
9000
19

Trzymaj krytykę kodu, a nie pisarza.

Każda wyprodukowana praca wiąże się z nieodłącznym przywiązaniem emocjonalnym. Zastanów się, jak to złagodzić, odsuwając kod od autora tak bardzo, jak to możliwe. Jakość kodu powinna być konsekwentnie ustalana jako wspólny cel, przed którym oboje stoicie razem, a nie jako punkt tarcia między wami.

Jednym ze sposobów osiągnięcia tego jest mądry wybór słów. Chociaż osoby ze STEM lubią uważać się za wysoce logiczne, emocje są częścią ludzkiej natury. Używany zwrot może być różnicą między zranionymi lub oszczędzonymi uczuciami. Powiedzenie „Ta nazwa funkcji byłaby bardziej spójna z konwencjami, gdyby była w języku angielskim”, jest lepsza niż „Napisałeś tę nazwę funkcji niepoprawnie i powinna być w języku angielskim”. Podczas gdy ten drugi jest nadal oswojony i sam wydaje się w porządku, w porównaniu do tego pierwszego jego wady stają się oczywiste - przygotowując, co powiedzieć albo osobiście, albo przez e-mail, sprawdź, czy twój kontekst, słowa i skupienie są na kwestiach, a nie osoba .

Język ciała

Chociaż słowa są ważne, większość komunikacji jest niewerbalna. Zwróć uwagę na mowę ciała, nawet pozornie nieznaczne subtelności, takie jak orientacja, np. Wiele interakcji między seniorami i młodszymi ma miejsce twarzą w twarz, ale podejście równoległe byłoby znacznie bardziej sprzyjające twojemu pożądanemu wynikowi.

Przekaż szczere pozytywne opinie

Wiele badań pokazuje, że informacje są przyswajane szybciej i lepiej przechowywane, gdy nagradzamy dobre zachowanie, a nie karanie złych. Czasami po prostu zauważam, że wydajność została poprawiona przez prostą „dobrą robotę” lub bardziej konkretną „Zauważyłem ostatnio, że twój styl dopasowuje nasze standardy do koszulki, świetna robota!” nawet uzupełnienie tego uznania za ulepszenie poprzez ich doradzenie komuś innemu w kwestiach, które poprawili, może mieć znaczenie dla twojego młodszego twórcy i jego pracy.

Legato
źródło
2
W kwestii werbalnej: kiedy musisz użyć zaimka osobistego, po prostu wybranie „my” zamiast „ty” również depersonalizuje krytykę, z mojego doświadczenia po obu stronach przeglądu kodu.
Josh Caswell
6

Facet jest otwarty na krytykę i chętny do nauki, ale mam wątpliwości, jak bardzo powinienem popychać różne rzeczy.

Wciśnij wszystko, co możesz. Jeśli facet się uczy, a Twoim zadaniem jest przejrzeć jego kod, oboje możesz wiele zyskać, jeśli wykona dobrą robotę.

Będzie to oznaczać mniej kodu do przejrzenia w przyszłości i może dać zespołowi docelowy poziom zatrudnienia.

Ponadto, jeśli powstrzymujesz się, nie pomagasz, ale protekcjonalnie.

Już sam fakt, że opublikowałeś tutaj swoje pytanie, pytając, czy robisz za dużo, już mnie sygnalizuje, że nie potrzebujesz tej konkretnej porady, ale dla innych, oto nadchodzi: pamiętaj, że naciskanie nie oznacza być palantem.

Bycie mentorem nie jest łatwym zadaniem. Będziesz także musiał dać mu trochę miejsca na samodzielne popełnianie błędów i poprawianie ich, po prostu upewnij się, że zrobi to w miejscu, które nie spowoduje prawdziwych obrażeń.

Machado
źródło
5

Opierając się na twoim opisie, zostawiłbym to w następujący sposób: „to dobrze. Jest kilka rzeczy, które zrobiłbym inaczej, ale nie są one bardzo ważne”.

Jak zdajesz się rozumieć, krytyka ma swoją cenę, a jeśli spędzasz dużo czasu na dręczeniu szczegółów, staje się to kwestią moralności. Idealnie wszystkie standardy kodowania są sprawdzane automatycznie i nie można budować, dopóki ich nie przestrzegamy. To ogromna oszczędność czasu i pozwala zabrać się do pracy. Jeśli zarezerwujesz swoją krytykę na „rzeczy, które mają znaczenie”, twoja rada będzie miała o wiele większy wpływ i będziesz postrzegany jako ceniony mentor. Bardzo ważne jest, aby odróżnić rzeczy, które nie są dobre, od rzeczy, które nie są dokładnie takie, jak byś to zrobił.

Wierzę w koncepcję możliwego do nauczenia momentu . Jeśli programista ma wystarczającą zdolność umysłową, może poprosić o szczegóły dotyczące tego, co zrobiłbyś inaczej. (S) może nie i to jest w porządku. Ludzie zostają wypaleni i na początku kariery może zająć dużo energii mentalnej, aby osiągnąć rzeczy, które później wydają się proste.

JimmyJames
źródło
Jednym ze sposobów uniknięcia niekończących się cykli przeglądów kodu jest niewielkie wprowadzanie zmian. Żadne żądanie ściągnięcia nie jest absurdalnie małe, jeśli stanowi korzystną zmianę (podjąłem udział w PR-ach 1-char). Im mniejszy, tym lepiej. Bezlitośnie ograniczył zakres biletów przekazywanych młodszym deweloperom i sprawił, że załatwili sprawę. Gdy są one dobre w całym procesie odczytu, zrozumienia kodu, testu, recenzji i wdrożenia, zasięg może się zwiększyć.
9000
1
Nie sądzę, że dobrym pomysłem jest powiedzenie deweloperowi, że „nie są bardzo ważne”, jeśli są wystarczająco ważne, aby OP mógł wrócić i zmienić później.
enderland
3
@enderland Z mojego doświadczenia wynika, że ​​nie ma czegoś takiego jak idealny kod. Zawsze możesz go ulepszyć później, więc nie ma to większego znaczenia. OP twierdzi, że są to rzeczy, które „naprawiają, jeśli mam trochę wolnego czasu”. Istnieją dwa rodzaje problemów. Rzeczy, które muszą zostać naprawione i rzeczy, które nie muszą być naprawione. Te ostatnie mogą, ale nie muszą być naprawione, i brzmią, jakby należały do ​​tej kategorii. Na pewnym poziomie jest to wezwanie do osądu, ale myślę, że jeśli jako doświadczony deweloper nie jesteś pewien, czy warto go wzywać jako konieczną zmianę, prawdopodobnie tak nie jest.
JimmyJames
5

Rozważałbym zaakceptowanie jego pracy, gdy jest to dopuszczalne, a nie idealne. A następnie następnym zadaniem jest dyskusja, aby od razu ją przeredagować, wprowadzając wszystkie małe, ale ważne zmiany, które chcesz.

Kiedy więc praca jest po raz pierwszy akceptowana, twoja wiadomość jest taka, że ​​nie była zła, a niektóre miejsca zaakceptowałyby ją jako wystarczająco dobrą - ale nie miejsca, w których chciałbyś być jako młodszy programista, który chce właściwie nauczyć się swojego zawodu.

Więc nie mówisz: „Odrzucam twoją pracę, ponieważ nie jest wystarczająco dobra”. Mówisz (a) „Akceptuję twoją pracę, ponieważ jest wystarczająco dobra”, a następnie (b) „Ale chcę jej lepiej”.

gnasher729
źródło
3
Lub „(b) I wiem, że możesz zrobić lepiej”. Jeśli poprosi „naucz mnie”, wiesz, że jest na właściwej ścieżce. :)
Machado,
1
W mojej poprzedniej pozycji używaliśmy Stash / BitBucket jako naszego narzędzia do sprawdzania kodu. Miał opcję zablokowania żądania ściągnięcia poprzez ustawienie zaległego zadania lub całkowite odrzucenie żądania ściągnięcia. Używałbym ich tylko do niezbędnych zmian. Jeśli nastąpiła kosmetyczna zmiana (np. Niewielka czytelność kodu, lepsza struktura danych, refaktoryzacja) wskazałbym to sugestiami, ale nie dodawałbym zadania blokowania, zrób to, jeśli masz czas. Zapobiega to również przekroczeniu terminów w przypadku drobnych zakłóceń.
Hand-E-Food
4

Całkiem szeroko otwarte pytanie, ale oto kilka pomysłów.

  1. Recenzje recenzentów (młodszego programisty)

    Najlepszym sposobem, aby ktoś nauczył się „właściwego” sposobu, jest zobaczenie, jak inni to robią. Czy wszyscy programiści wykonują recenzje kodu? Nie jest złym pomysłem, aby pozwolić młodszemu programistowi je wykonać (chociaż powinieneś również wymagać co najmniej jednej recenzji od starszego programisty). W ten sposób zobaczy dobrych koderów w akcji, a także zauważy, że komentarze recenzentów są skierowane do inżynierów innych niż on, co oznacza, że ​​nie jest to sprawa osobista.

  2. Wczesne opinie / recenzje zadań

    Zezwól programistom na udział we własnym podziale zadań. Poproś go, aby zanotował swój zamierzony projekt w notatkach z zadania i przesłał „przegląd kodu” bez zestawu zmian i samego zadania. W ten sposób możesz przejrzeć jego plan, zanim napisze on jedną linię kodu. Po sprawdzeniu jego zadania może rozpocząć kodowanie (po czym prześle kolejną recenzję kodu). Pozwala to uniknąć demoralizującej sytuacji, w której programista napisał wiele rzeczy i musisz mu powiedzieć, żeby je przepisał.

John Wu
źródło
3
Podoba mi się pomysł recenzji, na razie jest nas dwóch w zespole, ale mogę poprosić go o sprawdzenie mojego kodu. Jeśli zrozumie, co robię, i znajdzie jakieś niezgodności, może to być pomyłka, zarówno pod względem jakości kodu, jak i jego morale. Pomogło mi to, gdy uczyłem się widząc, że nie tylko ja popełniałem błędy +1
Zalomon
2

Jeśli kod obiektywnie narusza zapisany, jednoznaczny standard, myślę, że powinieneś po prostu odpychać, aż każdy problem zostanie naprawiony. Oczywiście, może to być trochę denerwujące dla kilku pierwszych autorów, ale równie dobrze mogą poznać wytyczne wcześniej niż później.

Ponadto, jeśli dopuścisz kilka naruszeń standardów tu i tam, będą stanowić zły precedens - zobacz teorię rozbicia okien . O wiele łatwiej jest pamiętać o przestrzeganiu standardów, jeśli są one konsekwentnie stosowane w bazie kodu. Tak naprawdę wszyscy wygrywają, w tym młodsi programiści.

Nie sądzę, aby morale było dużym problemem, dopóki zapisany jest standard kodowania. Tylko wtedy, gdy staje się bardziej subiektywne „dobrze, ja zrobiłbym to inaczej” -territory, to powinieneś być zaniepokojony, ponieważ podejście deweloperów może być tak samo ważny.

JacquesB
źródło
2

Zastanów się nad przyjęciem procedury sprawdzania kodu, w której programiści publikują proponowane zatwierdzenia w narzędziu takim jak Github Pull Requests lub Phabricator Diffusion i otrzymują podpis rówieśniczy przed opublikowaniem swoich zmian we współdzielonej gałęzi głównej.

W ten sposób, zamiast z mocą wsteczną krytykować lub prosić kogoś o ponowne wykonanie tego, co już zostało zrobione, praca nie jest jeszcze wykonywana, dopóki nie przejdzie recenzji. W kółko z równorzędnymi elementami jest tak samo część procesu inżynierii oprogramowania, jak iz powrotem z kompilatorem.

Możesz publikować swoje obawy jako komentarze do poszczególnych linii i prowadzić wątkowe dyskusje na ich temat. On może zrobić to samo z twoim kodem. Dyskusja koncentruje się na konkretnych proponowanych zmianach kodu, a nie na czyichś wydajnościach lub kompetencjach w ogóle.

Nawet wspaniali starsi inżynierowie w mojej firmie są wdzięczni, gdy recenzje kodu łapią literówki lub zmuszają je do wyjaśnienia. Nowi pracownicy zatrudniają więcej rund iteracji. Z czasem zaczynasz odruchowo naprawiać problemy, o których wiesz, że przyciągają komentarze przed opublikowaniem pliku różnicowego. Uzyskanie wyższego odsetka zaakceptowanych różnic przy pierwszej próbie to sposób, w jaki wiesz, że się poprawiasz.

closeparen
źródło
1

Nie odpycham ciągle kodu, co dla początkującego może wydawać się drobnymi szczegółami, co może być dość frustrujące, ale martwię się również, że zbyt „miękki” może uniemożliwić facetowi nauczenie się pewnych rzeczy.

Są to zarówno rzeczywiste możliwości, jak i uzasadnione obawy. Zapytaj programistę, co sądzi o tym.

Kevin Krumwiede
źródło
W rzeczywistości powiedział mi, że czuje się głupi. Staram się krytykować pozytywnie i powiedziałem mu, że jestem zadowolony z jego pracy, wyjaśniłem mu również, że miałem takie wątpliwości, kiedy zaczynałem, ale muszę założyć, że niektóre opinie aby poprawić jego pracę, wychodzi źle.
Zalomon
2
Wyjaśnij, że nie marnowałbyś swojego czasu na krytykowanie jego kodu, jeśli nie spodziewałeś się, że przyniesie on korzyści w postaci lepszego programisty. I bądź skrupulatny w rozróżnianiu między „musisz to naprawić, aby kod był akceptowalny”, a „oto coś, co możesz zrobić jeszcze lepiej następnym razem”. Zapewnienie dużej ilości wnikliwej i dokładnej krytyki jest największym prezentem, jaki możesz dać młodszemu programistowi. Zaniechanie tego czyni go gorszym programistą. Krytyka powinna zacząć się zmniejszać. Każdy błąd musisz popełnić tylko raz, może dwa razy, a błędów jest tylko tyle.
David Schwartz
1

Zakładając, że masz przepływ pracy związany z żądaniem ściągnięcia lub przeglądem kodu i wygląda na to, że tak, polecam zanotować rzeczy, które są „niekrytyczne” lub „preferowane”.

Jeśli widzisz PR w stanie podobnym do tego, co opisujesz, z pewnymi drobnymi problemami stylistycznymi lub wymagającymi niekrytycznego refaktoryzacji, zostaw komentarz, ale możesz też zaakceptować. Powiedzenie czegoś takiego: „W przyszłości spróbuj uniknąć takich nazw metod na rzecz czegoś takiego jak descriptiveMethodName” dokumentuje twoją opinię bez zmuszania ich do zmiany lub blokowania ich rozwoju.

Teraz znają twoje preferencje i jeśli próbują się poprawić, mam nadzieję, że zauważą taką sytuację w przyszłości. Pozostawia im także otwarte drzwi, aby faktycznie je zmieniali w tym czasie, jeśli zgodzą się z tobą i uznają to za wystarczająco krytyczne.

zak
źródło
0

Mam do czynienia z młodszym programistą, który pracuje zdalnie z fabryki kodowania.

To niestety nie jest idealna sytuacja: jeden zaawansowany programista odpowiedzialny za jednego początkującego programistę, z separacją geograficzną. Nic dziwnego, że istnieje pewne napięcie, ale dysproporcję można złagodzić.

Jestem ciekawy, co rozumiesz przez „fabrykę kodującą”? Ta terminologia, moim zdaniem, wskazuje na niepokojące podejście, które może zaostrzać niektóre z wymienionych przez ciebie problemów zarządzania.

… Naruszenie SRP, obiektów Boga, nieistotnych nazw metod lub zmiennych; Wskazuję, co musi naprawić, i próbuję wyjaśnić, dlaczego to jest złe.

Myślę, że problem polega na tym, że twój młodszy programista wyrzuca kod, nie przechodząc przez odpowiedni proces projektowania. To z twojej strony, jako menedżera i starszego programisty, niedostarczenie wskazówek i nauczenie dobrych nawyków związanych z tworzeniem oprogramowania. Możesz przede wszystkim zapobiec pisaniu złego kodu, jeśli razem pracujesz nad szkicem konturu. Byłoby to lepsze niż krytykowanie i przepisywanie kodu po jego utworzeniu, zarówno pod względem wydajności, jak i morale.

Prawdopodobnie będziesz musiał dostosować przepływ pracy. Wygląda na to, że obecnie oczekujesz, że dostarczy ci produkty. Potrzebna jest ściślejsza współpraca, aby zapewnić wskazówki na każdym etapie rozwoju. Porozmawiaj o projekcie i interfejsie przed rozpoczęciem kodowania. Podczas kodowania rób częstsze punkty kontrolne, aby wcześniej wykryć problemy. Jeśli to możliwe, spróbuj sparować programowanie poprzez udostępnianie ekranu z kanałem audio.

Wszystko to będzie wymagać więcej wysiłku z twojej strony, ale prawdopodobnie będzie to opłacalne, biorąc pod uwagę problematyczne relacje, które obecnie masz.

200_sukces
źródło
-1

Jeśli jest to naruszenie standardów kodowania, pokaż mu, gdzie to jest, aby wiedział. Jeśli musisz ciągle pokazywać mu ten sam błąd, możesz mieć problem z kimś, kto albo nie może przestrzegać zasad, albo odmawia. Nie marnuj wolnego czasu na naprawę błędów. Ta osoba powinna naprawić własne błędy, aby nie popełniać ich ponownie.

Zawsze mów im, co zrobili dobrze i jak mogą poprawić następnym razem. Zawsze możemy być lepsi w niektórych obszarach. Informacje zwrotne mają kluczowe znaczenie w poprawianiu czegokolwiek.

akit
źródło
-1

Innym pomysłem na radzenie sobie z „zbyt dużą krytyką” jest od czasu do czasu samodzielne wykonanie zadania i pozwolenie młodszemu programistowi na sprawdzenie kodu. Ma to co najmniej dwie zalety:

  • mogą nauczyć się, jak należy to robić.
  • w przypadkach, gdy istnieje wiele dobrych rozwiązań lub nazw zmiennych, akceptuję sugestie różnych, ale (prawie?) równie dobrych podejść. Kiedy naprawiam kod z powodu czyjegoś komentarza, pokazuję ludziom, że są szanowani, a krytyka zawsze dotyczy tylko kodu - bez względu na to, kto jest autorem.
BartoszKP
źródło
Z przyjemnością dowiem się, co jest nie tak z moim postem. Opinia negatywna jest zrozumiałym znakiem niezgody, ale czy usunąć głosy ?!
BartoszKP