Myślę, że kluczem do zrozumienia kodu badawczego dla inżynierów oprogramowania przemysłowego jest zaakceptowanie tego, że zazwyczaj nie tworzysz produktu . Nie masz klientów jako takich. Tworzysz oprogramowanie, aby udowodnić swoją rację.

W związku z tym większość kodu, który piszesz jako badacz, jest bardziej zbliżona do jednorazowych prototypów i makiet, które często piszesz (w branży) w wczesne fazy projektu. Jak z pewnością wiesz, nawet w przemyśle te makiety mają zupełnie inne właściwości niż ostateczne oprogramowanie. Przede wszystkim muszą:

• Mieć dokładnie te funkcje, które chcesz pokazać klientowi. Nie więcej, nie mniej. Zwykle wszystkie nudne standardowe funkcje domeny są pomijane.
• Trzeba zrobić szybko . Zarówno Ty, jak i klient wiecie, że prototyp i tak zostanie wyrzucony, więc nie ma znaczenia, czy kod jest możliwy do utrzymania.
• Musi być łatwy w rozbudowie i adaptacji, optymalnie na żywo podczas demonstracji.

Zasadniczo te same właściwości są również przydatne dla większości jednorazowego kodu badawczego. Nie chcesz tworzyć funkcji, których nie potrzebujesz. Nie chcesz tracić czasu na pisanie np. Łatwego w utrzymaniu kodu, jeśli wiesz, że nie będzie on utrzymywany. Chcesz użyć środowiska, które zmniejsza ilość gotowego kodu i konfiguracji, i które być może automatycznie generuje dla Ciebie dużo kodu, który jest „wystarczająco dobry” dla Twojego demonstratora (Ruby on Rails i jego przychodzą mi na myśl funkcje rusztowania).

Postęp w mojej karierze zależy od tego, czy napiszę „zły” kod !?

Nie, to zależy od tego, czy napiszesz kod odpowiedni do celu. Tak jak w przemyśle. W przemyśle i środowisku akademickim nikt nie pochwala oprogramowania, które nie jest potrzebne. Spróbuj ponownie przemyśleć, jaki jest punkt kodu, który piszesz. Jeśli planujesz wydać swój kod jako oprogramowanie typu open source i oczekujesz, że zostanie on odebrany przez inne osoby na całym świecie, to zwariuj - wykorzystaj wszystkie techniki inżynieryjne, które wykorzystałeś również w przemyśle, aby zbudować najlepszy produkt, jaki możesz. Jeśli Twoim celem jest ocena tego jednego algorytmu lub zasady na potrzeby konferencji, a następnie wyrzucenie kodu, możesz również żyć szczęśliwie bez pisania ani jednego testu jednostkowego, nie czując się w ogóle jak oszust.

EDYCJA: oczywiście nie oznacza to, że można pisać kod tam, gdzie nie ma się pewności, czy zaimplementowałeś wspomniany algorytm poprawnie . Upewnienie się, że to, co rzeczywiście pokazałeś, to, co twierdzisz, że pokazałeś, jest obowiązkowe , szczególnie w kodzie badawczym.

Jestem badaczem i programistą-samoukiem. Robiłem duże projekty, które opierały się głównie na oprogramowaniu. Chociaż moja praca jest daleka od najbardziej „hardkorowych” rzeczy, które istnieją pod względem złożoności i skali, projekty były na tyle duże, że naiwne błędy (np. Brak kontroli wersji lub słabo dokumentujący kod) były bardzo bolesne. Skończyło się na tym, że nauczyłem się kilku „najlepszych praktyk” metodą prób i błędów.

Byłem również na końcu „nieobsługiwanego kodu przekazywanego innym badaczom”:

Moje doświadczenie w przemyśle stanowi przeszkodę w moich badaniach

Nie, w zasadzie pochodzisz z cywilizowanego środowiska, które rozwiązało te problemy dziesiątki lat temu taki, który utknął w epoce kamienia łupanego pod względem higieny tworzenia oprogramowania. Naukowcy nadal kodują jak w latach 60. Oczywiście czujesz konflikt, ale wina nie leży po twojej stronie.

W przemyśle kod musi być (idealnie): możliwy do utrzymania, wolny od błędów, refaktoryzowany, dobrze udokumentowany, rygorystycznie przetestowany

Powiedzmy, że prelegent na konferencji naukowej, opisując część obliczeniową swoich badań, powiedział jedno z następujących:

