Jaki jest najbardziej absurdalny mit o problemach programistycznych?

Innymi słowy ... Jakie jest najczęściej utrzymywane i frustrujące nieporozumienie na temat programowania?

Które rozpowszechnione i długotrwałe mity / nieporozumienia są dla programistów trudne do usunięcia / poprawienia .

Proszę wyjaśnić, dlaczego to mit.

To dlatego, że jesteś programistą, wiesz, jak naprawić maszynę wirusową [osoby].

Powszechna rzecz HR, która doprowadza mnie do szału, gdy szukam pracy: domniemane założenie, że wszystkie umiejętności kodowania są specyficzne dla języka i że nie ma specjalistycznej wiedzy inżynierskiej, która wykraczałaby poza zestawy poleceń. Dziesięć lat doświadczenia w Javie i kolejne pięć w Perlu oznacza, że ​​byłbyś całkowicie bezużyteczny w projekcie, który używa, powiedzmy, C #.

„Tak, jest krzywa uczenia się. Ale zrobiłem trudniejsze przejścia niż to. Zrobię ci umowę, zapłać mi 80% za pierwszy miesiąc, a pod koniec tego czasu, jeśli nie jestem ... och , czekaj, tak naprawdę nie prowadzimy tej rozmowy, ponieważ twoja małpa HR po prostu usunęła moją aplikację ”.

Jeśli nie piszesz, nie pracujesz.

Uważam, że puste spojrzenia zombie i spacery po kawie są niezbędne dla programistów organizujących rzeczy w swoich głowach.

że możesz przyspieszyć późny projekt, po prostu rzucając na niego więcej ludzi.

To oprogramowanie do pisania jest łatwe.

Jak inaczej wyjaśnisz wszystkie te projekty, które trwają w czasie i przekraczają budżet, a ludzie (politycy, media itp.) Są nadal zaskoczeni, a klienci narzekają, gdy mówisz im, że ich „mała strona internetowa” (lub cokolwiek innego) faktycznie zajmie 6 miesiące na rozwój i kosztowały kilka tysięcy dolarów (funty, euro, [wstaw wybraną walutę])

Mając niewyraźne i ciągle zmieniające się wymagania, czasami myślę, że to niesamowite, że każde oprogramowanie się kończy!

Wiem, że to trochę bardziej skomplikowane;)

Złożoność aplikacji jest wprost proporcjonalna do złożoności interfejsu użytkownika. Zgodnie z tym rozumowaniem powinieneś być w stanie zbudować Google lub Twitter przez weekend.

Wszyscy programiści są dobrzy w matematyce. :-)

Każdy nastoletni dzieciak, który hakuje za pomocą komputera, ma umiejętności (lub lepszy) od weterana pracującego programisty.

Mój 14-letni siostrzeniec dobrze zna się na komputerach i płacę mu 10 USD za godzinę, aby kosił trawnik. Dlaczego mam zapłacić sześć cyfr za napisanie następnego FaceBooka?

Ten czas rzeczywisty oznacza szybki.

Stwierdzenie „Pakiety muszą być przetwarzane w czasie rzeczywistym”. jest bezwartościowy, a zły bliźniak ... odpowiada: „Jak szybko musi nastąpić X?” z „Real-time” jest prawdopodobnie mniej niż bezwartościowe… graniczące raczej z głupotą niż ignorancją.

W czasie rzeczywistym oznacza, że ​​po prostu ta funkcja Y zawsze zajmuje X czasu, a wszelkie odchylenia wskazują na poważny błąd. Czas trwania X nie definiuje „w czasie rzeczywistym”, może wynosić sześć mikrosekund lub sześć dni. To, że możesz określić, że funkcja Y zajmie czas X, definiuje „w czasie rzeczywistym”. Zgodnie z tą definicją systemy czasu rzeczywistego są deterministyczne.

Więc strąc to ...

Dlaczego po prostu nie napisacie tego poprawnie za pierwszym razem, zamiast spędzać tyle czasu na pisaniu błędnego kodu, a potem na czytaniu kodu, próbując znaleźć błędy?

:-) :-) :-) :-)

Jeśli nie studiowałeś, nie nadajesz się do tej pracy

Ta przedwczesna optymalizacja oznacza, że ​​nie powinieneś w ogóle optymalizować. Widziałem więcej strasznie złych baz danych, ponieważ nikt nie chciał brać pod uwagę wydajności (krytycznej dla dowolnego systemu baz danych) w projekcie, ponieważ była to przedwczesna optymalizacja niż jakikolwiek inny problem z projektowaniem bazy danych. Śmieci, są znani zabójcy wydajności, przestań ich używać jako pierwszego wyboru.

Kolejny mit, że zbyt trudno jest refaktoryzować bazę danych. Nie, ale musisz zastanowić się, jak przeprowadzić refaktoryzację na etapie projektowania, aby zrobić to skutecznie. A tak przy okazji, im dłużej będziesz czekać na rozwiązanie tego irytującego problemu związanego z wydajnością, tym trudniej będzie to naprawić.

