Tak, powinieneś.

Po pierwsze, większość programów naukowych jest okropna. Byłbym bardzo zaskoczony, gdyby twój był gorszy od średniej: sam fakt, że znasz wzorce projektowe i różnicę między rekurencją a pętlami, sugeruje, że jest lepiej.

Po drugie, jest mało prawdopodobne, że będziesz miał motywację lub motywację aby było lepiej, chyba że lub do czasu, gdy będzie potrzebne komuś innemu (lub Tobie za 6 miesięcy). Otwarcie go dodaje tej zachęty.

Potencjalne korzyści: potencjalni nowi współpracownicy, poprawki błędów, rozszerzenia, publikacje.

Potencjalne wady: timeink (utrzymanie kodu lub naprawianie problemów dla innych osób), zdobywanie. Powiem jasno: żadnej z tych wad nie traktuję zbyt poważnie.

Posprzątam trochę i udostępnię. Przez lata wydałem dużo kodu, ale nie wypuściłem kodu z powodów, które podałeś.

Przejrzyj go i skomentuj na dowolnym możliwym poziomie. Zostaw „nieudane próby” i skomentuj je jako takie. Powiedz, dlaczego się nie udało i czego próbowałeś. To jest BARDZO przydatna informacja dla osób, które będą cię ścigać.

Utwórz plik README, który mówi, że udostępniasz go na żądanie w nadziei, że komuś pomoże. Powiedz, że wiesz, że kod jest brzydki, ale masz nadzieję, że i tak będzie przydatny.

Zbyt wiele osób wstrzymuje się od rzeczy, ponieważ nie jest idealny!

Tak! Zwłaszcza jeśli twój papier jest np. o nowym / ulepszonym algorytmie, który zaimplementowałeś, lub przeprowadzasz znaczącą, niestandardową analizę danych lub w zasadzie wszystko, w czym odtworzenie wyników oznacza ponowne wdrożenie oprogramowania.

Artykuły rzadko mają miejsce, aby dać więcej niż zarys. Wiem, że spędziłem (= straciłem) zbyt dużo czasu próbując wdrożyć algorytmy z artykułów, które pominęły krytyczne (ale nie ściśle związane z artykułem) szczegóły.

¿Myślisz, że Twój kod jest niechlujny? Widziałem (i próbowałem pracować) kod, który przyniósł mi koszmary:

• Pięć poziomów zagnieżdżonych if True , rozrzuconych w losowych miejscach w kodzie.
• Utwórz tablicę zer, zamień ją na stopnie, weź cosinus iz powrotem na radiany. Następnie odrzuć wynik.
• W przypadku intensywnie rozwijanego oprogramowania lista „obsługiwanych architektur” jest tak stara (a oni sami mówią), że trudno byłoby dostać w swoje ręce jeden z tych komputerów obecnie.
• Funkcje zepsute lub zmodyfikowane kilka wersji temu, nadal zalecane w dokumentach.
• Kod, który przechodzi od użycia standardowego wejścia formatu do własnego formatu. Jak to wygenerować? Nikt tak naprawdę nie wie, a programiści przekazują odpowiedź.
• Wersje, które nawet się nie kompilują. (Czy w ogóle to przetestowałeś?)
• Menu GUI, do których masz dostęp w określonej kolejności. W przeciwnym razie pojawi się błąd segmentacji i będziesz musiał zacząć od początku.
• Zakodowane na stałe ścieżki rozproszone w kodzie. Musisz więc przejść przez kilka plików, znajdując i zmieniając wszystkie wystąpienia / home / someguy / absurd_project / working / na swoje.

I mój ulubiony , pewien program składający się z tysięcy wierszy kodu, używał tylko komentarzy do eliminacji losowych fragmentów kodu, z wyjątkiem jednego:

Tutaj uderzamy w karty.

Nadal nie mam pojęcia, co robił.

A to pozostawia tylko poza klasycznymi dobrymi praktykami, jak jednoliterowe zmienne w całym kodzie, algorytmy nieokreślone nigdzie ...