„ Kod, który napisałem ponieważ te badania są, trzeba przyznać, ... "

• ... nie do utrzymania (i powodzenia w budowaniu moich badań!)
• ... pełne błędy (i nie mam pojęcia, czy wynik jest poprawny!)
• ... nieczytelne spagetti (i nawet nie wiem, jak to działa, nie mówiąc już o poprawności!)
• ... nieudokumentowane (a wszystkie błędy są zaciemniane przez recenzentów!)
• ... nie testowane (więc Bóg wie, czy robi to, co mówię / myślę, że robi!)

Czy spodziewasz się, że publiczność zareaguje czymś innym niż pogardą i oburzeniem? Gdybym coś takiego usłyszał, nie uwierzyłbym w nic, co ta osoba kiedykolwiek opublikował.

W środowisku akademickim celem jest (...) w jak najkrótszym czasie.

Tak, ale „ nie krócej ”. Nie pomijasz ważnych eksperymentów kontrolnych, ponieważ „kontrole wymagają czasu”. Nie możesz oszczędzać na jakości kodu z bardzo podobnych powodów.

Wydaje się, że nie ma motywacji do pisania [dobrego kodu]

Ponieważ jest to endemiczny problem środowiska akademickiego. Chociaż komputery są wykorzystywane w nauce od dziesięcioleci, wydaje się, że algorytmy stały się ważną częścią badań dopiero w ostatniej dekadzie (być może z powodu „dużych zbiorów danych”). Kiedy opierasz swoje badania na kodzie, kod ten musi być dobrej jakości. Nie wystarczy po prostu uruchomić jakiś błędny skrypt tylko do zapisu i nazwać go dniem. Społeczność programistów wymyśliła to wszystko dawno temu, ale środowisko akademickie jeszcze się nie zorientowało - myślę, że powodem jest to, że większość naukowców nie ma formalnego doświadczenia w tworzeniu oprogramowania i nie było wystarczająco dużo skandali w badaniach, przez złe praktyki programistyczne (np. kluczowe wyniki głośnego artykułu okazują się artefaktami spowodowanymi błędami).

Zastanów się, jak w wielu dyscyplinach recenzenci nie będą nawet pytać o kod źródłowy twojego papier ciężki obliczeniowo. Jak więc mogą ocenić ważność twoich wyników? Nie mogą i jest to porażka modelu wzajemnej oceny, który obecnie istnieje.

Przepraszam, że kontynuuję rantowanie, ale zasadniczo wygląda to tak: Jak wiesz, istnieją bardzo dobre powody do pisania kod jakości, nawet jeśli nikt nie patrzy Ci przez ramię. W nauce obecnie tak się dzieje, że nikogo nie obchodzi, czy Twój kod jest dobry, czy nie. Ale to nie powinien być powód, dla którego i tak nie powinieneś pisać dobrego kodu - powody pisania dobrego kodu w branży wciąż w dużej mierze dotyczą nauki.

Niestety, możesz nie otrzymać wynagrodzenia za dodatkową pracę. Możesz nawet zostać ukarany, ponieważ, jak mówisz, dobry kod trwa dłużej, a inni mogą nie patrzeć poza to. Twój PI lub koledzy mogą nie rozumieć, dlaczego jesteś o wiele wolniejszy. Najlepsze, co możesz zrobić, to wyjaśnić im potrzebę dobrych praktyk.

Oczywiście są wyjątki. Na przykład możesz nie martwić się o przenośność lub kompatybilność wsteczną ze starymi wersjami systemu operacyjnego dla kodu, który ma działać na dedykowanym komputerze laboratoryjnym (chociaż niepożądane jest pisanie kodu w taki sposób, że działa on tylko w bardzo egzotycznym środowisko, którego inni naukowcy nie będą w stanie łatwo zrekonstruować). Ale ogólnie rzecz biorąc, uważam, że praktyki branżowe nadal obowiązują, a wyjątki można łatwo wykryć, stosując odrobinę krytycznej myśli. To powiedziawszy, istnieje również pomocna publikacja „ Best Practices for Scientific Computing ”, która szczegółowo analizuje tę kwestię.

