To pytanie zostało zainspirowane tym . Chociaż to drugie pytanie zostało uznane za zlokalizowane, uważam, że podstawowy problem jest czymś niezwykle powszechnym w naszej branży. Wiem, że są programiści, którzy to przeczytają i pomyślą, że to wymyślam, a następnie mogą odpowiedzieć, że wszyscy troszczą się o swoją pracę i chcą się uczyć, ale tylko patrząc na inne posty programistów SE ( przypadek ), Wiem, że to nie jest prawda.
Powiedzmy, że masz kogoś w zespole (a może większość), którego standardową procedurą jest kopiowanie / wklejanie i kto wierzy, że wszystko można rozwiązać, jeśli tylko dodasz wystarczającą liczbę wywołań funkcji i zmiennych. Ta osoba nigdy nie słyszała o TDD, SUCHYM lub SOLIDNYM, a poza 40 godzinami pracy, kiedy jest zajęta pracą, nigdy nie czytała ani jednej metodologii / praktyk / książki projektowej.
W przeszłości ja (i inni) pytałem, jak uczyć OOD . Ale teraz myślę, że to nie jest właściwe pytanie. Prawdziwe pytanie brzmi: w jaki sposób podchodzisz do takiej osoby / zespołu i sprawiasz, że ciekawi ich lepszy sposób działania? Jak inspirujesz ich do nauki? Bez tego wydaje się, że wszystkie nauczanie, spotkania, wykłady, dyskusje są bezużyteczne, jeśli są całkowicie szczęśliwi, wracając do biurka i robiąc to, co zawsze robili.
Pracuję z taką grupą ludzi. W rzeczywistości są to dość bystre osoby, ale nienawidzę, gdy słyszę: „Skończyłem kodowanie, wystarczy zrefaktoryzować i podzielić na wiele klas, aby uszczęśliwić DXM”. Nie refaktoryzują czystszego, czytelnego, łatwego do utrzymania kodu, ale tylko dlatego, że w przeciwnym razie zostaną skarceni. Wiem, że są w stanie się uczyć, wydaje się, że ogólny brak motywacji.
Kiedy dostarczam pracę, generalnie ma o wiele mniej błędów, a praca, którą posiadam, nigdy nie stała się potwornością 5000 linii. Inni komentowaliby: „Twój kod jest znacznie bardziej przejrzysty i czytelny niż nasze”, więc widzą różnicę. Ale jednocześnie czuję, że wierzą, że zarabiają 40 godzin bez względu na to, co robią, więc nie mają nic przeciwko temu, że spędzą 3 pełne dni na kontroli jakości, szukając błędu, którego nie powinien był wprowadzić pierwsze miejsce. Lub że modyfikacja jednej klasy zajmuje tydzień, ponieważ istnieje tak wiele zależności, że w końcu się dotykają. Jednak „może ta klasa powinna być napisana inaczej” nigdy nie wyskakuje.
Czy można coś zrobić w takich sytuacjach? Czy komuś się udało? A może najlepiej jest odizolować taki sposób myślenia od niekrytycznych części projektu i zminimalizować szkody?
UWAGA: Kiedy mówię „brak motywacji”. Nie sądzę, żeby brakowało motywacji do pracy lub dobrej pracy, ponieważ po prostu przestali się przejmować. Większość naszego zespołu jest wręcz przeciwnie. Z pewnością dbają o produkt. Mamy facetów, którzy będą pracować nocami i weekendami. Część, przez którą próbuję przejść, to ulepszone nawyki i umiejętności, w rzeczywistości nie musieliby tyle pracować. Wydaje mi się, że dzięki „40 godzinom” ten post brzmiał trochę zbyt negatywnie.