Jak byś pomyślał, że programista jest zły w tym, co robi?
Jeśli to możliwe ... Jak powinien poprawić?
Jak byś pomyślał, że programista jest zły w tym, co robi?
Jeśli to możliwe ... Jak powinien poprawić?
Odpowiedzi:
Kiedy nie uczą się na własnych błędach i na podstawie recenzji.
W pewnym momencie wszyscy jesteśmy zieleni; Jeśli jednak nie poprawiasz się lub nie próbujesz się poprawić, jesteś złym programistą.
Programista, który nie wie, czego nie wie i wcale go nie interesuje, aby się dowiedzieć.
Dużym znakiem ostrzegawczym jest to, że są programistami „kultu kultu” - co oznacza, że robią rzeczy, ale nie wiedzą, dlaczego to robią (to po prostu „magia”). Świetny post Erica Lipperta tutaj .
Z artykułu:
programiści, którzy rozumieją, co robi kod, ale nie wiedzą, jak to robi.
Ważną wskazówką jest dla mnie to, że zadają oni tobie lub innym programistom pytania programistyczne, które wyraźnie pokazują, że podjęli absolutnie zerowy wysiłek, aby je rozwiązać.
Następstwem jest wielokrotne zadawanie tego samego pytania programowego, co oznacza, że nie internalizują informacji.
Kiedy zajmuje im dużo czasu, aby rozwiązać problem FizzBuzz.
Programiści, którzy nie chcą uczyć się nowych technologii / języków i nalegają, aby trzymać się tego, co już znają.
Dodatek: (dodając myślnik poniżej w komentarzach)
Rozszerzeniem tego są ludzie, którzy znają podzbiór funkcjonalności niektórych technologii, ale nie wykazują chęci, aby dowiedzieć się o nim czegoś więcej. Język programowania, edytor, inne narzędzia ...
Gdy członek zespołu jest programistą produkującym negatywnie .
|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0
Oznacza to, że reszta twojego zespołu musi wykonać więcej pracy z powodu złego programisty. NNPP
Kiedy produkują rzeczy, które regularnie należą do The Daily WTF .
Kiedy wiedzą, że istnieją lepsze sposoby robienia rzeczy, ale nadal odmawiają ich wykonania, nawet jeśli pozwala na to czas.
Osobiście uważam, że każdy programista, który potrafi spojrzeć na własny kod, który napisał jakiś czas temu i nie znajduje w nim nic złego, nie jest dobry. „Chwilę” można skalować wraz z doświadczeniem ... Powiedziałbym, że od kilku tygodni do roku.
Kiedy byłem liderem zespołu w małym sklepie, było kilku ludzi, których musiałem ponownie przypisać (ani ja, ani mój bezpośredni przełożony nie mogliśmy wypowiedzieć umowy bez tony czerwonej taśmy i stosu dokumentacji.) Lub nie mieć przedłużenia umowy na koniec obecnego zlecenia. Niektóre z wymienionych typów działały również dla innych liderów zespołów i mieli oni podobne zdanie. Rzeczy, które zabrały ludzi do kategorii „Bad Programmer” w mojej książce:
To tylko niektóre ze złych postaci, z którymi musiałem pracować ...
/ s / BezantSoft
Prócz oczywistego braku wiedzy / umiejętności, programista jest zły, jeśli jego kod jest trudniejszy do odczytania i / lub utrzymania niż powinien.
Gdy nikt inny nie może odczytać jego kodu. Nie ma znaczenia, jak jasny jesteś; żaden programista nie jest wyspą.
Dla mnie są dwie kategorie programistów - solo i zespół.
Źli programiści solo są
Źli programiści zespołu to ci, którzy należą do kategorii złych programistów solo, w tym
Nie chcą przyznać, że nie znają odpowiedzi i / lub nie chcą szukać.
Jeśli nie wiesz, nie poddawaj się - wymyśl to i załatw sprawę.
Wielkim znakiem ostrzegawczym z mojego doświadczenia jest to, że nie komentują swoich hacków ...
Wiesz, co mam na myśli: kiedy jesteś zmuszony zrobić coś bardzo zuchwałego, ponieważ po prostu nie ma lepszego sposobu na zrobienie tego.
Dobrzy programiści nie znoszą tego robić i umieszczają w komentarzach, jak bardzo nienawidzą tego rodzaju włamań, ale nie ma wyboru. Źli programiści po prostu włożą się do hacka i nie skomentują tego.
Cicho, oczywiście, gdy programista pisze DUŻO kodu. Bardzo duże funkcje, może kopiuj / wklej wiersze lub bloki kodu, używając o wiele więcej, jeśli jest to konieczne itp. Może to być spowodowane tym, że programista nie zna standardowej funkcji do robienia tego, co chce, ale przez większość czasu tak nie jest.
Przenoszę tutaj swoją odpowiedź z zamkniętego, zduplikowanego tematu, który brzmiał: czy potrafisz rozpoznać, czy jesteś złym programistą? Drugi temat był zamykany, gdy tworzyłem odpowiedź. Moja odpowiedź bardziej bezpośrednio odnosi się do pytania, które zostało sformułowane przez drugiego pytającego i lepiej je zrozumiesz, jeśli to zrozumiesz.
Westchnienie! Część mnie nie chciała dodawać do tego już zajętego tematu, ale inna część mnie wygrała! Dlaczego wygrał; dlaczego zawracam sobie głowę dodawaniem kolejnych słów do tego konkretnego multilogu? Cóż, ponieważ do pewnego stopnia mogę mieć nieco inne podejście do tego niż wielu poprzednich komentatorów.
Binarnie działa świetnie na komputerach: „1” lub „0”, „on” lub „off”. Możemy wyodrębnić i zakodować wiele informacji za pomocą tych dwóch słynnych stanów. Ale nie działa tak dobrze w przypadku spraw ludzkich: „dobry” lub „zły”, „rozsądny” lub „szalony”, „dobry” lub „zły”, „mądry” lub „głupi”, „gruby” lub „cienki”, „żywy” lub „martwy?” Tego rodzaju spolaryzowane oceny zawsze sprawiały, że troskliwy człowiek był częścią mnie strasznie niezadowolony. Niezależnie od schematów pomiarowych, które wybiorę, zwykle stwierdzam, że odpowiedzi na tak ostre kontrasty faktycznie leżą gdzieś wzdłuż kontinuum między jednym takim biegunem a drugim, a nie na żadnym końcu.
Z tą tendencją do polaryzacji walczyłem już od dłuższego czasu, a moim osobistym rozwiązaniem jest, że o wiele bardziej przydatne jest zastosowanie trzech słów do każdej takiej oceny: „ w jakim stopniu!”
Tak więc, moja odpowiedź na twoje pytanie brzmi: zasugeruj je ponownie i zadaj sobie następujące pytanie: „W jakim stopniu jestem złym programistą?”. Lub jeszcze lepiej zapytać w drugą stronę: „W jakim stopniu jestem dobrym programistą?” Jeśli będziecie dążyć do prawdy, prawdopodobnie zlokalizujecie się gdzieś wzdłuż kontinuum między byciem „złym” programistą a „dobrym”. Następnie, gdy uda ci się zlokalizować w przybliżeniu to, gdzie jesteś na tej ścieżce, prawdopodobnie możesz zidentyfikować punkt nieco bliższy „dobrego” końca - punkt, w którym chciałbyś znaleźć się w najbliższej przyszłości.
Jeśli nie ustawisz tego punktu zbyt daleko, prawdopodobnie dostaniesz tylny koniec biegu i zaczniesz go przesuwać w tym kierunku. Jeśli uda ci się kilka razy powtórzyć ten dość prosty algorytm heurystyczny, może się okazać, że jesteś zbyt zajęty programowaniem, aby ponownie zadać to pytanie! Och, i prawdopodobnie zrobisz szybsze postępy, jeśli zaczniesz walić w klawisze tak szybko i często, jak to możliwe; a jeśli robisz sobie przerwę, przeczytaj jakiś kod wysokiej jakości napisany przez twoich rówieśników! W dzisiejszych czasach dynamicznego rozwoju Open Source nie brakuje wolnego i wykwintnego kodu do nauki!
Tak więc gorąco polecam wam, abyście wypróbowali moje trzy małe słowa „w jakim stopniu” i przekonali się, jak daleko mogą was poprowadzić!
Ktoś, kto mówi „Nie da się tego zrobić”.
Moim zdaniem chodzi o rozwiązywanie problemów, narzędzie powinno być znacznie mniej przydatne niż faktyczne wykonanie pracy. Jeśli muszę to rozwiązać za pomocą MS-Access lub asemblera, to kwestia czasu i pieniędzy, a nie „Nie da się tego zrobić”
Znak ostrzegawczy to zbyt duży nacisk na akademicki i „właściwy” sposób robienia rzeczy, a niewystarczający nacisk na wykonanie pracy.
Jeśli zna tylko składnię języka, ale nie zna podstawowych pojęć algorytmów.
! (inteligentny i załatwia sprawę)
Bezpośrednim sygnałem rozpoznawczym jest ktoś, kto mówi: „Nie rozumiem, dlaczego to nie działa. Zrobiłem wszystko dobrze”.
Jedną z rzeczy, która odróżnia złego programistę od początkujących, jest upór przy wdrażaniu swojego ulubionego systemu w jakimkolwiek języku i interfejsie API, w którym pracują.
Kiedyś odziedziczyłem system, w którym poprzedni programista ponownie wdrożył (w Javie) duży zestaw interfejsu Ashton Tate DBase III + nałożonego na niestandardową bibliotekę dostępu dbf. Żadna z ram kolekcji Java nie została użyta.
Dzięki temu mógł napisać aplikację Java / swing, która wyglądała i działała jak aplikacja DBase III + (lub ewentualnie clipper).
Aplikacje, które napisał w tym systemie, miały menu paska lite i otwierały pełne okno z rzędem przycisków na dole, gdy nawigowałeś pasek lite do opcji. To było jak mała wehikuł czasu z lat 80.
Ten człowiek był wyraźnie wykwalifikowanym programistą. Wiedział wystarczająco, że był w stanie sam napisać cały system w ramach czasowych tego projektu. Był również w stanie ponownie go użyć w kilku innych systemach wewnętrznych.
Ale był okropnym programistą, ponieważ jego kod niewłaściwie wykorzystywał funkcje systemów, nad którymi pracował. Był bardziej skłonny spędzić 3 miesiące na niestandardowej bibliotece wątpliwych korzyści, niż uczyć się Java / Swing / SQL.