Jak ustalić jakość kodu potencjalnego pracodawcy przed objęciem stanowiska? [Zamknięte]

Z mojego doświadczenia, zanim zaczniesz pracować dla firmy, nie masz okazji przyjrzeć się bazie kodu (poprosiłem i ze względu na poufność wszyscy zawsze mówili „nie”, myślę, że to jest sprawiedliwe), więc podczas rozmowy kwalifikacyjnej czy uważasz, że są najważniejsze pytania, które należy zadać, aby dowiedzieć się, w jakim stanie jest kod (w końcu, jeśli jest to pies, to będziesz miał do czynienia z biednymi nieszczęśnikami, którzy muszą go chodzić codziennie)?

AKTUALIZACJA:

Lista kontrolna: Zapytaj;

• Co oni myślą o kodzie. A kiedy to zrobisz, zwróć szczególną uwagę na mimikę twarzy i czas potrzebny na reakcję. [Zaraz]
• Jaki jest poziom CMM firmy [DPD] (i jeśli słyszysz, że poziom 5 działa w drugą stronę [Doug T])
• W jakim cyklu życia używają [DPD] (A jeśli słyszysz „Agile”, wtedy zaczynasz zadawać kilka wnikliwych pytań, aby spróbować dowiedzieć się, czy przez „Agile” mają na myśli „Agile” lub „kodowanie kowboja” [Carson63000])
• Jakich narzędzi używają do oceny jakości kodu? [DPD]
• Jakich narzędzi używają do programowania? [DPD] (poszukaj narzędzi do refaktoryzacji i serwerów ciągłej kompilacji)
• Jakiego systemu kodu źródłowego (kontroli wersji) używają, i dobrą odpowiedzią jest pytanie, dlaczego go używają. [Zachary K].
• Jakie są ich procedury testowe? [Karl Bielefeldt] (Zwróć szczególną uwagę na zespoły, które używają fałszywych frameworków i kładą nacisk na dokładne zautomatyzowane testowanie jednostek za pomocą ustalonych frameworków, takich jak NUnit / JUnit; nie zniechęcaj się zespołami, które nie używają testowego rozwoju TDD, ale bądź uważaj, jeśli nie uznają testowania za integralną i solidną podstawę do tworzenia oprogramowania. Poszukaj zespołów z oddanymi testerami).
• Jakie zadania są przydzielane nowym programistom? Do doświadczonych programistów? [Karl Bielefeldt]
• Ile osób pracuje nad projektem? [Karl Bielefeldt]
• Czy refaktoryzacja jest dozwolona? Zachęcony? [Karl Bielefeldt]
• Jakie zmiany w procesie lub architekturze związane z jakością są rozważane lub zostały wprowadzone niedawno? [Karl Bielefeldt]
• Ile autonomii mają poszczególne moduły? [Karl Bielefeldt]
• Czy będziesz opracowywać nowsze projekty (rozwój terenów zielonych) czy starsze projekty (rozwój terenów poprzemysłowych)? (Rozwój Greenfield jest ogólnie przyjemniejszy i ma mniej problemów, ponieważ nie czyścisz błędów innych).
• Czy wskaźnik rotacji pracowników jest wysoki w organizacji czy zespole? (Często oznacza to niższą jakość kodu) [M.Sameer]
• Niektóre twoje własne problemy programistyczne; ale unikaj wydawania się palantem. [Iskrzący]
• Jak współpracują programiści i jak dzielą się wiedzą w zespole? (To powinno pasować do twojej osobowości; powiedziałbym, że najlepiej jest mieszać pracę solo i parę, przy proporcji odpowiadającej twoim potrzebom społecznym)
• Jak blisko jest ich baza danych do trzeciej postaci normalnej (3NF), a jeśli odbiega ona gdzie i dlaczego? (Jeśli powiedzą „3NF ???”, wyjdź. Jeśli nie, a powody mogą być inne, dowiedz się, jakie są).

UWAGA: Zaakceptowałem odpowiedź Anona, ponieważ po około tygodniu społeczność myśli, że jest najlepsza - myślę, że to sugeruje, że jest to po prostu coś, dla czego musisz rozwinąć szósty zmysł. Ale myślę, że każdy miał coś cennego do powiedzenia.

Zamiast pytać o kod, zapytaj, co myślą o bazie kodu. A kiedy to zrobisz, zwróć szczególną uwagę na mimikę twarzy i czas potrzebny na reakcję.