Jeśli martwisz się jakością swojego kodu, prawdopodobnie oznacza to, że zależy Ci na tym, aby był lepszy od średniej. Jeśli zaczekasz, aż kod będzie czysty, może on nigdy się nie wydostać, a Twój wkład naukowy zostanie częściowo utracony.

Moim zdaniem najważniejsze rzeczy, którymi powinieneś się przejmować, to:

1. Formaty wejściowe i wyjściowe. Używaj standardów, jeśli są dostępne, a jeśli nie, uprość to. Uprość używanie programu jako czarnej skrzynki.
2. Skomentowane. Krótki opis funkcji, szybki przegląd algorytmu.
3. Czytelność. Używanie idiomatycznego kodu, dobre nazwy zmiennych ...
4. Struktura. Jest to łatwiejsze, gdy wiesz, co chcesz zrobić, co zwykle nie ma miejsca w kodzie badawczym. Tylko jeśli społeczność jest zainteresowana, możesz rozważyć jej refaktoryzację.

Tak więc, wypuszczaj swoje oprogramowanie, gdy tylko masz 1 (2 i część 3 powinny pojawić się w trakcie pisania) .

Pytasz, czy udostępnianie oprogramowania niskiej jakości nie zrobiłoby o Tobie złego wrażenia. Myślę, że udostępnianie oprogramowania w ogóle daje dobre wrażenie.

1. Jako informatyk lubię, gdy koledzy udostępniają swój kod źródłowy. To sprawia, że ​​bardziej prawdopodobne jest, że zajrzę głębiej do ich pracy, może się z nimi skontaktować, może zacytować, ponieważ jest jeszcze jeden artefakt do interakcji (nie tylko papier, ale także kod).

2. Kiedy artykuł informuje o wyniku „udowodnionym” przez kod źródłowy, ale kod źródłowy nie jest publiczny, często zastanawiam się, czy wynik jest prawdziwy. Spojrzenie na kod źródłowy (lub tylko dostępność kodu źródłowego bez patrzenia na niego) może mnie przekonać.

Udostępnianie kodu źródłowego, okropne czy nie, zawsze dałoby mi o tobie dobre wrażenie.

Teraz, jeśli chcesz zrobić jeszcze większe wrażenie, pomogłoby ...

... jeśli zareagujesz na problemy lub pociągniesz żądania ze strony takiej jak github, to znaczy, gdy widzę, że inni próbują się z tobą skontaktować, a ty reagujesz.

... jeśli twój kod zawiera plik readme, który odnosi roszczenia z twojego artykułu do źródła kod. W ten sposób, gdy przeczytam artykuł i chcę dowiedzieć się więcej, mogę skorzystać z pliku readme, aby przeskoczyć w odpowiednie miejsce w kodzie. Typowe zwroty z takiego pliku readme mogą brzmieć: „Algorytm z rozdziału 3.2 artykułu znajduje się w pliku algorytm / nowa wersja / powiązane / secondtry / foo.c” lub „Aby powtórzyć przebieg z małym zestawem danych opisanym w punkcie 2 papier, biegnij, wykonaj; make second_step; foo_bar_2 datasets / christmas.dataset. Ten bieg na moim laptopie zajmuje około 2 dni ”.

Może Cię również zainteresować CRAPL (Community Research and Academic Programming License) Matthew Mighta, dostępny pod adresem http://matt.might.net/articles/crapl/. Zawiera on sformułowanie: „Zgadzasz się chronić Autora od wstydu, zażenowania lub ośmieszenia za wszelkie włamania, kłopoty lub skoki wiary znalezione w Programie”. Nie jest dla mnie jasne, czy ta „licencja” ma jakikolwiek skutek prawny, ale cel jest jasny: wypuść swój brzydki kod i nie myśl źle o brzydkim kodzie innych.

W związku ze stykami, opiszę, jak udostępniać oprogramowanie, biorąc pod uwagę Twoje obawy (a nie powinieneś udostępniać oprogramowanie, na które masz już odpowiedź).

