Jak radzić sobie z pytaniami na temat stylu programowania [zamknięte]

Jako programista C ++ w wywiadach wielokrotnie znajdowałem się w sytuacjach, gdy ankieter chciał sprawdzić moją wiedzę na temat dobrego stylu programowania. Zazwyczaj koncentrowały się one wokół podstawowej wiedzy na temat OOP.

Wiem, że OOP jest przydatne do enkapsulacji pojęć i używam go codziennie. Jednak ponieważ język taki jak C ++ pozwala na wiele różnych stylów, a niektóre podejścia C ++, takie jak algorytmy TMP lub STL, wcale nie są OOP (ale raczej przypominają programowanie funkcjonalne), utknąłem w tym, jak najlepiej „sprzedać” moją wiedzę na temat innych podejść, ponieważ dobrze, nie spotykając się jako arogancki lub jako ktoś bez znajomości podstaw. Obawiam się, że ten nacisk na OOP pytających wynika z ich socjalizacji w latach 90., gdzie uważano, że OOP jest lekarstwem na wszystko, ale to aroganckie stanowisko.

Jak mam zrobić najlepsze z takich pytań?

Powiedziałbym, że musisz jak najlepiej odpowiadać na tego rodzaju pytania, tak jak najlepiej odpowiadasz na wszelkiego rodzaju pytania.

Później, kiedy będziesz mieć możliwość zadawania pytań ankieterowi, powinieneś podnieść temat, zadając pytania takie jak:

• Czy robisz tylko OOP?
• Używam innego podejścia programistycznego, jak to jest akceptowalne w twoim zespole?

I tak dalej ... w ten sposób możesz nie tylko rozpocząć rozmowę o sprzedaży swojej wiedzy specjalistycznej za pomocą innych metod, ale także zobaczyć, jak sztywny i jak duży nacisk kładziony jest na OOP w tym zespole / firmie.

Nie przejmuj się zbytnio motywacjami pytającego i po prostu odpowiedz uczciwie. Pamiętaj, że wywiad to dwukierunkowa ulica. Nie chcesz utknąć w ideologicznie nieelastycznej firmie bardziej niż oni chcą utknąć z tobą.

Biorąc to pod uwagę, myślę, że jesteś trochę paranoikiem co do intencji ankieterów. Zdumiewająca liczba rzekomo profesjonalnych programistów nie rozumie podstaw OOP. W 99% przypadków ankieterzy nie próbują sprawdzić, czy wypiłeś pomoc kool OOP, ale chcą tylko sprawdzić, czy ją rozumiesz. Nawet jeśli uważasz, że inny paradygmat lepiej nadaje się do określonego rozwiązania, ankieterzy chcą wiedzieć, że był to świadomy wniosek, a nie niewiedza o OOP.

Racjonalizacja jest bardzo częstym mechanizmem obronnym, gdy ktoś czegoś nie rozumie. Jeśli ludzie nie rozumieją pojęcia, twierdzą, że jest ono głupie lub nie nadaje się do zastosowania, niż przyznają się do swojej ignorancji. Nawet jeśli naprawdę uważasz, że OOP jest złym wyborem na odpowiedź, musisz jednak odróżnić się od racjonalizatorów. Sposobem na to jest zarówno wyjaśnienie rozwiązania OOP, jak i dlaczego uważasz, że jest to zły wybór w tej sytuacji.

Chciałbym podkreślić, że postępujesz zgodnie z zasadą SOLID , czyli OOP i więcej. Nie tylko gwarantuje, że twój kod jest zorientowany obiektowo, ale że jest ukształtowany w taki sposób, że zastępowanie obiektów zgodnie z zasadą SOLID jest stosunkowo prostym zadaniem. Nie tylko wysłałby wiadomość, że znasz OOP, ale także pokazuje, że rozumiesz subtelne punkty tego, co odróżnia dobry kod OOP od hackowanego skomplikowanego kodu OOP napisanego przez kogoś, kto programował w C i uważa, że ​​wszystkie inne języki powinny być programowane w ta sama moda, ponieważ bądźmy szczerzy, to sprawia, że ​​jesteś dobrym programistą, a nie tylko możesz korzystać z OOP.

Przygotuj się do dokładnego wyjaśnienia każdej z pięciu zasad, dlaczego każda z nich jest ważna i co może się stać z kodem, który ignoruje tę zasadę.