Długotrwałe, niepoprawne założenia programistyczne [zamknięte]

Robię badania nad typowymi błędami i złymi założeniami poczynionymi przez młodszych (i być może starszych) inżynierów oprogramowania.

Jakie było twoje najdłużej utrzymywane założenie, które ostatecznie zostało skorygowane?

Na przykład, źle zrozumiałem, że rozmiar liczby całkowitej nie jest standardem, a zamiast tego zależy od języka i celu. Trochę zawstydzające, ale tak jest.

Bądź szczery; jakie masz głębokie przekonanie i z grubsza jak długo utrzymałeś to założenie? Może dotyczyć algorytmu, języka, koncepcji programowania, testowania lub czegokolwiek innego na temat programowania, języków programowania lub informatyki.

Przez długi czas zakładałem, że wszyscy inni opanowali wszystkie koncepcje programowania (wzorce projektowe, najnowszy nowy język, złożoność obliczeniowa, wyrażenia lambda, nazywacie to).

Czytanie blogów, Stack Overflow i książek o programowaniu zawsze sprawiało, że czułem, że jestem w tyle za tym, co wszyscy programiści muszą po prostu wiedzieć intuicyjnie.

Z biegiem czasu zdałem sobie sprawę, że skutecznie porównuję swoją wiedzę do wiedzy zbiorowej wielu osób, a nie jednej osoby, i to jest całkiem wysoki poziom dla każdego. Większość programistów w prawdziwym świecie dysponuje pamięcią podręczną wymaganą do wykonywania swoich zadań i ma więcej niż kilka obszarów, o których są słabi lub zupełnie nieświadomi.

Że ludzie wiedzieli, czego chcą.

Najdłużej myślałem, że będę rozmawiał z ludźmi, oni opisywaliby problem lub przepływ pracy, umieszczałem go w kodzie i automatyzowałem. Okazuje się, że za każdym razem, kiedy to się dzieje, to, co myśleli, że chcieli, nie było tym, czego chcieli.

Edycja: Zgadzam się z większością komentarzy. To nie jest odpowiedź techniczna i może nie być tym, czego szukał pytający. Nie dotyczy to tylko programowania. Jestem pewien, że to nie jest moje najdłużej utrzymywane założenie, ale była to najbardziej uderzająca rzecz, której nauczyłem się w ciągu 10 krótkich lat, kiedy to robiłem. Jestem pewien, że z mojej strony było to naiwne, ale sposób, w jaki mój mózg jest / był podłączony do sieci, a nauczanie i doświadczenia, które miałem przed wejściem do świata biznesu, skłoniły mnie do przekonania, że ​​zrobię to, na co odpowiem; że będę w stanie używać kodu i komputerów do rozwiązywania problemów ludzi.

Myślę, że ta odpowiedź jest podobna do odpowiedzi Robina na temat nie-programistów rozumiejących / dbających o to, o czym mówię. Chodzi o naukę biznesu jako zwinny, iteracyjny, interaktywny proces. Chodzi o poznanie różnicy między byciem małpą kodującą programistą a byciem programistą. Chodzi o uświadomienie sobie, że między nimi jest różnica i że naprawdę jest w tej dziedzinie dobra, nie chodzi tylko o składnię i szybkość pisania.

Edycja: Ta odpowiedź jest teraz wiki-społeczności, aby uspokoić ludzi zdenerwowanych tą odpowiedzią, dając mi przedstawiciela.

Że wiem, gdzie jest problem z wydajnością bez profilowania

Że powinienem mieć tylko jeden punkt wyjścia z funkcji / metody.

Że nieprogramiści rozumieją o czym mówię.

To wolne od błędów oprogramowanie było możliwe.

Te prywatne zmienne składowe były prywatne dla instancji, a nie dla klasy.

Myślałem, że pisanie na klawiaturze było nieruchome.

Że możesz w pełni zrozumieć problem, zanim zaczniesz się rozwijać.

Mądrzy ludzie są zawsze mądrzejsi ode mnie.

Naprawdę potrafię się pobić, kiedy popełniam błędy, i często zostaję przeklęty za to, że się deprecjonuję. Kiedyś patrzyłem z podziwem na wielu programistów i często zakładałem, że skoro znali więcej niż ja na X , wiedzieli więcej niż ja.

Ponieważ nadal zdobywam doświadczenie i spotykam więcej ludzi, zacząłem zdawać sobie sprawę, że często, choć wiedzą więcej niż ja w danym temacie, niekoniecznie są mądrzejsi ode mnie.

Morał tej historii: nigdy nie lekceważ tego, co możesz przynieść na stół.

Przez najdłuższy czas myślałem, że złe programowanie stało się na marginesie ... że robienie rzeczy było normą. W dzisiejszych czasach nie jestem taki naiwny.

Pomyślałem, że powinienem przejść do abstrakcji w jak największym stopniu. Uderzyło mnie to z powodu zbyt dużej ilości powiązanych funkcji.

Teraz staram się, aby rzeczy były jak najprostsze i jak najbardziej rozdzielone. Refaktoryzacja w celu stworzenia czegoś abstrakcyjnego jest znacznie łatwiejsza niż przewidywanie, w jaki sposób muszę coś abstrakować.

W ten sposób przeszedłem od opracowania frameworka, który nimi rządzi, do fragmentów funkcjonalności, które wykonają zadanie. Nigdy nie oglądałem się za siebie, chyba że myślę o czasie, który naiwnie myślałem, że to ja będę rozwijał następną wielką rzecz.

Kobiety uważają programistów komputerowych za seksowne ...

Że jakość oprogramowania doprowadzi do większej sprzedaży. Czasami tak jest, ale nie zawsze.

Że wszystkie języki są (w większości) równe.