Następnie wykorzystaj swoją wiedzę na temat niewerbalnych gestów kultury, aby zinterpretować to, co naprawdę mówią. W przypadku firmy z Ameryki Północnej następujące informacje powinny być dokładne:

• Małe wzruszenie ramion i szybka odpowiedź „mogłoby być lepiej”: prawdopodobnie jest całkiem niezła.
• Długa pauza, wdech, może mały śmiech: to nie jest przyjemne, a ludzie, z którymi rozmawiasz, nie czują się komfortowo, mówiąc ci to.
• Przewrócone oczy, szybka odpowiedź „to jest do bani”: może być dobra, może być zła, ale zdarzają się gry polityczne. Jeśli nie jesteś gotowy do grania lub pozostania cichym, trzymaj się z daleka.
• Podniesione lub zwężone brwi: nie rozumieją pytania, a baza kodów jest prawie na pewno zgniła.

Oczywiście, jeśli masz problemy z komunikacją międzyludzką, może to nie działać.

Dziwię się, że nawet zapytałeś. Żadna firma nigdy nie pokaże Ci kodu, zanim dołączysz. Nawet konsultanci wezwani do procesu, chyba że podpisali umowę o zachowaniu poufności.

Oto, o co możesz poprosić, aby się dowiedzieć.

• Jaki jest poziom CMM firmy (najlepiej 5)
• Jaki jest proces, który jest realizowany w twoim przyszłym projekcie (BTW, zadawanie pytań jest dobre, ponieważ pokazuje, że interesuje Cię „ta” praca, a nie tylko każda praca)
• Z jakiego cyklu życia korzystają (nie osądzaj, jeśli nie słyszysz „Agile”. Mogą mieć uzasadniony powód do używania modeli starej szkoły)
• Zapytaj, czy używają narzędzi i wskaźników do sprawdzania jakości kodu. A jeśli tak, to które (jeśli używają co najmniej jednego narzędzia do pomiaru, a drugiego do pomiaru jakości, jest to dobry znak).
• Zwróć też uwagę, jakich narzędzi używają. Jeśli jest to drogie narzędzie, takie jak Resharper zamiast jakiegoś darmowego narzędzia, poważnie traktują jakość.

1. Zapytaj ich, czy używają kontroli źródła.
   • Brak kontroli źródła? -> kod najprawdopodobniej gówniany
2. Zapytaj ich, jak często przeglądają kod.
   • Brak recenzji kodu? -> kod może być podejrzany (ale niekoniecznie tak, szczególnie jeśli jest to niewielki zespół złożony z porządnych programistów).
3. Zapytaj ich, jak testują i wdrażają przed wejściem do produkcji?
   • Brak środowiska testowego? Bezpośrednie wdrożenie do produkcji? -> kod najprawdopodobniej gówniany.
4. Zapytaj ich, czy wykonują ciągłą integrację (np. Uruchamianie kompilacji z Hudsonem)
   • Brak ciągłej integracji? -> kod może być podejrzany, ale niekoniecznie.