Kolejny zły mit, projektowanie baz danych powinno odzwierciedlać zasady OOP. Nie, bazy danych są zaprojektowane do pracy z zestawami, a nie zasadami OOP. Niektóre rzeczy związane z OOP powodują okropne problemy z wydajnością, a inne są po prostu niemądre z punktu widzenia bazy danych.

Wreszcie należy wymusić integralność danych w aplikacji. Bazy danych będą trwać dłużej niż aplikacja i utraciłyby reguły, gdy aplikacja zostanie zastąpiona, wiele aplikacji będzie miało do nich dostęp i często będzie konieczne uruchamianie bezpośrednich zapytań w celu naprawy rzeczy, które nie przechodzą przez aplikację. Nigdy nie widziałem bazy danych, która odmawia wymuszania integralności danych w bazie danych, która ma dobre dane.

Że istnieje mityczne źródło absolutnych najlepszych praktyk.

Żadne odchylenie nie może być nigdy uzasadnione.

Żaden dokument podający się za definicję najlepszej praktyki nie może być nigdy kwestionowany.

Fakt, że marketing wydaje się uważać, że dodanie wielu drobnych funkcji jest mniej pracochłonne niż dodanie pojedynczej, ale raczej ciężkiej funkcji. Co prawdopodobnie jest bardziej konkretnym przypadkiem błędnego przekonania, że ​​„przełączanie zadań nie ma narzutu”.

Ten kod komentowania jest niepotrzebny lub że „dobry kod nie wymaga komentarzy”. Czasami musisz wyjaśnić, co robi złożony kawałek kodu. Co więcej, komentowanie sekcji kodu pomaga znacznie bardziej efektywnie przeszukiwać.

Najgorszy mit: jeśli programujesz przez długi czas, możesz łatwo zostać Project Managerem.

I że powinieneś zostać kierownikiem projektu, jeśli programujesz od dłuższego czasu.

Jeśli użyjemy w naszym projekcie czegoś innego niż Java, C # i C ++, nie znajdziemy żadnego programisty, który by to obsługiwał.

Java to po prostu C ++ z różnymi klasami.

Java działa wolno .

Prawdopodobnie najbardziej niebezpieczny, jaki widziałem, ponieważ jest tak chętnie akceptowany, ponieważ umiejętność szybkiego pisania kodu jest dobra i dlatego im szybciej możesz napisać [wstawić tutaj funkcję] w danym języku, tym lepszy język jest.

Jest to poważny przykład przedwczesnej optymalizacji, ponieważ o wiele więcej pracy wymaga utrzymanie kodu niż jego tworzenie. Oznacza to, że o wiele ważniejsze jest pisanie kodu, który jest łatwy do odczytania, zrozumienia i debugowania, niż kod, który jest łatwy do szybkiego pisania, a ułatwienie łatwego do odczytania kodu jest znacznie bardziej użytecznym pomiarem jakości języka.

Lekcje wytwarzania można zastosować do procesu tworzenia oprogramowania.

że jako programista wiesz wszystko o najnowszych trendach sprzętowych, przetaktowywaniu, modowaniu skrzynek itp. przyjaciele i krewni konsultują się przy zakupie sprzętu.

Gdy programiści twierdzą, że jest to bardzo trudne / po prostu niemożliwe, HR uważa, że ​​jest leniwy i niezmotywowany

Dla mojej firmy musi istnieć program typu open source. Nie możesz go po prostu pobrać i dostosować do moich wymagań.

Kiedyś więcej niż jedna osoba pytała mnie, jak to jest programować, aby w połowie rozmowy uświadomić sobie, że tak naprawdę myślą, że programujemy bezpośrednio w postaci binarnej lub za pomocą symboli matematycznych.

Nie wiem, czy chcę rozwiać ten mit, sprawia, że ​​wyglądam naprawdę elegancko!

Myślę, że największym nieporozumieniem jest to, że ważniejsza jest umiejętność łatwego zapisywania kodu niż umiejętność czytania i rozumienia kodu.

Programowanie jest jak praca na linii montażowej. Pracujesz nad produktem przez pewien czas (być może ze współpracownikami) i wreszcie go wysyłasz. Podobnie jak budowanie domu z cegieł.

Contra: Programowanie zawiera wiele kreatywności i planowania. To jest sztuka. Podobnie jak mason, także programista zna różnicę między kształtowaniem cegły a planowaniem całej katedry.

Przeniesienie programu do C ++ automatycznie przyspieszy jego działanie.

Każde środowisko programistyczne z jakimś projektantem wizualnym sprawi, że użytkownicy biznesowi będą mogli „pisać” program, a faktyczni programiści nie będą potrzebni.

Ponowne użycie OOP. To największy błąd wprowadzony na rynek w programowaniu.