Umieszczenie nieudanych prób w kontroli wersji oznacza, że ​​nikt ich nigdy nie zobaczy. Sposób, w jaki sobie z tym radzę, polega na umieszczaniu każdej próby w metodzie, a każda nieudana próba w oddzielnej metodzie:

  def main (): get_foobar (x, y) def get_foobar (): return x ** ydef get_foobar_legacy_1 (): "" "Ta próba nie zadziałała dla wartości > 100" "" return x + ydef get_foobar_legacy_2 (): "" "Ta próba nie zadziałała w środy we wrześniu" "" return x - y  

Zgodnie z komentarzami poniżej, może to być dobrym pomysłem jest umieszczenie tych metod w osobnej klasie FailedAttempts lub BadIdeas. Ma to ładny efekt w postaci podziału poszczególnych etapów procesu zgodnie z rzeczywistą potrzebą. Uważam, że programiści komputerowi często mają talent do tego, kiedy przełamać logikę do metody, a kiedy nie, ale naukowcy komputerowi często tego nie robią. Takie podejście pomaga informatykom przełamać metodę, gdy jest to konieczne.

Oczywiście powinieneś udostępniać kod źródłowy.

Z naukowego punktu widzenia wynik oparty na oprogramowaniu przy użyciu kodu, który nie jest łatwo dostępny, nie jest zbyt wartościowy, ponieważ w jaki sposób inni ludzie mogliby w razie potrzeby zweryfikować twoje twierdzenia? Czy spodziewasz się, że będą samodzielnie programować w tym celu? Udostępnianie tylko plików binarnych jest znacznie mniej wartościowe i często prowadzi do koszmarów dla osób próbujących je uruchomić.

Myślę, że powinieneś się tym podzielić. Przede wszystkim należy wykonać podstawowe czynności porządkowe. (np .: brak wcześniejszego kodu, który nie jest już używany; brak kodu w komentarzu; prawidłowy sposób komentowania itd.) Ponadto, jeśli umieścisz w kodzie coś do zrobienia, inni zobaczą, że skończył Ci się czas twoje intencje. (np .: todo: to powinno zostać zmienione na wyliczenie) Myślę też, że powinieneś udostępniać najważniejszą część swoich algorytmów. Kiedy udostępniam kod, nigdy nie udostępniam nieistotnych części. Każdy może obsłużyć odczyt / zapis plików, komunikację między wątkami, GUI i tak dalej. Ale nie udostępniaj nieczytelnego kodu. To nie miałoby sensu. Więc myślę, że środkowa droga jest najlepsza tyle razy. :-)

Porozmawiaj z niektórymi profesorami na wydziale informatyki. Sprawdź, czy któryś z nich szuka projektu, w którym uczniowie mogą wyczyścić niechlujny kod, aby był bardziej reprezentacyjny.

Dla uczniów, którzy poprawią kod, może to być dobre doświadczenie edukacyjne. Co się dzieje, gdy programiści programują z nastawieniem na wyniki - lub tylko na wynikach? Widzą to z pierwszej ręki. Mogą również zastosować niektóre z najlepszych praktyk, o których się uczyli. Mogą też być zmotywowani do wykonania szczególnie dobrej pracy, wiedząc, że inni specjaliści są już zainteresowani zobaczeniem kodu.

Profesor może nawet zrobić z tego konkurs, w którym zespoły studentów próbują poprawić oprogramowanie, a najlepsze wyniki są udostępniane reszcie świata.

Jeśli ich wysiłki w zakresie refaktoryzacji zawiodą, nie jesteś dalej w tyle niż byłeś. Jeśli tak jest, zastrzeżenia są wspaniałą rzeczą. Po prostu udostępnij kod, ale dodaj zastrzeżenie: „To nie jest ładne. Kiedy to pisałem, próbowałem przeprowadzić swoje badania - nie sądziłem, że kiedykolwiek wyjdzie poza moje laboratorium komputerowe. Ale nie ma za co rzucić okiem, jeśli naprawdę chcesz. ”