Przez długi czas doszedłem do wniosku, że wybrany język nie ma większego wpływu na trudność procesu rozwoju i potencjał sukcesu projektu. To zdecydowanie nie jest prawda.

Wybór odpowiedniego języka dla zadania jest równie ważny / krytyczny jak każda inna decyzja dotycząca pojedynczego projektu.

To, że duży stosunek komentarz / kod jest dobrą rzeczą.

Zajęło mi trochę czasu, zanim zdałem sobie sprawę, że kod powinien być samodokumentujący. Jasne, komentarz tutaj i tam jest pomocny, jeśli kod nie może być wyjaśniony lub jeśli istnieje ważny powód, dla którego coś się robi. Ale ogólnie lepiej poświęcić temu czasowi na zmianę nazw zmiennych. Jest czystszy, wyraźniejszy, a komentarze nie są „niezsynchronizowane” z kodem.

To programowanie jest niemożliwe.

Nie żartowałem, zawsze myślałem, że programowanie jest czymś niemożliwym do nauczenia się i zawsze trzymałem się od tego z daleka. A kiedy zbliżyłem się do kodu, nigdy go nie zrozumiałem.

Pewnego dnia po prostu usiadłem i przeczytałem kilka podstawowych samouczków dla początkujących i zacząłem stamtąd. A dzisiaj pracuję jako programista i uwielbiam każdą minutę.

Dodając, nie sądzę, aby programowanie było łatwe, jest wyzwaniem i uwielbiam uczyć się więcej i nie ma nic przyjemniejszego niż rozwiązywanie problemów programistycznych.

„On Error Resume Next” było pewnego rodzaju obsługą błędów

To oprogramowanie do programowania wymaga silnych podstaw w wyższej matematyce.

Przez lata zanim zacząłem kodować, zawsze mówiono mi, że aby być dobrym programistą, musisz być dobry w zaawansowanej algebrze, geometrii, rachunku różniczkowym, trygonie itp.

Dziesięć lat później i tylko raz musiałem zrobić wszystko, czego nie mógł zrobić ósmy równiarka.

Optymalizacja == przepisywanie w asemblerze.

Kiedy po raz pierwszy naprawdę zrozumiałem asembler (pochodzący z BASIC), wydawało się, że jedynym sposobem na przyspieszenie działania kodu jest przepisanie go w asemblerze. Zajęło mi to kilka lat, aby zrozumieć, że kompilatory mogą być bardzo dobre w optymalizacji, a zwłaszcza w przypadku procesorów z prognozowaniem gałęzi itp. Prawdopodobnie mogą wykonać lepszą robotę niż człowiek w rozsądnym czasie. Również spędzanie czasu na optymalizacji algorytmu może dać lepszą wygraną niż spędzanie czasu na konwersji z języka wysokiego na niski. Również ta przedwczesna optymalizacja jest źródłem wszelkiego zła ...

• Kierownictwo firmy dba o jakość kodu.
• Im mniej linii, tym lepiej.

Powiedziałbym, że przechowywanie elementu roku daty jako 2 cyfr było założeniem, które dotknęło całe pokolenie programistów. Pieniądze przelane na Y2K były dość przerażające.

Że wszystko inne niż rodzaj wstawiania / bąbelków było po prostu czarną magią.

Ten XML byłby naprawdę interoperacyjnym i czytelnym dla człowieka formatem danych.

To C ++ było w jakiś sposób wewnętrznie lepsze niż wszystkie inne języki.

Otrzymałem to od kolegi kilka lat przede mną na studiach. Trzymałem to przy sobie przez bardzo zawstydzająco długi czas (zarumieniam się teraz). Dopiero po 2 latach pracy z nim mogłem zobaczyć pęknięcia takimi, jakie były.

Nikt - i nic - nie jest doskonały, zawsze jest miejsce na poprawę.

Wierzyłem, że tworzenie programów będzie dokładnie takie, jak to, czego nauczano na zajęciach ... usiądziesz z grupą ludzi, rozwiążesz problem, wymyślisz rozwiązanie itp. Itd. Zamiast tego prawdziwy świat brzmi „Oto mój problem, muszę go rozwiązać, idź ”, a dziesięć minut później dostajesz inny, nie pozostawiając Ci czasu na skuteczne zaplanowanie rozwiązania.

Myślałem, że wzorce głównego nurtu były niesamowite, kiedy zostały wprowadzone w klasie CS. Wcześniej przez 8 lat programowałem jako hobby i tak naprawdę nie rozumiałem, jak tworzyć dobre abstrakcje.

Wzory projektowe przypominały magię; możesz robić naprawdę fajne rzeczy. Później odkryłem programowanie funkcjonalne (przez Mozart / Oz, OCaml, później Scala, Haskell i Clojure), a potem zrozumiałem, że wiele wzorców było po prostu płytkami lub dodatkową złożonością, ponieważ język nie był wystarczająco wyrazisty.

Oczywiście prawie zawsze istnieją jakieś wzorce, ale są one na wyższym poziomie w ekspresyjnych językach. Teraz zajmuję się profesjonalnym kodowaniem w Javie i naprawdę odczuwam ból, gdy muszę zastosować konwencję, taką jak wzorzec gościa lub polecenia, zamiast dopasowywania wzorca i funkcji wyższego rzędu.

Przez pierwsze kilka lat programowania nie złapałem, że 1 Kbyte to technicznie 1024 bajty, a nie 1000. Zawsze byłem trochę zakłopotany faktem, że rozmiary moich plików danych wydawały się nieco odbiegać od tego, czego się spodziewałem być.

Ten warunek sprawdza:

if (condition1 && condition2 && condition3)

są wykonywane w nieokreślonej kolejności ...

Że moje programowanie byłoby szybsze i lepsze, gdybym to wykonał sam.