Ostatecznie jest to etyczna decyzja, którą musisz podjąć. Czy zależy ci przede wszystkim na robieniu dobrej nauki? Postępuj zgodnie z najlepszymi praktykami. Chcesz iść na skróty, których nie powinieneś (w sensie etycznym), zaoszczędzić czas lub uniknąć tarć ze współpracownikami? Z zasady nie mógłbym ci tego polecić. Ale oczywiście wielu ludzi to robi i być może w praktyce niektórzy naukowcy są do tego zmuszani - chociaż z drugiej strony, czy niezdolność do uprawiania dobrej nauki przez okoliczności nie usprawiedliwia złej nauki?

Ponadto, jak powiedziałem, ja Myślę, że część problemu polega na tym, że nie było żadnych wielkich skandali. Jeśli oszczędzisz na jakości kodu, jest szansa, że ​​cię dogoni. Możesz nawet skończyć jako jeden z tych wielkich skandali. Trzeba przyznać, że ryzyko jest prawdopodobnie niewielkie ... Ale myślę, że rozumiesz, o co mi chodzi.

Spędzam zbyt dużo czasu na tworzeniu (niepotrzebnie), aby mój kod „badawczy” był na poziomie przemysłowym

Nie. Zrób to jak najlepiej w sugerowanych ramach czasowych. Dążenie do 100% perfekcji, która wymaga podwójnego czasu, nie jest tego warte. W tym sensie badania są dokładnie takie same, jak w przemyśle.

W rezultacie napisany przeze mnie kod „akademicki” jest słabej jakości.

To nie wszystko kod akademicki jest niskiej jakości. Jeśli przejrzysz artykuły na temat konferencji algorytmów lub systemów przetwarzania równoległego, zobaczysz, że programiści pomyśleli nawet o dręczących szczegółach, takich jak zmiana kolejności danych w celu zmniejszenia liczby braków w pamięci podręcznej, SIMD, programowanie GPU, pamięć SSD itp. Zazwyczaj zaawansowane badania nad algorytmami CS trwają kilka lat. przodują w przyjmowaniu nowych metod, technik sprzętowych, zanim którakolwiek z tych technik faktycznie trafi do branży. Z drugiej strony, w bardziej teoretycznych konferencjach CS kod jest głównie narzędziem i jako taki nie musi być nowatorski. Tak więc jakość jest związana z odbiorcami kodu produktu (dokładnie tak, jak w branży).

Czy ktoś zna formalne metodologie kodu „badawczego”?

Nigdy nie słyszałem o metodach specjalnie dostosowanych do kodu badawczego. Mimo to możesz wykorzystać praktyki z Twojej branży (kiedy faktycznie przyspieszają one proces pisania oprogramowania). Na przykład system wersjonowania przyspiesza rozwój i minimalizuje błędy / straty danych. Z drugiej strony testy UNIT zajmują dużo czasu, którego możesz nie mieć. Nieformalna wiki dotycząca błędów, dokumentacji, funkcji może być warta dodatkowego czasu, ponieważ przyspiesza również pisanie właściwej pracy naukowej. Wręcz przeciwnie, pełna baza danych błędów (bugzilla) może nie być warta dodatkowego czasu i wysiłku.

Tak więc, trzymaj się tych metod branżowych, technik, które znasz, pozwolą Ci zaoszczędzić czas na dłuższą metę i ulepszą oprogramowanie, ale bez zajmowania całego czasu. Znalezienie kompromisu jest zawsze najlepszym rozwiązaniem.

tl; dr Niektóre części „najlepszych praktyk” branżowych dobrze pasują, a inne są nieefektywne w środowisku badawczym. Zachowaj to, co działa dobrze w tym środowisku.

Jestem eksperymentalnym fizykiem cząstek elementarnych i piszemy dużo kodu, a większość z nich to duże projekty napisane przez wielu , rozproszeni programiści.

Część zwykłego zestawu narzędzi branżowych, którego używamy entuzjastycznie.

• Kontrola wersji
• Śledzenie błędów
• Zautomatyzowane systemy budowania i testowania

Inne części są albo wolniejsze, albo mniej cenione, w tym

• Formalny proces (z duże „P”) z regularnymi spotkaniami dotyczącymi planowania, listą kontrolną wydania i tak dalej. Pojawiają się one, gdy projekty stają się większe (zwykle w odpowiedzi na całkowity brak kontroli jakości lub długie opóźnienia w wydaniu). Oznacza to, że używamy ich, gdy potrzebujemy ich.

• Systemy generowania dokumentacji są dość powszechne, ale rzadko używane, dopóki projekt nie stanie się duży, gdy ludzie, którzy są zmuszeni dekodować niektóre bity często dostarczają trochę więcej dokumentacji.

