Czy „nie wymyślaj koła ponownie” ignoruje granice ludzkiej pamięci?

Jedną rzeczą, która pracowała w Haskell i F #, nauczyło mnie, że ktoś na uniwersytecie mądrzejszym ode mnie prawdopodobnie już znalazł abstrakcję tego, co robię. Podobnie w języku C # i programowaniu obiektowym, prawdopodobnie jest biblioteka do „it”, cokolwiek to robię.

Nacisk na ponowne wykorzystywanie abstrakcji w programowaniu jest tak duży, że często mam dylemat między: 1) po prostu kodowaniem czegoś krótkiego i brudnego lub 2) spędzaniem tego samego czasu na szukaniu bardziej niezawodnej biblioteki / rozwiązania innej osoby i po prostu z tego korzystaniem.

Tak jak ostatnio jeden z programistów napisał (de) serializator dla plików CSV, i nie mogłem nie myśleć, że coś takiego jest prawdopodobnie bardzo łatwe do znalezienia w Internecie, jeśli nie jest ono dostarczane ze standardem .NET Pszczoła.

Nie obwiniam go jednak, kilka razy pracując w .NET, założyłem rozwiązanie oparte na tym, co wiem, tylko po to, aby zdać sobie sprawę, że było jakieś wywołanie metody lub obiekt lub coś , często w tej samej bibliotece, które robiło to, co Chciałem i po prostu o tym nie wiedziałem.

Czy to tylko oznaka braku doświadczenia, czy zawsze istnieje element kompromisu między pisaniem nowego a ponownym wykorzystywaniem starego? Najbardziej nienawidzę tego, kiedy natrafiam na rozwiązanie, o którym już wiedziałem i o którym zapomniałem. Wydaje mi się, że jedna osoba po prostu nie jest w stanie przetrawić ogromnej ilości kodu, który jest obecnie pakowany w większość języków.

Najpierw musisz nauczyć się identyfikować „komponenty”, które są na tyle ogólne / wielokrotnego użytku, że biblioteka lub rozwiązanie innej firmy prawdopodobnie już istnieje. Gdy to zrobisz, zdaj sobie sprawę, że nawet jeśli jesteś dobrym programistą, zbiorowe doświadczenie niezliczonych programistów spędzających niezliczone godziny na tym samym problemie prawdopodobnie stworzy rozwiązanie lepsze niż kiedykolwiek będziesz w stanie zrobić. Nie oznacza to, że nigdy nie powinieneś „wymyślać koła na nowo”, ale jeśli zdecydujesz się to zrobić, lepiej mieć dobre uzasadnienie DAMN.

Nacisk na ponowne wykorzystywanie abstrakcji w programowaniu jest tak duży, że często mam dylemat między: 1) po prostu kodowaniem czegoś krótkiego i brudnego lub 2) spędzaniem tego samego czasu na szukaniu bardziej niezawodnej biblioteki / rozwiązania innej osoby i po prostu z tego korzystaniem.

Warto wspomnieć, że nawet jeśli znalezienie istniejącej biblioteki / rozwiązania zajmuje tyle samo czasu, co samodzielne napisanie, pamiętaj, że zrobienie tego samemu oznacza również, że będziesz musiał zachować go na zawsze . Nie tylko wymyślasz na nowo koło, ale także całą ekipę, aby utrzymać go w ruchu. Oczywiście niektóre biblioteki są wadliwe lub źle utrzymane, ale o tych sprawach należy pamiętać przy wyborze rozwiązania innej firmy.

Czasami jest to znak braku doświadczenia, czy to w danym języku, czy w ogóle w programowaniu. Czasami jednak, jeśli dopasowanie nie jest oczywiste, po prostu lepiej jest stworzyć własny kod, który robi dokładnie to , co chcesz i nic więcej . Biblioteki ogólne, choć często przydatne, można budować pod kątem wymagań, których po prostu nie masz, aw niektórych przypadkach ten poziom ogólności może sprawić im więcej kłopotów, niż są warte.

Przykład: W przypadku moich małych jednoosobowych projektów nigdy nie używam „prawdziwej” biblioteki rejestrowania. Używam printinstrukcji i trochę konfiguracji ad-hoc. Nie chcę się przejmować konfigurowaniem i konfigurowaniem biblioteki rejestrowania, która ma o wiele więcej funkcji niż kiedykolwiek będę używać, gdy printinstrukcje działają dobrze dla moich celów. Nie chcę też innej zależności, która może nie być kompatybilna z wersją kompilatora / interpretera, której chcę używać, musiałaby być rozpowszechniana itp.

Witamy w świecie programowania. Ta kwestia będzie przedmiotem wielu sporów między tobą a twoimi przyszłymi kolegami. Masz dwie opcje:

1. Skręć swój własny.
2. Zbuduj coś na czyimś rozwiązaniu.

Myślę, że są chwile, w których oba rozwiązania są odpowiednie. Na przykład wolałbym unikać rzucania własnym parserem ORM CSV, jeśli mogę tego uniknąć głównie dlatego, że jest to dość żmudna praca. Z drugiej strony biblioteki są często ograniczone. Powiedziałbym, że przy każdym projekcie, nad którym pracowałem, napotkałem biblioteki, które idealnie rozwiązałyby mój problem, jeśli nie ten jeden brak. Lub czasami biblioteka jest dokładnie tym, czego potrzebujesz, gdy zaczynasz coś robić, ale jest bardziej szkodliwa niż pomoc, gdy musisz wprowadzić zmiany.

Ogólnie jednak odradzam próbowanie znalezienia „poprawnych” odpowiedzi, ponieważ nie istnieją. W razie wątpliwości idź z jelitami. Kiedyś słyszałem, jak ktoś powiedział, że doświadczenie określa liczba głupich błędów, które popełniasz. Zwykle więc albo się czegoś nauczysz, albo stworzysz coś, co działa. Tak czy inaczej, nie jest tak źle.

Ta (lub podobna rzecz) często zdarzała mi się podczas poprzedniej pracy, w której ramy cierpiały na ciężki efekt platformy wewnętrznej.

Zasadniczo ich baza kodu ewoluowała od wczesnych dni Windows C / C ++, a następnie zaczęła być kompilowana pod MFC - tak więc opiekunowie zaczęli mieszać MFC i ich stare wewnętrzne struktury danych i elementy okienkowe. Wewnętrzna platforma nie była zbyt dobrze udokumentowana, ale podobno była to „Droga” do robienia rzeczy na tym produkcie, ze względu na niektóre wewnętrzne udogodnienia, które zapewniała. Często łatwiej i szybciej pisałem własne rzeczy od zera (z podstaw MFC), zamiast wymyślić, jak to zrobić za pomocą wewnętrznych ram firmy.

(Okej, więc wydaje się, że jest to prawie przeciwieństwo twojego początkowego punktu - ale zasada jest taka sama, hehe! Tak, czasami naprawdę szybciej jest robić własne rzeczy niż tracić czas i wysiłek, aby znaleźć istniejący do ponownego użycia rozwiązanie.)