Wiele argumentów przemawiających za opublikowaniem kodu zostało wymienionych w innych odpowiedziach i całkowicie się z nimi zgadzam. Stąd, skoro omówiono podstawową celowość opublikowania kodu, chciałbym to uzupełnić listą kontrolną dalszych punktów, które należy wziąć pod uwagę. Wiele z tych problemów pojawia się prawdopodobnie w praktycznie każdym oprogramowaniu akademickim, więc nawet jeśli nie możesz odpowiedzieć „To nie dotyczy mojego projektu”. każdemu z nich powinieneś być w stanie odpowiedzieć „To jest problem, ale możemy rozwiązać ten problem przez ...” przed opublikowaniem kodu:

• Czy masz pozwolenie na publikację kodu?
  • Czy możesz zagwarantować, że użyłeś tylko fragmentów kodu, które możesz rozpowszechniać? A może używałeś kodu z innych niż otwarte źródła którego możesz używać we własnym oprogramowaniu wewnętrznym, ale którego nie możesz publikować? Czy możesz zagwarantować, że cały kod, którego użyłeś, zostanie opublikowany w jednym kompletnym pakiecie? Zgodność licencji to nietrywialna kwestia.
  • Czy możesz w ogóle rzetelnie się tego dowiedzieć? Czy zleciłeś outsourcingowi jakąkolwiek część swojej pracy związanej z kodowaniem lub zintegrowałeś niepublikowany kod z innego miejsca? Na przykład, czy nadzorowałeś jakichś studentów podczas ich prac dyplomowych lub zatrudniłeś asystentów naukowych, których praca opierała się na twoich badaniach, a zatem ich kod został dodany do twojego kodu? Czy jacyś współpracownicy dodali kod do Twojej bazy kodu? Czy część kodu dostali od uczniów? Czy wszystkie zaangażowane osoby należycie zwracały uwagę na kwestie związane z licencjami (jeśli w ogóle miały wiedzę, aby dokonać świadomej oceny tych kwestii licencyjnych)? Czy można jeszcze ustalić, skąd pochodzą części kodu? Czy ludzie, którzy przyczynili się do każdej części, nadal wiedzą? Czy nadal są dla Ciebie „w zasięgu kontaktów”?
  • Czy kod został opracowany w czasie pracy w oparciu o fundusze osób trzecich? Jeśli tak, czy warunki umowy o dofinansowanie zezwalają na publikację kodu , czy też zawierają wymagania, aby oprogramowanie stworzone w ramach finansowanego projektu było udostępniane wyłącznie partnerom projektu?