5. (Podobne do # 3), ich zapytać, czy ich środowisko testowe jest odrębny od danego środowiska rozwoju?
   • Test jest dev? -> nie jest to dobry znak, chyba że są naprawdę gotowi, ale jak drogie byłoby dodatkowe pudełko?
6. Zapytaj ich, czy przejrzą listę akcji przed wdrożeniem do produkcji.
   • Brak przeglądu działań przed wdrożeniem produkcyjnym? -> Bad juju.
7. Zapytaj ich, ile kroków zajmuje im wykonanie kompilacji.
   • Więcej niż 3? -> zazwyczaj złe juju.
8. Czy biorą (lub zgadują) miary kodu, takie jak złożoność cykliczna lub LCOM (miara spójności klas).
   • Tak? -> prawdopodobnie (ale nie na pewno) dobry znak dotyczący jakości ich kodu.
   • Nie, ale rozumieją pojęcia (przynajmniej złożoność cykliczna)? -> trudno powiedzieć
   • Uważają, że cykliczność jest egzotycznym daniem lub afrodyzjakiem z Timbuktu (innymi słowy, nie wiedzą, co to jest)? -> możliwe złe juju.
   • Myślą, że to nieistotne gówno (lub inne tego rodzaju zachowanie)? -> uciekaj.
9. Zapytaj ich, jak śledzą błędy.
   • Śledzą liczbę błędów w stosunku do niektórych danych (np. Na projekt, liczbę zmienionych modułów lub liczbę żądań / żądań zmiany, coś!)? -> dobry znak na temat ich kodu (i procesu tworzenia oprogramowania).
   • Czy robią to powyżej i próbują przewidzieć liczbę możliwych błędów, które mogą napotkać w przyszłym (lub trwającym) projekcie na podstawie oczekiwanych danych (liczba żądań zmiany, rozmiar projektu itp.)? -> bardzo dobry znak.
   • Śledzą błędy tylko w celu ich usunięcia? -> trudno powiedzieć
   • Brak spójnego śledzenia? -> uciekaj.

To byłoby z czubka mojej głowy. Zauważysz, że niektóre z moich pytań dotyczą procesu tworzenia oprogramowania, a nie tylko kodowania. Jakość tego drugiego jest bezpośrednią funkcją jakości tego pierwszego.

Powiedziawszy to, zadając te pytania, postępuj ostrożnie. Przestudiuj je i wybierz kilka podczas wywiadu.

Kilka rzeczy, o których powinieneś pamiętać. Dobry zespół programistów z przyjemnością usłyszy, jak osoba, z którą przeprowadzono wywiad, zadaje te pytania ... pod warunkiem, że zostanie zapytany z taktem. Zrób to źle, a dasz ankieterowi wrażenie arogancji i perfekcjonizmu. Bez względu na to, jak dobry jest zespół deweloperów, żadna grupa nie jest idealna i wszyscy mają problemy do rozwiązania, kompromisy w zakresie jakości i tym podobne. Chcą drużyny z zamiłowaniem do jakości, a nie destrukcyjnego perfekcjonisty. Więc uważaj.

Mogą się również zdarzyć przypadki, w których masz zespół dobrych ludzi, którzy z przyczyn zewnętrznych muszą pracować w kodzie o niskiej jakości (mogą to być programiści młodsi, lub po prostu odziedziczyli kupę bzdur, nad którymi muszą teraz pracować z ograniczonymi możliwościami) zasoby przeznaczone na poprawę jakości.) Możesz pracować z gównianym kodem i nadal mieć dobre doświadczenia zawodowe, jeśli ludzie wokół ciebie są również dobrymi ludźmi (zarówno osobiście, jak i zawodowo). Zadawaj im złe wrażenie, gdy zadajesz pytania, a oni mogą po prostu uniknąć całkowitego zatrudnienia cię (pozbawiając cię możliwości pracy z dobrymi ludźmi w bardzo trudnej i trudnej sytuacji).

• przy okazji, wierzę z całego serca, że ​​programista musi koniecznie przynajmniej raz pracować z jakimś kodem przekraczającym nadzieję (lub prawie poza nadzieją). Przetrwasz to i wykonasz dobrą pracę, to cenna lekcja.

Możesz także spotkać gównianą grupę programistów z gównianymi ludźmi. Oczywiście ich kod będzie gówniany i obleją się każdym z tych pytań. Mogą gardzić tobą za zadawanie im trudnych pytań (a zatem mogą wyświadczyć ci przysługę), lub zatrudnią cię, ponieważ cię potrzebują (nawet jeśli nie są / będą w stanie z tobą pracować).

Kiedy tak się dzieje, musisz zadać sobie pytanie, czy potrzebujesz tej pracy tak bardzo. Czasami to robisz i musisz zanurzyć się w kupie spaghetti. Czasami nie (to znaczy, możesz sobie pozwolić na nie.)

Są to rzeczy, które należy wziąć pod uwagę, gdy / jeśli zdecydujesz się zapytać ankietera o jakość jego kodu i procesów oprogramowania.

Zamiast rzeczywistej jakości kodu wolałbym raczej szukać firmy, w której znaczenie jakości kodu jest dobrze zrozumiane.

Na przykład powiedzmy, że firma A ma menedżerów, którzy uważają, że „planowanie to strata czasu” i „możemy później naprawić problemy projektowe (np. Gdy piekło zamarznie. Będziemy wtedy mieli czas)”. Nawet jeśli ta firma ma teraz dobrą bazę kodów, nie będzie miała jej długo. A ty będziesz tym, który będzie (zmuszony) pogorszyć sytuację.

Z drugiej strony, powiedzmy, że firma B ma złą bazę kodu, ale kierownictwo rozumie, że jakość kodu powoduje wszystkie te błędy i opóźnienia, widzą potrzebę zmian i są gotowi coś z tym zrobić (np. Na dużą skalę refaktoryzacja lub nawet przepisanie). Ta firma ulepszy swoją bazę kodu i możesz pomóc im to zrobić.