• Testy jednostkowe są rzadkie i zwykle koncentrują się na niższych warstwach systemów, ale testy regresji są bardziej powszechne.

• Większość projektów ma standardy kodowania, ale generalnie są one luźno określone i słabo egzekwowane.

Inne proste rzeczy nie pojawiają się często.

• Planowanie funkcji jest dość trudne, gdy nie wiesz, jakie sprytne pomysły ma absolwent w przyszłym tygodniu , aby rozwiązać problem, jeszcze nawet nie zauważyłeś.

• Kiedyś było prawdą, że ścisła kontrola zaewidencjonowania przeszkadzała w rozprzestrzenianiu eksperymentalnych segmentów kodu i po prostu od czasu do czasu zamrażaliśmy nowe check-iny, aby wydać błogosławioną wersję renderowane HEAD / trunk / cokolwiek jako propozycja „używaj na własne ryzyko”). Wraz z pojawieniem się rozproszonej kontroli wersji zaczyna być coraz większe zaangażowanie w kontrolę odprawy dla oficjalnego łącza.

• Refaktoryzacja zwykle ma miejsce tylko gdy nowa osoba zaczyna pracować z jakimś starym kodem i czuje, że potrzebuje zmian lub rozszerzeń. To, co nie jest zepsute, pozostaje w spokoju.

Na podstawie twojego pytania podejrzewam, że kodujesz samodzielnie lub w małej grupie . W tym ustawieniu szczegóły się zmieniają, ale ton pozostaje ten sam. Po prostu zachowaj te części swojej praktyki branżowej, które działają, i zrezygnuj z części, które mają najgorszy stosunek kosztów do korzyści pod względem czasu / wyników.

Zostaw ciężką refaktoryzację do czasu wiedzieć z dowodów, że określona część twojego kodu zostanie ponownie wykorzystana. Podobnie, zadowalaj się przybliżoną dokumentacją, chyba że okaże się, że kod ma ciągłe życie. I tak dalej.

Główną cechą kodu badawczego (bardziej niż typowych programów) jest to, że trudniej go zaplanować. Badania z definicji sięgają w nieznane, co przekłada się również na struktury programowe. Jako badacz często nie masz czasu na refaktoryzację, gdy twoje badania idą w innym kierunku, co powinno przełożyć się na inną strukturę oprogramowania.

W typowej inżynierii oprogramowania (powinieneś) mieć dość dobry pomysł ostatecznej funkcjonalności przed napisaniem pojedynczej linii kodu. W badaniach często tak nie jest. Programowanie do celów badawczych polega głównie na szybkim prototypowaniu, które jest zwykle wykonywane inaczej niż programowanie do długotrwałego użytku (np. Mało testów jednostkowych lub brak testów jednostkowych, użycie różnych języków, ...). Główną mantrą jest uzyskanie wyników szybko, a nie optymalnych z punktu widzenia inżynierii oprogramowania.

Wreszcie, właściwa inżynieria oprogramowania to sztuka, która jest bardzo trudna do opanowania. Nawet w środowisku przemysłowym jest mnóstwo brzydkiego oprogramowania (napisanego przez profesjonalistów!). Przeciętny badacz nie ma formalnego wykształcenia w zakresie pisania oprogramowania.

Postęp w mojej karierze zależy od tego, czy piszę „zły” kod !?

Jako badacz, nie dostajesz wynagrodzenia za tworzenie oprogramowania (niestety). Jako idealista lubię wierzyć, że to się zmieni z czasem, ale na razie źródła finansowania zajmują się tylko papierami.

„Rzemiosło” tworzenia oprogramowania to ogromny temat - ale gdzie jest najlepsza praktyka w badaniach naukowych? Nikt nie pisze testów jednostkowych dla papierowego kodu konferencji!

Testy jednostkowe służą dwóm głównym celom: (i) stwierdzenie, że kod działa poprawnie oraz (ii) szybkie znajdowanie i debugowanie problemów, szczególnie po zmianach strukturalnych i refaktoryzacji (długoterminowe korzyści dla dużych infrastruktur). Ponieważ oprogramowanie badawcze jest zwykle dość małe, pierwsza zaleta jest jedyną, która jest naprawdę istotna. Wygląda na to, że ta przewaga jest albo zbyt mała, albo niedoceniana (jeszcze raz przypomnijmy, że większość badaczy nie jest inżynierami oprogramowania).