• Czy masz wystarczające zasoby (czas i nie tylko), aby poświęcić wysiłek na oczyszczenie kodu i jego komentarzy w taki sposób, aby nadal był zrozumiały, ale nie zawierał żadnych informacji, nie mogą zostać upublicznione?
  • Czy masz jakieś uwagi, które zdradzają, kto pracował nad kodem? Czy osoby, które wniosły kod, zostały oficjalnie dopuszczone do pracy nad odpowiednimi badaniami, zgodnie z ich finansowaniem ? (Twórcy oprogramowania doskonale zdają sobie sprawę z tego, że praca zespołowa i ponowne wykorzystanie komponentów to podstawowe aspekty tworzenia oprogramowania. Niestety agencje finansujące są tego bardzo nieświadome i zakładają, że jeśli deweloper A jest finansowany z projektu X, a programista B jest finansowany z projektu Y, A działa wyłącznie na X, a B działa wyłącznie na Y i ujawniając, że wlog, A spędził tylko pół godziny na czymś, co zakończyło się w projekcie Y, może prowadzić do poważnych konsekwencji, takich jak odzyskanie części finansowania.)
  • Czy cokolwiek w opublikowanych danych zawiera informacje o szczegółach wykonania pracy, które nie mogą zostać upublicznione? Jest to szczególnie ważne, jeśli cała historia zatwierdzeń w systemie VCS ma stają się publiczne (lub praktycznie oznacza, że ​​historia zmian nigdy nie powinna być publikowana), ale może również odgrywać rolę w innych sytuacjach. Na przykład: Czy jakakolwiek praca nad kodem była wykonywana poza oficjalnie wyznaczonymi godzinami pracy (np. W weekendy)? Czy czas pracy świadczy o tym, że przepracowałeś więcej niż ustawowy limit godzin pracy w Twoim kraju w ciągu dnia? Czy czas pracy zdradza, że ​​nie przestrzegałeś prawnie wymaganych przerw? Czy czas pracy zdradza, że ​​ludzie przydzieleni do innych projektów wnieśli swój wkład? Czy czas pracy daje jakikolwiek powód, aby nie ufać jakimkolwiek stwierdzeniom dotyczącym czasu pracy, które złożyłeś w inny sposób (np. W raportach z sukcesów projektów, które wymagały szczegółowego przypisania czasu pracy do wcześniej zdefiniowanych pakietów roboczych z określonymi maksymalnymi przydziałami)? Czy coś zdradza, że ​​pracowałeś w sytuacjach, w których nie powinieneś był pracować (np. Podczas spotkania projektowego)? Czy coś zdradza, że ​​pracowałeś w miejscach, w których nie powinieneś był pracować (np. W domu, gdy umowa nie pozwala ci na prowadzenie biura w domu, np. Z powodu komplikacji związanych z ubezpieczeniem)?
  • Czy w kodzie są jakieś tajne informacje , takie jak hasła, nazwy kont użytkowników lub adresy URL, które nie mogą być publicznie znane (ponieważ serwery nie są przystosowane do obsługi większej liczby użytkowników poza niewielką liczbą wybranych osób którzy osobiście otrzymali adres URL do konfiguracji testu)?
• Czy z kodu może korzystać ktoś inny?
  • Czy kod będzie działał , czy też wymaga dużego wysiłku konfiguracyjnego? Czy możesz poświęcić wysiłek potrzebny na wyjaśnienie, jaka konfiguracja jest konieczna?
  • Czy można skompilować kod? Czy użyłeś nieoficjalnych zmodyfikowanych lub niestandardowych kompilatorów, które nie są publicznie dostępne? Jeśli tak, to czy kod dodaje coś poza tym, co może być już podane jako algorytm pseudokodu w twoich artykułach?
  • Czy kod wymaga zasobów zewnętrznych? Czy kod będzie tylko być przydatne, jeśli może uzyskać dostęp do serwerów, bibliotek lub zbiorów danych, których nie możesz opublikować wraz z kodem z tego czy innego powodu? Czy można podać przynajmniej opis tych zasobów, czy też ich interfejsy podlegają jakiejś umowie NDA?
  • Czy kod wprowadza nieodwracalne zmiany w systemach, w których działa? Na przykład, czy automatycznie zmienia konfigurację systemu (na przykład zastępuje ścieżkę wyszukiwania systemu)? Czy zapewnia dostęp niskiego poziomu do komponentów sprzętowych, który w pewnych konstelacjach (których wewnętrznie unikasz w konfiguracjach testowych) może spowodować trwałe uszkodzenie któregokolwiek z komponentów? Czy możesz niezawodnie ostrzec użytkowników o kodzie przed takimi możliwymi niepożądanymi skutkami ubocznymi?

Oczywiście. Jedynym sposobem na poprawienie się w pisaniu dobrego oprogramowania jest uzyskanie opinii (wszystkich typów). Jeśli boisz się informacji zwrotnych, tak naprawdę nie zajdziesz daleko. Trzy podstawy pisania świetnego oprogramowania to praktyka, praktyka i praktyka.

A teraz przejdźmy do pytania, czy zaszkodziłoby twojej karierze, gdyby ludzie odkryli, że twoje umiejętności pisania oprogramowania nie są na najwyższym poziomie. Myślę, że nie, wręcz przeciwnie, będą cię szanować za twoją akademicką uczciwość. I nie mogę się doczekać współpracy z Tobą.