Wiem, gdzie chciałbym pracować.

Istnieje 99,9% szans, że nie będziesz mógł zobaczyć kodu przed rozpoczęciem. (O ile oczywiście nie wypuszczą wolnego oprogramowania)

Więc co możesz zrobić, zapytałbym o proces, ogólnie dobry proces wytworzy dobry kod. Zacznę od testu Joela i zapytam o metodę programowania. Wyjdź także poza podstawy. Na przykład zawsze pytam, jakiego systemu kodu źródłowego używają, więc dobrym rozwiązaniem jest pytanie, dlaczego go używają.

Miejsce, w którym pracowałem z kodem o bardzo wysokiej jakości, w zasadzie nie pozwalało dwóm trzecim programistów dotknąć kodu. Inni napisali zamiast tego automatyczne skrypty testowe czarnej skrzynki. Jeśli udowodniłeś, że jesteś godny zmiany faktycznego kodu, wymagania były tak bardzo zawyżone, że w zasadzie była to tylko transkrypcja na kod źródłowy. Skrypty testowe były tak naprawdę przyjemniejsze w pisaniu.

Miejsca, w których widziałem kod o najniższej jakości, były dokładnie odwrotne: tylko względnie niedoświadczeni lub niezaangażowani programiści kiedykolwiek dotknęli kodu, zwykle dlatego, że było to narzędzie niezwiązane bezpośrednio z produktem firmy lub uważane za eksperymentalne.

Najbardziej przyjemne miejsca pracy mają równowagę. Nowi programiści otrzymują prawdziwe zadania, ale są mentorami. Istnieje dobry dział kontroli jakości i proces wzajemnej oceny w celu wykrycia błędów. Nie jesteś karany za popełnianie błędów, ale musisz je naprawić i uczyć się od nich. Czasem źle napisany moduł wpada przez szczeliny, ale nie jesteś krytykowany za poświęcanie czasu na poprawę jakości kodu. Firma jako całość nieustannie poszukuje nowych sposobów na ulepszenie kodu.

Dlatego pytania, które zadałbym w celu oceny jakości kodu, to:

• Jakie są twoje procedury testowe?
• Jakie zadania są przydzielane nowym programistom? Do doświadczonych programistów?
• Ile osób pracuje nad projektem?
• Czy refaktoryzacja jest dozwolona? Zachęcony?
• Jakie zmiany w procesie lub architekturze związane z jakością są rozważane lub zostały wprowadzone niedawno?
• Ile autonomii mają poszczególne moduły?

Jak powiedział @DPD i @Zachary, proces i SDLC są bardzo ważnymi czynnikami, ale chcę dodać kilka innych czynników, które zgodnie z moim doświadczeniem mają znaczący wpływ na jakość kodu:

• Zapytaj, czy zamierzasz pracować nad programowaniem w stosunkowo nowym projekcie lub w utrzymaniu starszej aplikacji. Starsze aplikacje są zwykle mniej czyste niż nowsze projekty.
• Spróbuj się dowiedzieć, czy wskaźnik rotacji pracownika jest wysoki w organizacji lub zespole. To najprawdopodobniej obniży również jakość kodu.

Pamiętaj, że proces bardzo pomaga, ale nie daje całkowitej odporności na powyższe czynniki. Kiedy wielu programistów przekazuje projekt, każdy ma inny sposób myślenia. Architekt i deweloper nie będą postępować dokładnie tak, jak zrobili to ich poprzednicy, co doprowadzi do pewnych niespójności.

Moje podejście jest takie, kod jest kodem, jeśli jest zły, to jest wyzwanie, aby go ulepszyć. Jeśli jest dobry, to jest jeszcze trudniejsze wyzwanie, aby go ulepszyć!

Najważniejsze dla mnie jest to, czy chcę pracować dla firmy i ludzi, z którymi mam okazję współpracować. Kod można zmienić, ludzie nie mogą ...

Nieco żartobliwie mówię, przeprowadzam ze mną wywiad .

Zwykle używam rzeczywistego błędu (już naprawionego) w naszej bazie kodu jako testu wywiadu, więc widzisz trochę rzeczywistego kodu. Zasadniczo nieco skomplikowany kod i zawiera błąd.