Czy ktoś znajduje ich w podobnych sytuacja? Czy ktoś zna formalne metodologie kodu „badawczego”?

Jeśli chcesz zmienić świat, zacznij od siebie. Osobiście staram się dostarczać oprogramowanie wraz z manuskryptem, gdy jest to uzasadnione. Jako recenzent konsekwentnie proszę o kod, choć wydaje się to rzadkie.

Myślę, że Twoim problemem jest postrzeganie jakości jako binarnych.

Niezależnie od tego, czy w przemyśle, czy w środowisku akademickim musimy dokonywać wyborów dotyczących określonych celów jakościowych. Oprogramowanie „przemysłowe” może mieć krytyczne znaczenie dla bezpieczeństwa i wymagać najwyższego osiągalnego poziomu jakości lub może być narzędziem programistycznym używanym wewnętrznie.

Cele jakościowe mogą obejmować:

• Dostępność
  
  • Prawdopodobnie nie dotyczy Ciebie
• Solidność
  • Czy będziesz musiał korzystać z wielu różnych zestawów danych, czy jest to jednorazowe?
• Możliwość ponownego użycia
  • Czy przetwarzanie zostanie włączone do następnego problemu, nad którym będziesz pracować?
• Możliwość weryfikacji
  • Czy działa tak, jak powinno do? Co by to oznaczało, gdybyś opublikował, a to nie była prawda?
• Możliwość weryfikacji
  • Czy daje właściwą odpowiedź? [Miejmy nadzieję, że to ma znaczenie. ]
  • Inny sposób sprawdzenia poprawności odpowiedzi może oznaczać, że nie ma znaczenia, czy logika jest błędna.
• Musi być utrzymywalna autor:
  • Ja
  • Inny ekspert
  • Jakiś przypadkowy student
  • Lub na pewno jest wyrzucony.
• Odpowiednie do upublicznienia do użytku przez innych w celu sprawdzenia lub ponownego wykorzystania Twojej pracy.
• Etc.

Po sformułowaniu celów jakościowych, Twój rozwój a system budowania powinien być wystarczający, aby osiągnąć te cele i nic więcej. Zauważ, że może się to różnić w zależności od projektu.

Zamiast mówić o różnicach w tworzeniu oprogramowania branżowego (z czym nie mam doświadczenia), chciałbym porozmawiać o rzeczach, które powinieneś robić w środowisku akademickim. Zakładam, że twój kod nie istnieje sam w sobie, ale jest dołączony do pewnego stwierdzenia naukowego, takiego jak „E. coli dzieli genom foo z ludźmi” lub „Algorytm A przewyższa algorytm B w scenariuszu Z”.

• Najlepszy wysiłek

  Chociaż Twoim celem nie jest produktywne wykorzystanie i związane z nim przychody, powinieneś mieć uzasadnioną pewność, że Twój kod nie co twierdzisz i które mogą być zrozumiane (recenzowane!) przez zainteresowane strony. Oznacza to, że napisz jasny kod, skomentuj i udokumentuj. I test (jednostkowy).

  Jeśli nic więcej, pamiętaj, że Ty być może będziesz musiał ponownie odwiedzić swój własny kod jakiś czas później. Budujesz prototyp, ale następny może ponownie wykorzystać jego części. Lub chcesz, aby uczniowie go rozszerzyli.

• Dostępność

  Aby wesprzeć naukową ocenę Twojej pracy (falsyfikowalność, odtwarzalności) inni badacze muszą być w stanie skompilować i uruchomić twoje programy.

  Dlatego powinieneś zapewnić źródła, pliki / instrukcje kompilacji i wszelkie dane wejściowe, których użyłeś w swoim praca. Należy pamiętać, że ktoś może chcieć zbudować Twój program lata po pierwszej publikacji, więc upewnij się, że źródła wciąż są dostępne, a proces / instrukcje kompilacji są wystarczająco solidne w czasie (wspomnij o wersjach bibliotek). Interfejs użytkownika nie jest zbyt ważny, ale tutaj też obowiązuje zasada „najlepszych starań”.

  Rozważ umieszczenie kodu na Github lub podobnej platformie (np. własnej ). W ten sposób możesz łatwo publikować aktualizacje i zbierać błędy. Zobacz także tutaj i tutaj.