Możesz po prostu przesłać go do GitHub i spróbować utrzymać projekt na wypadek, gdyby inne osoby zainteresowane Twoim projektem miały łatwy dostęp do Twojego kodu i być może pomogłyby ulepszyć Twój kod.

Tak, powinieneś. W końcu kod źródłowy jądra Linuksa jest dość bałaganiarski, co nie przeszkodziło wielu profesjonalnym programistom w jego studiowaniu i dostarczaniu poprawek i dodatków. Pamiętaj też, że jądro Linuksa jest podstawą systemu operacyjnego, na którym działają najszybsze i najpotężniejsze superkomputery oraz większość urządzeń na świecie PD: Linus Torvalds, facet, który wynalazł jądro Linuksa, ma bardzo dochodową i udaną karierę, która nie miała został dotknięty negatywnie lub w jakikolwiek sposób uszkodzony przez fakt, że kod źródłowy jądra Linuksa jest niechlujny.

Powodem, dla którego nikt nie wspomniał, dlaczego powinieneś udostępniać swój kod, jest to, że możesz znaleźć kogoś, kto jest zainteresowany współpracą z Tobą, ale który jest gotowy poświęcić więcej czasu na czyszczenie kodu i sprawienie, by działał w różnych systemach, itp. niż na innowacyjnym rozwoju, którego dokonałeś.

Wiele osób uważa ten rodzaj pracy za bardzo satysfakcjonujący i jeśli Twój kod jest dla nich naprawdę przydatny, mogą być szczęśliwi mogąc to zrobić. W każdym razie może się okazać, że otrzymywanie opinii od osób, które próbowały go używać, ale potrzebują jakiejś pomocy, jest dobrą motywacją do uczynienia go łatwiejszym w utrzymaniu / łatwiejszym w użyciu i zrozumieniu.

Zdecydowanie powinieneś udostępnić swój kod.

Aby posortować rzeczy, utwórz regiony z tych samych części kodu, jak region z nieudanej próby, i wyjaśnij, dlaczego się nie powiodła. Ponadto, jeśli programujesz w programie Visual Studio, zainstaluj rozszerzenie „CodeMaid” z programu Extension Manager i wyczyść całe rozwiązanie. Usunie spacje, a także usunie nieużywane odwołania, dzięki czemu większość rzeczy będzie wyglądać lepiej.

Jeśli programujesz w C #, udostępnij mi swój kod. Mogę też pomóc w rozwiązaniu problemu :)

Udostępnij to, jeśli chcesz, nie udostępniaj, jeśli nie chcesz. Wiem, że to brzmi śmiesznie, ale wydaje mi się, że w dzisiejszych czasach istnieje zbyt duża presja, aby „dzielić się wszystkim”, a ludzie będą próbować obwiniać Cię za to, że nie udostępnisz, ale tak naprawdę nie masz obowiązku niczego udostępniać.

Umieść zastrzeżenie, że kod jest dostarczany „tak jak jest” bez obietnic wsparcia itp. A następnie udostępnij kod.

Studium przypadku: przekształcenie chmury pojedynczych punktów w wodoszczelną powierzchnię jest niezwykle ważnym problemem praktycznym, używanym wszędzie, od robotyki po wizję komputerową i przetwarzanie danych z czujników 3D, takich jak Microsoft Kinect.

Rekonstrukcja powierzchni Poissona ma 7 lat i już dawno przestała być najnowocześniejszą techniką rozwiązanie tego problemu. Ale wszyscy nadal go używają. Czemu? Ponieważ autor opublikował kod i od tego czasu został włączony do wielu popularnych bibliotek do przetwarzania geometrii. Artykuł ma obecnie ponad tysiąc cytatów.