Zachęcam wszystkich do korzystania z tej techniki, ponieważ już wiesz, że błąd jest prawdziwy, problem jest prawdziwy i wiesz, ile czasu zajęło znalezienie i naprawienie.

Świetną rzeczą jest to, że możesz mieć mierzalnie trudny problem.

Użyłem bardzo trudnego problemu jako pytania z ostatniego wywiadu, aby oddzielić ekspertów od całkiem dobrych.

Znaczenie pytania PO polega na tym, że każdy, kto przejdzie wywiad fizyczny, zobaczy kod. (Nic z poufnymi treściami firmy)

Jeśli nie możesz użyć tej techniki, powiedzmy, wulgaryzmów w bazie kodu, test działa, ponieważ potencjalni pracownicy zapytają „czy mogę zobaczyć kod”, a odpowiedź brzmi „och, nie możesz pełne wulgaryzmów ".

Oczywiście standardową odpowiedzią „to wszystko tajemnica firmy” jest całkowity chytry koń.
Mój dowód: u mojego poprzedniego pracodawcy część niepoufna produktu wojskowego była próbka kodu do pytania na rozmowę kwalifikacyjną. [Na szczęście niesklasyfikowane]

Problem z określeniem jakości sklasyfikowanych projektów pozostawiam przed kimś mądrzejszym ode mnie. Sugeruję, że może być powszechne, że klasyfikacja jest synonimem wolnego od nadzoru.

Wątpliwe jest, aby pozwolili ci zobaczyć ich kod, ale możesz być w stanie dowiedzieć się, jak to może być, jeśli powierzysz im zadanie domowe z programowania. Wiele miejsc daje rozmówcom zadanie programowania na wynos, którego mogą użyć do oceny ciebie. Oddaj przysługę - spodziewaj się jednego z nich, aby lepiej ocenić, w co możesz się wpakować.

Zapytaj, co jest wymagane, aby kod mógł znaleźć się w kompilacji produkcyjnej. Jeśli dostaniesz „hmm ... twórca to popełni ...”, to prawie na pewno śmieci.

Istnieje wiele rzeczy, które mają tendencję do podnoszenia jakości kodu (oczywiście nie ma gwarancji).

• Analiza statyczna (w .NET są to rzeczy takie jak fxcop / stylecop)
• Podzbiór (lub pełny zestaw) zestawu testowego - jednostka / integracja / regresja / instrukcja itp.
• Kompilacja znajomych (inny deweloper w zespole buduje zmiany, aby sprawdzić, czy występują problemy zależne od maszyny / użytkownika - czasami także szybkie zdrowie psychiczne)
• Przegląd kodu

Mogą one pomóc poprawić nie tylko siłę kodu, ale także jego jakość.

Zapytaj ich o testy jednostkowe. Jeśli wezmą to na poważnie, wówczas osoba przeprowadzająca wywiad prawdopodobnie będzie miała pewne określone opinie na ten temat i chętnie się z nimi podzieli. Jeśli odpowiedzi są niejasne, to duży znak ostrzegawczy.

Jeśli jest to sklep Java, zapytaj ich, jakiej biblioteki ORM używają. Jeśli wyrzuciły własne, może pójść w obie strony - może ssać lub może być w porządku. Jeśli nie używają żadnego, biegnij od razu do drzwi.

To trudne zadanie, ponieważ istnieje tak wiele różnych złych praktyk kodowania, że ​​nigdy nie będziesz w stanie przewidzieć wszystkich.

Niestety nie możesz. Żadna firma nie pozwoli ci zobaczyć ich kodu (ale poprosi o obejrzenie TWOJEGO kodu ...), a są szanse, jeśli zadasz im pytania dotyczące środowiska, w którym albo zostaniesz okłamany („Kontrola wersji? Jasne .. używamy ... uhh .. myśląc Sub .. Sub-coś ”) lub wprowadziliśmy w błąd co do jakości („ Używamy najnowszego i najlepszego .NET 4 ”tylko po to, aby dowiedzieć się, że podczas korzystania z .NET 4„ piszę go jak .NET 1.1).

W przeszłości byłem przez niego palony wiele razy i jeszcze nie znalazłem dobrego sposobu na ocenę jakości. Zwykle najlepszym sposobem jest skorzystanie z własnego osądu, a jeśli sprowadza się do tego, opuść natychmiast, jeśli jest gorzej, niż ci się wydawało; możesz skończyć z pracy, ale zachowasz rozsądek.