• Licencjonowanie

  Powinieneś coś powiedzieć o tym, co inni (w szczególności koledzy badacze) mogą, a czego nie mogą zrobić z Twoim kodem. Możesz użyć dowolnej licencji (uważam, że powinna ona zezwalać przynajmniej na swobody GPL). Warto zajrzeć do CRAPL.

• Rzetelna ocena

  Jeśli Twój algorytm / kod to artefakt, który proponujesz (jako lepszy), musisz porównać go z istniejącymi rozwiązaniami. Upewnij się, że używasz porównywalnych danych wejściowych, powtórz eksperyment w celu znalezienia alternatyw i postępuj zgodnie z podstawowymi najlepszymi praktykami eksperymentalnymi (sprawdź na przykład pracę McGeocha). Upewnij się, że twoje porównanie zawiera akceptowany standard (y) twojej dziedziny, jeśli takie istnieją; jeśli twoje podejście daje różne wyniki, musisz wyjaśnić dlaczego (to w porządku / poprawne / lepsze).

Dostępność jest prawdopodobnie najważniejszą kwestią. Kod badawczy musi zostać udostępniony. Myślę, że nie można tego wystarczająco podkreślić i jest to jeden z głównych problemów w całej nauce obliczeniowej. Oprócz, powiedzmy, fizyki, mamy możliwość łatwego udostępniania i odtwarzania (większości) konfiguracji eksperymentalnej - musimy to wykorzystać.

Osobiście nie rozumiem, dlaczego jakikolwiek artykuł jego twierdzenia dotyczące obliczeń, których recenzenci (i inne strony) nie mogą powielać, mają prawo do publikacji.

Jedno przypomnienie dla wszystkich typów teorii:

Uważaj na błędy w powyższym kodzie; Tylko udowodniłem, że to prawda, a nie próbowałem.
_{Donald E. Knuth}

Gdybym mógł dodać krótką wersję dokładniejszych odpowiedzi powyżej, powiedziałbym:

• Academia -> prototypy.
• Przemysł -> produkty.

Produkty i prototypy nie mogą być traktowane zgodnie z tymi samymi standardami.

Prototypy mogą mieć krótszą dokumentację i ich wdrożenie może wymagać pewnego wysiłku. Mogą być również używane w pojedynczym systemie operacyjnym z bardzo określonymi wymaganiami, takimi jak te, w których kod został początkowo opracowany.

Niemniej jednak prototypy dobrej jakości powinny być testowane, kontrolowane przez wersje, mieć stabilną gałąź i nie może zawierać nieaktualnej dokumentacji. W przeciwnym razie są to tylko prototypy złej jakości.

---- Edytuj

Postęp w mojej karierze zależy od tego, czy napiszę „zły” kod !?

Odejście ze środowiska akademickiego przypomniało mi, że istnieje coś innego niż metoda pracy zorientowana na papier, do której szkoleni są doktoranci (a której wyniki często mają mniejszą liczbę czytelników niż liczba współautorów).

Może nie ma to miejsca w każdym środowisku akademickim, chociaż z mojego doświadczenia wynika, że ​​badania z kryteriami naukowymi są prowadzone w sektorze prywatnym.

Poza tym nie jest to tylko problem związany z kodowaniem!

Niektórzy badacze pracujący w wilgotnych laboratoriach powiedzieli mi, że mają dokładnie ten sam problem. Wykonywanie eksperymentów mokrego laboratorium dokumentujące pełną procedurę, kalibracja narzędzi do najwyższych standardów, ocena składu chemicznego materiału zakupionego przez osoby trzecie jest spójna w czasie, dzięki czemu każdy krok jest w pełni odtwarzalny przez innego badacza ... te podstawowe praktyki zaowocowały zbyt wolna produkcja artykułów naukowych.

Zostałem skierowany do tego pytania przez gościa w odpowiedzi na moją prośbę o wyjaśnienie „Dlaczego używali typu float jako klucza do hasha”. Otóż, nie wydawało mi się to dobrym pomysłem. Po kilku chwilach pytający skierował mnie tutaj jako powód, dla którego to zrobili.

To było interesujące, podobnie jak samo pytanie.