Tak. Powinieneś zwolnić swój kod, prawdopodobnie na licencji CRAPL. Celem jest zbudowanie lepszej przyszłości - a twój kiepski kod pomoże to ludziom. Zastrzeżeniem jest to, że powinieneś udokumentować, jak pomyślnie obsługiwać kod na tyle dobrze, aby ktoś miał przyzwoitą szansę na odtworzenie jakichkolwiek opublikowanych wyników.

I nie martw się - jeden fragment kodu badawczego, nad którym pracowałem został opracowany przez 5 postdoców o obojętnych umiejętnościach programowania dla serii projektów w ciągu około 8 lat.

Lista zmiennych globalnych (tylko nazwy) wynosiła około 4 strony.

Mniej więcej jedna trzecia z nich została wykorzystana do ustawienia domyślnego zachowania, aby zmienić funkcjonalność, która działała w danym momencie. Kolejne 20% to równoległe struktury danych - co oznacza, że ​​przechowywały one w przybliżeniu te same dane - a zatem funkcje w kodzie pobierane ze struktur danych mniej więcej losowo. Tak. Czasami nie były zsynchronizowane. Czasami musiała być niezsynchronizowana.

Było około 50 nieudokumentowanych wersji, przechowywanych w losowych częściach serwera grupy - z których każda służyła co najmniej jednemu celowi - i tylko jeden administrator zachowywał te określone cele w jego głowie. Częściej zdarzało się, że ludzie używali „niewłaściwej” wersji do określonego celu.

Standardem było stosowanie niewiarygodnie złożonych procedur rekurencyjnych, np. Do pisania pliku. Poważnie - kilka tysięcy wierszy, aby zapisać wyniki obrazów.

Aha, i pozostałości po morderczej próbie rozwiązania problemu wycieku pamięci (właściwie niewidocznej liczby), nigdy nie tworząc nowej zmiennej.

Aha, i baza danych, ta piękna baza danych. Około połowa danych była bezużyteczna z powodu (a) błędów w projekcie bazy danych (b) błędów wprowadzania danych (w programach automatycznych). Kod do pobierania plików z bazy danych składał się z kilkuset wierszy logiki ... Sama baza danych również była na tyle uprzejma, że ​​zawierała wiele kopii tych samych danych, w większości z uszkodzonymi połączeniami między tabelami. Ograniczenia? Nie. Widziałem, jak statystyka przechodzi od niepokoju przez strach, łzy do rzucenia palenia w ciągu miesiąca od powierzenia mu bazy danych ...

Było od 0 do 1 sposobów obsługi oprogramowania i uzyskiwania prawidłowych wyników w dowolnym momencie ...

I tak, były problemy.

Aha, i próbując zapewnić nieprzezroczyste i niedeterministyczne działanie, wykonano serię obliczeń, wywołując GUI przyciski z powiązanymi wywołaniami zwrotnymi.

Około 90% dowolnej funkcji było całkiem niezawodnie nieistotne dla wyniku lub debugowania wyniku - składało się raczej z wstawionych projektów krótkoterminowych, a następnie nigdy oddalony. Poważnie - napisałem pełną wersję funkcji, która faktycznie działała, która była 1/10 rozmiaru ... Znaczące ułamki to skopiowane i wklejone funkcje, z których wiele różniło się od siebie.

I, żadna Virginia, nie ma dokumentacji. Albo opisowe nazwy zmiennych.

Aha, i nieudokumentowane, błędne biblioteki dll i powiązane biblioteki - wygenerowane przy użyciu kodu, który już nie istnieje.

Wszystko napisane w Matlabie. Jeśli chodzi o praktyki kodowania Matlab, załóżmy, że obfite użycie eval byłoby główną atrakcją twojego dnia.

Poważnie, twój kod nie jest taki zły.

To powiedziawszy, jeśli zrobiłeś coś naprawdę pożytecznego, wypuszczenie oczyszczonej wersji, aby inni ludzie użyli i zacytowali Twoją bibliotekę, może przyspieszyć karierę. Jeśli właśnie coś zrobiłeś, reprodukcja jest prawdopodobnie tak daleko, jak byś był dobrze zalecany.