Czy jesteś przekonany do napisania złego kodu, aby osiągnąć określone cele akademickie? Tak, nawet na kursach CS mogę dodać. Przynajmniej źle pod względem zrozumiałości. Jednakże, jak wszyscy jesteśmy zbyt przerażająco świadomi, zostaliśmy „przekonani” do napisania równie złego kodu w środowisku komercyjnym lub nasi panowie i mistrzowie zostali przekonani, że napisali dla nich kiepski kod .... > Pomijając trywialne implementacje algorytmów. Na przykład, czy powinieneś używać i i j jako zmiennych pętli w algorytmie sortowania bąbelkowego, czy też w ogóle powinieneś używać sortowania bąbelkowego. Moja odpowiedź na twoje pytanie byłaby inna. W jaki sposób dobre zasady inżynierii oprogramowania pomagają osiągnąć cele?

Czy, powiedzmy, dobre nazewnictwo, SOLIDNE zasady, spójność i sprzężenie itp. Pomogą Ci skuteczniej osiągnąć cel? Moja odpowiedź byłaby prawie na pewno. Są przeznaczone do tego w każdym nietrywialnym oprogramowaniu. Po to są, zostały stworzone w celu uzyskania oprogramowania, które można zmienić mniejszym kosztem. Nie ma znaczenia, że ​​nie jesteś (lub przynajmniej nie możesz przewidzieć) wersji drugiej, implementacja nie wyskakuje z twojego umysłu, więc to się zmieni.

Jeśli tak nie jest Jeśli masz pewność, jaki kod musisz napisać, coś takiego jak TDD również pomogłoby, biorąc pod uwagę gotowe środowisko do testów jednostkowych. Nawet bez tego „luksusowego” pisania testowalnego kodu będzie.

Masz ogromną przewagę nad kolegami, którzy nie mają doświadczenia w inżynierii oprogramowania, powinieneś być w stanie szybciej usunąć ten irytujący binarny fragment ćwiczenia, dotrzeć do celu przy mniejszym wysiłku a potem być w stanie włożyć więcej wysiłku w osiągnięcie prawdziwego celu.

Kiedyś rozmawiałem z typem posiadającym kwalifikacje akademickie, który powiedział mi, że re-factoring to po prostu majstrowanie przez estetów oprogramowania i że powinienem był napisać oprogramowanie poprawnie. Nie trzeba dodawać, że mój szacunek dla tej osoby spadł o jeden stopień lub dwa, co było dla niego niefortunne, ponieważ nie zarobił tak dużo.

Podsumowując, powiedziałbym, że rozsądną opcją byłoby użycie dobrych praktyk inżynierii oprogramowania we wszystkich swoich wysiłkach. Żeby było jasne, że pisanie dobrego kodu, którego nie potrzebujesz, nie jest dobrą praktyką inżynierii oprogramowania ...

Parafrazując Gandalfa: „Uprość to, zachowaj bezpieczeństwo”

Jeśli chodzi o to, czy jako klucz do hashowania należy używać float, aby zaoszczędzić czas. Jeśli bez wątpienia wiesz, wybierając ten kompromis projektowy, że problemy z tym nie spowodują problemu, to być może. Ale ilość wysiłku potrzebnego do uniknięcia tego kompromisu jest dość trywialna i po prostu spędziłeś czas na pytaniu, jak rozwiązać problem z użyciem pływaka jako klucza. Odpoczywam

W każdym środowisku komercyjnym lub akademickim wybór niższej jakości jest zarówno korzyścią, jak i kosztem, zbadaj oba ....

Mam problem z przesłanką pytania:

W środowisku akademickim celem jest napisanie jak największej liczby wysokiej jakości artykułów naukowych w jak najkrótszym czasie.

Wydaje się, że nie ma motywacji do pisania przetestowanego, możliwego do utrzymania, udokumentowanego kodu - wystarczy go uruchomić i jak najszybciej uzyskać wynik w mojej pracy lub czymkolwiek innym

Obecnie mam do czynienia z dużym kod źródłowy napisany przez ludzi, którzy najwyraźniej też tak myśleli. Wcześniej przyzwyczaiłem się do innego standardu kodowania akademickiego - takiego, w którym kod jest prosty, elegancki, nowoczesny, dobrze przetestowany i dobrze utrzymany przez wiele lat.

I wierzę, że ludzie, którzy będą mieli Wpływ w tej erze informacji niekoniecznie to ci, którzy mają największe zasługi naukowe, ale ci, którzy mogą coś zrobić ze swoich fajnych pomysłów naukowych.

Jeśli jednak w twojej domenie fajne rzeczy, które możesz zrobić, nie W ogóle nie zależy od kodu, który napiszesz (np. tylko nudnego filtrowania danych), wtedy naprawdę nie musisz przejmować się jego jakością.