Pytanie:
Czy powinienem udostępniać moje okropne oprogramowanie?
qsp
2015-01-23 03:21:48 UTC
view on stackexchange narkive permalink

Po opublikowaniu pracy niektórzy ludzie poprosili mnie o udostępnienie opracowanego przeze mnie oprogramowania. Na początku byłem bardzo szczęśliwy, że moja praca przyciągnęła uwagę i chętnie udostępniłem nie tylko plik binarny, ale także kod źródłowy, studia przypadków itp. Ale patrząc na moje oprogramowanie, czuję się bardzo zażenowany.

Moje oprogramowanie jest po prostu okropne: kod źródłowy to po prostu bałagan, zawierający kilka moich nieudanych prób; Nigdy nie używałem wzorców projektowych, więc zduplikowany kod jest wszędzie; ze względu na prostotę i szybkość implementacji często wolę rekurencje od pętli itp.

Zawsze jestem pod presją tworzenia nowych wyników, a czyszczenie tego kodu kosztowałoby mnie sporo wysiłku.

Moje pytanie brzmi, czy udostępnienie tego okropnego oprogramowania da ludziom bardzo negatywne wrażenie o mnie? Czy zaszkodziłoby mojej karierze, gdyby ludzie, których dzielę, byli potencjalnymi współpracownikami, pracodawcami, ponieważ pracują w tej samej dziedzinie.

Brzmi jak oprogramowanie akademickie.
Powiązane: [Jak udostępniać kod komputerowy] (http://academia.stackexchange.com/questions/16785/how-to-share-computer-code?lq=1) i [Najlepsze modele praktyk dla kodu „badawczego”? ] (http://academia.stackexchange.com/q/21276/10643) i klasyka: [Dlaczego wielu utalentowanych naukowców pisze okropne oprogramowanie?] (http://academia.stackexchange.com/q/17781/10643)
Nie jestem pewien, jak bardzo mogę ci pomóc, ale widziałem ten film, który w oparciu o twój problem może cię trochę zachęcić. https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CCsQtwIwAg&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv% 3D0SARbwvhupQ & ei = k2rBVKP8J8P1OPbMgagL & usg = AFQjCNEIXszWW5AeYeh5TglmX2_yHFD7WA & bvm = bv.83829542, d.ZWU Przepraszam, że nie mogłem Ci pomóc, chciałem pokazać ten film.
Brudny sekret: * większość * oprogramowania akademickiego jest okropna. Nawet rzeczy wychodzące z wydziału informatyki.
Możesz go wydać na licencji CRAP: http://matt.might.net/articles/crapl/
Badania ogólnie obejmują wypróbowanie tysięcy rzeczy, które nie działają. Jeśli uda Ci się napisać kod, który działa w pierwszych kilku próbach, prawdopodobnie nie prowadzisz badań, a jedynie wdrażasz.
[Ten artykuł] (http://www.siam.org/news/news.php?id=2064) w czasopiśmie SIAM jest fascynującą lekturą i stanowi bardzo przekonujący argument.
Kolejna kwestia do rozważenia: co zrobić, jeśli niektóre z twoich wniosków opierają się na fałszywych danych pochodzących z błędu w twoim oprogramowaniu? Czytelnicy powinni być w stanie to sprawdzić.
Opublikowanie kodu w miejscu publicznym, takim jak GitHub, daje szansę pokazania, w jaki sposób stopniowo ulepszyłeś swoje oprogramowanie. Znaczące ulepszenie oprogramowania bez zmiany wyników generowanych przez oprogramowanie nie jest łatwym zadaniem i dlatego jest wysoko cenioną umiejętnością. Może się okazać, że opublikowanie części kodu na stronie przeglądu kodu https://codereview.stackexchange.com/ będzie pomocne.
@qsphan Z ciekawości, o czym jest twoja praca?
Aby dodać do rozmowy: http://www.phdcomics.com/comics/archive.php?comicid=1692
@mankoff: Proszę nie. Ta licencja jest * fatalna *. Wydanie go pod 3-klauzulowym BSD z dużą naklejką ostrzegającą o jakości byłoby znacznie lepszą opcją.
wiele programów nieakademickich też to bałagan, por. ostatnie błędy basha ...
Blah, jako programista: „Zawsze jestem pod presją, aby uzyskać nowy wynik, a czyszczenie tego kodu będzie mnie kosztować dużo wysiłku”. Czy zdajesz sobie sprawę, że powodem, dla którego jesteś pod taką presją, jest to, że spędzasz tyle czasu DEBUGOWANIE kodu, że nigdy nie zadałeś sobie trudu, aby pisać lub utrzymywać poprawnie?
Nawet jeśli kod jest naprawdę okropny - w co wątpię - nadal jest testowany w walce i debugowany, co jest dużo, DUŻO bardziej wartościowe niż używanie najnowszych wzorców projektowych itp. Pamiętaj, aby dodać szczegółowe instrukcje na platformie bazowej (Ubuntu 12.04, OS X 10.7 z XCode z libX w wersji Y itp.), Ponieważ mogą występować drobne różnice powodujące problemy, a także pełne instrukcje dotyczące kompilowania i linkowania programów. Prawdopodobnie już trochę zautomatyzowałeś podczas pisania - po prostu zanotuj, aby inni mogli to zobaczyć.
Nie ma nic złego w rekurencji, chyba że język programowania nie obsługuje jej optymalizacji
@Philipp: Bardziej martwi mnie sytuacja, w której artykuł jest poprawny, ale kod zawiera paskudny błąd. W takim przypadku naprawienie błędu zmieniłoby poprawność odpowiedzi, ale nie (powiedzmy) jej charakterystykę wydajnościową ... więc jeśli zwolnisz kod, ryzykujesz zawstydzeniem, nawet jeśli wyniki mogą nie zostać unieważnione. (Już wcześniej znalazłem tego rodzaju błędy we własnym kodzie).
Nie ma znaczenia, czy jest to akademickie, czy nie. http://blog.codinghorror.com/version-1-sucks-but-ship-it-anyway/
@Mark: Większość oprogramowania jest okropna, kropka. Nie ogranicza się do akademickich i naprawdę nie jest tajemnicą. ;-)
Aby dodać do tego, nawet oprogramowanie naukowe, które jest używane każdego dnia w głównych aplikacjach, staje się bałaganiarskie i okropne - kod używany przez Met Office wciąż znajduje się w Fortranie i ma w sobie resztki sprzed kilkudziesięciu lat ...
@djechlin Chociaż czasami prawda, „Źródłem presji jest złe kodowanie”, nie zawsze da się uogólnić. Chyba że było coś w moich umiejętnościach Pythona, które napędzały ostatnią epidemię Eboli?
@Fomite Coś o twoich umiejętnościach w Pythonie jest powodem, dla którego nie skończyłeś jeszcze swoich badań nad Ebolą, jeśli chcesz to ująć w ten sposób: P
@djechlin Nie, myślę, że jest to bardziej związane z ludźmi, którzy wciąż umierają ...
@Fomite po co w ogóle zawracać sobie głowę pisaniem kodu, skoro i tak ludzie umierają?
@Fomite Chodzi mi o to, że jeśli zamierzasz * zrobić * to, powinieneś to zrobić * dobrze * i * szybko *, jeśli jest to * główne * wąskie gardło w twojej pracy. Przypuszczam, że możesz powiedzieć, że głównym wąskim gardłem w twojej pracy jest częstość występowania eboli, ale po tym jest przerażająco duża szansa, jak dobrze działa twój kod. Ale jeśli chcesz upierać się, że istnienie eboli jest problemem, to masz więcej mocy.
@djechlin Zwracam tylko uwagę, że idea, że ​​źródło presji na naukowca sprowadza się do złego kodowania, jest zarówno głęboko zarozumiała, jak i zdecydowanie nie daje się uogólnić.
Czy można pracować z studentem studiów licencjackich lub magisterskich i kazać im „wyczyścić” część kodu?
Sugestia programisty: nie trzymaj swoich nieudanych prób jako zakomentowanego kodu lub w nieużywanych klasach.Zamiast tego często zatwierdzaj (pół) działające wersje do kontroli źródła (GIT).__Zawsze__ usuwaj martwy kod, który nie jest już potrzebny!Jeśli musisz wrócić do wcześniejszej wersji, przywróć ją z kontroli źródła.W ten sposób znacznie łatwiej jest zachować kontrolę nad kodem, ponieważ jest znacznie mniej kodu do odczytania.Jeśli chodzi o kwestię, w której twój kod nie używa fantazyjnych wzorców projektowych itp.: To może być dobra rzecz, postaraj się, aby było to tak proste, jak to tylko możliwe, dodawaj złożoność tylko tam, gdzie jest to absolutnie konieczne.
Osiemnaście odpowiedzi:
#1
+306
Ian
2015-01-23 03:31:21 UTC
view on stackexchange narkive permalink

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.

Większość programów naukowych NIE jest straszna. (Od kilkudziesięciu lat zarabiam na życie pracując z i optymalizując go, więc myślę, że mam przemyślaną opinię). Ma po prostu inne kryteria dobroci: praca, uzyskiwanie poprawnych odpowiedzi w praktycznym czasie, możliwość rozszerzania do następnej teorii itp., zamiast dostosowywać się do najnowszego paradygmatu projektowania quasi-religijnego lub trendu językowego. A jeśli chodzi o OP, twoje „okropne” oprogramowanie może, jeśli zostanie trochę wyczyszczone i skomentowane, będzie bardziej dostępne dla innych naukowców niż „dobry” kod.
Dodam tylko, że proponuję udostępnienie go za pośrednictwem Github lub podobnego, który ma żywą społeczność i ułatwia ludziom współpracę, rozwidlenie twojego projektu i wniesienie do niego wkładu.
Żadnej wzmianki o słoniu w pokoju, „odtwarzalności”?
@jamesqf: Przesadziłem dla efektu, ale myślę tak. Większość oprogramowania naukowego to krótki kod dowodowy, jednorazowy. Rzadko jest publikowany poza małą grupą i, z mojego doświadczenia, jest źle napisany. Większość oprogramowania naukowego *, które działa w rozsądnej skali *, nie jest straszna (pracowałem też z niektórymi w podobnej skali czasowej): nie można tworzyć wielu publikacji. Ale myślę tutaj o „całym kodzie napisanym przez naukowców”.
@mmalmeida Zgadzam się, Github jest kanałem współpracy. Problemy i kamienie milowe umożliwiają śledzenie problemów i próśb o ulepszenia. Przed otwarciem tego kodu poleciłbym również poświęcić trochę czasu na jego wyczyszczenie lub przynajmniej dodanie do niego opisowych komentarzy.
@jamesqf Cóż, większość jest okropna. Powiedziałbym również, że mam przemyślaną opinię. To, jak działa kod, nie jest kryterium „dobroci” kodu dla programisty, przynajmniej takiego uznawanego za dobry. Poprawność to właściwość „obowiązkowa”. Stopień dywergencji, stabilność numeryczna, szybkość (z wyłączeniem optymalizacji sprzętowych) itp. Są właściwościami * algorytmu * implementowanego przez kod. Możesz mieć dobry kod i zły kod wykonujący to samo. Chociaż przyznaję, „dobre” jest zbyt niejasne i często prowadzi do nieporozumień. Powiedziałbym, że „jakość kodu” jest bardzo często straszna. Nawet jeśli program * działa * świetnie.
@jamesqf: większość oprogramowania naukowego, z jakim się spotkałem, nie znajdowała się w żadnej kontroli źródła, a to brzmi jak inny przykład (lub dlaczego wszystkie są nadal nieudane próby).
@RemcoGerlich: Cóż, jest przykład posiadania różnych kryteriów „dobroci”. Nigdy jeszcze nie znalazłem systemu kontroli kodu źródłowego, który nie ma oczywistej poważnej wady projektowej: wyewidencjonowanie plików z systemu resetuje ich znacznik czasu do czasu pobrania, a nie czasu ostatniej modyfikacji. Osoby wdrażające te systemy oczywiście uważają, że jest to „dobra” funkcja - miałem kilka argumentów na ten temat na forum użytkowników - ale efekt końcowy jest taki, że nie używam kontroli wersji, chyba że wyraźnie mi za to płacą.
@jamesqf: nie bierze tego do siebie, ale zajmuje to dość wysokie miejsce na liście głupich powodów, aby nie używać kontroli źródła (poza tym, w przypadku „normalnych” systemów VCS potrzeba może 20-liniowego skryptu, aby „naprawić” ten „poważny błąd projektowy” ).
@jamesqf Nigdy nie widziałem, aby znacznik czasu pliku miał znaczenie, * w ogóle *. Jedynym przypadkiem, w którym mogę nawet pomyśleć, że ma to wpływ na cokolwiek, jest `make`, a kiedy masz czysty checkout, nie ma plików binarnych do sprawdzenia, czy wymagają przebudowy. Korzyści z kontroli źródła są oczywiste: śledzenie zmian (co jest * niezwykle * cenne w praktyce), ochrona przed utratą, łatwiejsze udostępnianie współpracownikom i umożliwienie ludziom jednoczesnej pracy na tej samej bazie kodu. Twój problem wydaje się wyjątkowo niejasny i założę się, że same te korzyści przeważają nad wadami twojego konkretnego przypadku użycia
Projekt Sage (http://www.sagemath.org) jest żywym przykładem oprogramowania do badań matematycznych, które * nie jest straszne *, chociaż nieustannie toczą się dyskusje projektowe i skargi dotyczące praktyki kodowania.
@jpmc26: Jak czasy plików mogą nie mieć znaczenia? Być może, jeśli pracujesz tylko na jednym zestawie kodu, nie są one aż tak ważne, ale jeśli masz wiele różnych kodów, każdy z wieloma plikami (z mojego doświadczenia wynika, że ​​jest to typowe dla oprogramowania naukowego), naprawdę przydatne jest rzut oka (robiąc np. „ll *. [chyl]” dokładnie, kiedy i nad którymi plikami pracowałeś. Teraz zgadzam się, że PRAWIDŁOWO DZIAŁAJĄCY system kontroli kodu źródłowego byłby świetnym narzędziem. Problem polega na tym, że! @ # Osoby, które je budują, absolutnie odmawiają wdrożenia tej naprawdę prostej poprawki.
@jamesqf Commits (rdzeń większości systemów kontroli źródła) mają znaczniki czasu. Na przykład w git utwórz zatwierdzenie dla każdej modyfikacji plików danych, na przykład „przeredaguj ponownie symulację przy użyciu nowego kodu z wersji XXX”. Dla każdej modyfikacji kodu dokonaj zatwierdzenia o treści „ulepszony kod w XXX z powodu YYY”. Wtedy zamiast mieć „datę ostatniej modyfikacji” dla swoich plików, otrzymujesz ładną listę zatwierdzeń wraz z datą ich wystąpienia, dokładnymi nazwami plików, które zostały dodane / zmodyfikowane / usunięte oraz pomocnym komentarzem. Nie ma nic do zrobienia, po prostu nie wiesz, jak prawidłowo używać kontroli źródła.
Nie wspominając o tym, że jeśli ** naprawdę ** potrzebujesz tej funkcji, każde oprogramowanie do kontroli źródła pozwala zapytać o to, kiedy plik był ostatnio modyfikowany. W rzeczywistości większość wyjdzie poza to i powie ci, które zatwierdzenie ostatnio wpłynęło na plik, podając kontekst zmiany oprócz sygnatury czasowej, co jest o wiele bardziej pomocne i praktyczne niż „och, ostatnio modyfikowałem ten plik 26 dni temu , Lepiej zajrzyj do mojego pliku .txt i zobacz, co tam zrobiłem ... och, czekaj, zapomniałem to zapisać, ups ”.
@jamesqf Thomas załatwił sprawę. Przeglądasz historię zmian, aby zobaczyć, co zostało zmienione, kiedy i jak. Dzięki narzędziu do porównywania możesz nawet zobaczyć porównanie linia po linii poprzednich i bieżących wersji plików (lub nawet dwóch poprzednich wersji). Twoja kontrola źródła staje się autorytatywnym źródłem tych informacji. To także znacznie ułatwia dzielenie się historią z innymi, co moim zdaniem byłoby cenne dla społeczności akademickiej. Na marginesie, zwykle powinieneś umieszczać niepowiązane bazy kodu w różnych repozytoriach. Umożliwia to oddzielne przeglądanie historii.
@Thomas: Przepraszam, ale to jest ta sama linia BS, którą otrzymałem od programistów: albo pracuj tak, jak chcemy, żebyś pracował, albo się zgub. Przepraszam, ale PRÓBOWAŁEM pracować na swój sposób, ludzie. Nie działa mi.
@jamesqf W takim przypadku byłoby całkiem łatwo napisać punkt zaczepienia dla większości systemów VCS, aby działał tak, jak chcesz. Nie ma powodu, żeby nie mieć tego w obie strony.
Powodem, dla którego sygnatury czasowe są resetowane, jest to, że jeśli w kasie otrzymasz zmieniony plik, który został zmieniony wczoraj, ale wykonałeś kompilację dziś rano, większość systemów kompilacji nie przyjmie zmiany (ponieważ sygnatura czasowa była starsza niż artefakty kompilacji) . Kompilacje będą działać z sygnaturą czasową ustawioną na czas kasy.
@jamesqf Czy ci się to podoba, czy nie, korzystanie z VCS jest pragmatycznym obowiązkiem. Jeśli nie korzystasz z VCS, wielu potencjalnych współpracowników (w tym prawie wszyscy doświadczeni programiści) będzie mieć duże trudności z poważnym potraktowaniem projektu. A impulsem do tych „quasi-religijnych” paradygmatów projektowania jest dążenie do niewypowiedzianej elegancji, która sprawia, że ​​projekt jest rozszerzalny na następną teorię i dostępny dla innych.
@jamesqf Jest powód, dla którego „programiści” ci to powtarzają - to dlatego, że mają rację. Poza tym, tak, większość oprogramowania naukowego jest rzeczywiście dość zła, w tym moje własne. Piszę kod znacznie inaczej, gdy piszę go dla projektu produkcyjnego, który zamierzam faktycznie utrzymywać, a kiedy piszę go jako dowód słuszności koncepcji, aby przeprowadzić symulacje dla pracy naukowej. Widziałem to samo w prawie każdym fragmencie kodu badawczego, jaki kiedykolwiek widziałem. Jest kilka wyjątków, ale to po prostu: wyjątki.
@jamesqf „Jak czasy plików mogą nie mieć znaczenia? Być może, jeśli pracujesz tylko na jednym zestawie kodu, nie są one tak ważne, ale jeśli masz wiele różnych kodów, każdy z wieloma plikami (typowe dla oprogramowania naukowego, z mojego doświadczenia) , bardzo przydatna jest możliwość szybkiego sprawdzenia, nad którymi dokładnie plikami pracowano ”. Uh ... czy to nie _ dokładnie_ jest problem, który ma rozwiązać kontrola wersji?
@jamesqf Jeśli aktywne używanie kontroli źródła powoduje problemy, prawdopodobnie wystarczy trochę przemyśleć przepływ pracy. Jeśli możesz zawęzić konkretne problemy, które masz, pytania o to, jak możesz do nich podejść, najprawdopodobniej będą mile widziane w programistach i StackOverflow. Spróbuj. Możesz być zaskoczony, jak bardzo poprawia to twoje wrażenia. Powiem też tak: jeśli wypróbowałeś git, ten system jest naprawdę trudny do nauczenia. Rozpoczęcie pracy z SVN może być łatwiejsze, ponieważ jest znacznie bardziej intuicyjne i nie jest tak wymagające dla przepływu pracy. SVN jest o wiele lepszy niż nic.
Jako ktoś, kto pracuje w oprogramowaniu, żaden kod nie jest _ nigdy_ doskonały. Ale nie pozwól, by perfekcja była wrogiem „dostatecznie dobrego”. Jak powiedzieli inni, ktoś może uznać twoje oprogramowanie za przydatne. Jeśli możesz trochę posprzątać i dodać kilka komentarzy lub README, tym lepiej :)
Nie tylko naukowe oprogramowanie jest okropnie napisane. Od dziesięciu lat rozwijam się zarówno w sklepach z oprogramowaniem, jak iw firmach produkcyjnych i obiecuję, że kod nie stanie się bardziej przejrzysty. Gdziekolwiek. Pisanie pięknego kodu jest bardzo trudne. To jak pisanie książki. Pierwszy szkic zwykle jest do bani, ale tak naprawdę opowie historię. Żeby sprzedać książkę, trzeba ją upiększać. Aby zadowolić udziałowców w zakładach, wystarczy im opowiedzieć historię.
Ten wątek komentarzy zamienił się w dyskusję niezwiązaną z tematem na temat VCS. ** Prosimy o podjęcie rozszerzonej dyskusji na [czat]. **
Bawiłem się z GATT (programem do ustalania rozkładu zajęć przy użyciu algorytmów genetycznych, stanowiskiem testowym dla serii doktoratów w Szkocji). Zadziałało, ale kod zawierał mnóstwo zakomentowanego kodu, nieużywane funkcje (z poprzednich tez), zbyt ogólny kod (aby pomieścić różne próby) i bardzo wąski, trudny do dostosowania kod obok siebie. Złożone z zawiłymi strukturami danych, które czasami są używane do nieprzeznaczonych zastosowań. Sprzątanie tego bałaganu byłoby ogromnym zadaniem. Ale było dobrze, jak to było w przypadku jego roli eksploracyjnej.
#2
+83
Blair MacIntyre
2015-01-23 03:31:26 UTC
view on stackexchange narkive permalink

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!

Nie mogę poprzeć odejścia w nieudanych próbach. Zamiast tego należy użyć kontroli wersji. Dołączanie krótkich komentarzy wyjaśniających, dlaczego pierwsza próba się nie powiodła, jest w porządku, ale uwzględnienie rzeczywistego nieudanego kodu może być aktywnie szkodliwe.
@DavidZ Wręcz przeciwnie, pokaż to. Jeśli używasz kontroli wersji, ludzie mogą zobaczyć poprzednie odmiany Twojej pracy, co wcale nie jest bezużyteczne. Ale jeśli tak jak tutaj nie używasz VC, nie usuwaj nieudanych prób. Umieść je w innym pliku z odpowiednimi komentarzami. Jak szkodliwe może to być?
@coredump Może sprawić, że cały program będzie praktycznie niezrozumiały. Widziałem, jak to się stało. Jeśli nie używasz VC, _ zacznij go używać_. Jedynym sposobem, w jaki mógłbym poprzeć zalecenie, aby nie usuwać nieudanych prób, jest to, że nie wolno ci umieszczać kodu w VC z jakiegoś powodu, którego nie mogę sobie wyobrazić, _ i_ konieczne jest zobaczenie poprzedniego kodu, aby zrozumieć, co jest aktualne code (co prawdopodobnie oznacza, że ​​obecny kod też jest zły, chociaż przyznaję, że mogą istnieć wyjątki).
@DavidZ Przepraszamy, ale „Powiedz, dlaczego się nie udało i czego próbowałeś” to dobra rada, IMHO. Jeśli Twój kod jest niechlujny i / lub jeśli nie jesteś przyzwyczajony do praktyk inżynieryjnych oprogramowania, zostaw go tak, jak jest i komentuj jak najwięcej. Usunięcie przydatnych informacji może uczynić rzeczy praktycznie niezrozumiałymi. Widziałem, jak to się dzieje ;-). Okej, więc może jest jakiś kompromis między pokazaniem wszystkich okropnych rzeczy, których próbowano, a pozostawieniem pożytecznych śladów. Myślę, że „trochę posprzątałbym” to również dobra rada.
@coredump Powiedzenie tego, czego próbowałeś w sensie włączenia nieudanego kodu, jest dobrą radą, gdy prosisz o pomoc, ale nie w przypadku pisania samego programu.
Nie widzę, w jaki sposób uszkodzony kod może pomóc poza zaciemnianiem działającego kodu (chyba że błędy są wyraźne i np. „Znacznie prostszy kod, ale działa tylko dla pozytywnych wpisów”). Ale co warto robić w komentarzach (np. „Kusiłoby użycie tablic, ale nie będą one działać w przypadku nieunikalnych wpisów”).
Jeśli kod jest implementacją artykułu badawczego, a on próbował wdrożyć go na różne sposoby, to wychodzę z założenia, że ​​rozwiązanie nie jest oczywiste. Podczas badań ktoś inny może zobaczyć działający kod i pomyśleć „Mogę to zrobić lepiej w ten sposób”, co może być jednym ze sposobów, które autor wypróbował jako pierwszy. Słabo radzimy sobie w CS w dzieleniu się naszymi porażkami, co czasami prowadzi do utraty pracy. To mój punkt. Nie można wiedzieć, czy jest to dobry wybór w tym przypadku, nie widząc kodu, ale znam wielu innych specjalistów, którzy podzielają ten pogląd
Dzielenie się nieudanymi próbami różni się od mieszania uszkodzonego kodu z działającym kodem, co nie daje nic poza myleniem i uniemożliwianiem zrozumienia.
#3
+58
jamesqf
2015-01-23 04:26:19 UTC
view on stackexchange narkive permalink

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.

Bardzo prawdziwy komentarz dotyczący odtwarzalności, w szczególności drugi akapit.
@E.P: Tak. Przepraszam, znowu pojawia się moja dystypica :-)
#4
+51
Davidmh
2015-01-23 15:05:12 UTC
view on stackexchange narkive permalink

¿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) .

+1, ale dodałbym również odpowiednią obsługę błędów do listy ważnych punktów (zbyt często brakuje w pośpiesznym kodzie badawczym). W szczególności, należy zachować szczególną ostrożność w przypadku każdego błędu, który mógłby wpłynąć cicho na wyjście - czy ta funkcja zwraca wartość rzeczywistą liczbę zero, czy też domyślną wartość powrotu po błędzie zero? (Nie kreśl ich!) Ponadto błędy powinny być obsługiwane, ale nie nadmiernie. Widziałem naiwnie napisany „kuloodporny” kod, który potrafiłby po cichu odzyskać dane po zniekształconych danych wejściowych i kontynuować tworzenie wyników bez reklamacji. Awaria może być frustrująca, ale niedokładne wyniki mogą być katastrofą.
Skorzystaj z punktu nr 3 i czyjegoś komentarza na temat jednoliterowych nazw zmiennych: w oprogramowaniu naukowym często mniej lub bardziej bezpośrednio przekładasz równania matematyczne na kod. Jeśli zmienne w równaniach są pojedynczymi literami, użycie ich jako nazw zmiennych w kodzie ma sens. I, jak przyznaję, powinienem robić częściej, dołączać LaTeX do równań w komentarzu. Co do reszty, tak naprawdę nie żyłeś, dopóki nie spróbowałeś debugować FORTRAN 66 za pomocą obliczonych i przypisanych GOTO :-)
+1 za odpowiedź od @imsotiredicantsleep. Kod, który po cichu zawodzi, jest trudny w użyciu. Jeśli ma generować niedokładne wyniki, upewnij się, że generuje ostrzeżenie lub zgłasza błąd.
#5
+23
Toxaris
2015-01-26 16:07:07 UTC
view on stackexchange narkive permalink

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.

#6
+14
dotancohen
2015-01-25 17:28:40 UTC
view on stackexchange narkive permalink

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.

To nie jest część żadnej najlepszej praktyki programistycznej. Przypuszczalnie nieużywany kod powinien zostać zakomentowany, aby jakiś kod nie wywoływał `get_foobar_legacy_43`. A kiedy stanie się jasne, że jest uszkodzony, należy go usunąć, jeśli to możliwe.Jeśli zrozumienie jakiejś nieudanej próby jest warte dla czytelników aktualnej wersji (co się dzieje), należy umieścić ją w kontroli wersji i dodać komentarz wskazujący na odpowiednie zatwierdzenie ID - prawdopodobnie z permalinkiem.
@Blaisorblade: Masz rację, jeśli celem jest stworzenie dobrze działającej aplikacji, to nieużywany kod powinien zostać usunięty, albo poprzez komentowanie, albo poprzez przeniesienie go do głębi oprogramowania do kontroli źródła. ** Jednak nie taki jest cel określony w PO. ** PO musi mieć udokumentowane niepowodzenia. To jest sposób na zrobienie tego. Chociaż widzę wartość w twoim punkcie i być może każda metoda może zostać zakomentowana za pomocą składni komentarza blokowego `/ * * /`. Co ciekawe, jednym z niewielu języków, które nie obsługują komentarzy blokowych, jest Python, język, którego użyłem powyżej pseudokodu.
@Blaisorblade: Jeszcze lepszym rozwiązaniem może być oddzielny plik, klasa lub katalog obejmujący nieudane próby, oddzielony od kodu pocztowego aplikacji.
Dokumentowanie niepowodzeń nie jest zawarte w pytaniu i myślę, że jest to dobry pomysł * w kilku przypadkach * (powiedzmy, dla interesujących, ale nieudanych prób osiągnięcia wkładu pracy). „Odejście w niepowodzeniach” wydaje się pochodzić z innej odpowiedzi - gdzie ludzie toczyli ożywioną debatę: http://academia.stackexchange.com/a/37373/8966.
#7
+10
Dima Pasechnik
2015-01-25 01:16:44 UTC
view on stackexchange narkive permalink

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ć.

#8
+9
David1199
2015-01-23 13:23:20 UTC
view on stackexchange narkive permalink

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. :-)

Sprzątanie jest w zasadzie dobre. Jeśli jednak poczekasz na dobry czas na posprzątanie, ten czas może nigdy nie nadejść. Sugerowałbym natychmiastowe umieszczenie go w repozytorium kontroli wersji na Github lub Bibucket lub podobnym i wyczyszczenie go, gdy się do niego przejdziesz. Każdy, kto ją pobierze, i tak będzie głównie patrzył na HEAD.
#9
+7
J.R.
2015-01-26 04:47:31 UTC
view on stackexchange narkive permalink

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. ”

Podoba mi się to, bardzo bym chciał mieć taką szansę, kiedy byłem na uniwersytecie. Czytanie i rozumienie kodu innych ludzi to umiejętność i trzeba się jej nauczyć.
#10
+7
O. R. Mapper
2015-04-02 16:49:06 UTC
view on stackexchange narkive permalink

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?
Zastanawiasz się, czy agencje finansujące lub pracodawcy nie przeszukują dzienników zatwierdzeń, aby określić konsekwencje prawne. To jest oczywisty problem teoretyczny. A więc, czy masz jakieś dowody na to, że kiedykolwiek się to wydarzyło? Moje ograniczone doświadczenie z agencjami finansującymi, w szczególności z grantami ERBN, jest w rzeczywistości odwrotne, chociaż to się nie liczy.
@Blaisorblade: "Więc, czy masz jakieś dowody na to, że kiedykolwiek się to wydarzyło?" - motywacja darczyńcy do odkrycia możliwości obniżenia kosztów wydaje się jasna, a możliwe reperkusje, które mogą zostać wyegzekwowane (zwrot części dotacji) są wystarczająco dotkliwe (utrata wcześniej przyznanych środków jest prawdopodobnie jedną z niewielu rzeczy, które mogą wpychać pracowników uni w poważne kłopoty z administracją unii), że wydaje się rozsądne, aby w pierwszej kolejności nie otwierać tego możliwego punktu ataku.
#11
+6
King
2015-01-24 23:32:51 UTC
view on stackexchange narkive permalink

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ą.

#12
+5
lovelyzlf
2015-01-24 23:11:47 UTC
view on stackexchange narkive permalink

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.

+1 - to pierwsza rzecz, która przyszła mi do głowy.Jest to bezpieczne miejsce do przechowywania kodu, lepsze niż trzymanie go na twardym dysku lub pamięci USB, która umrze lub zaginie.Ponadto kod jest łatwy w utrzymaniu, a wszelkie zmiany w kodzie są śledzone, a jak mówisz, inni mogą współpracować i wnosić swój wkład (pod warunkiem, że zostaną wybrane odpowiednie ustawienia dostępu).
#13
+4
jwg
2015-01-26 16:51:34 UTC
view on stackexchange narkive permalink

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.

#14
+4
user28382
2015-01-25 11:03:30 UTC
view on stackexchange narkive permalink

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.

#15
+1
CaptainCodeman
2015-01-25 20:15:12 UTC
view on stackexchange narkive permalink

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ć.

Odtwarzalne wyniki są jednym z kamieni węgielnych metody naukowej. A to wymaga udostępniania. Twój komentarz jest podobny do powiedzenia „... ale tak naprawdę naukowcy nie mają obowiązku stosować się do metody naukowej”.
Jasne, udostępnianie może być opcjonalne * poza * społecznością naukową, ale z pewnością nie jest opcjonalne * wewnątrz * społeczności naukowej.
@Contango Tak, to słuszna uwaga, jeśli wydanie oprogramowania pomaga odtworzyć wyniki.
@JeffE Nic nie udostępniłem, o czym mówisz? Twoja wiadomość jest tajemnicza. Jeśli chcesz, aby Cię zrozumiano, proszę, wyrażaj się bardziej jasno.
Oczywiście podzieliłeś się swoją opinią.
#16
+1
Zuberi
2015-01-24 14:50:29 UTC
view on stackexchange narkive permalink

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 :)

@PeterMortensen: [Dodaj linki tylko wtedy, gdy istnieje uzasadniona szansa, że ​​ktoś chce je kliknąć.] (Http://meta.academia.stackexchange.com/q/1252/7734)
@Zuberi005 jest jedyną osobą, która oferuje zautomatyzowane * rozwiązanie * pomagające w czyszczeniu kodu i jedyną osobą, która osobiście oferuje pomoc w czyszczeniu kodu. Ktoś przegłosował? Niech się wstydzą!
#17
  0
user168715
2015-02-12 08:54:28 UTC
view on stackexchange narkive permalink

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.

#18
  0
erwin
2015-04-01 19:22:14 UTC
view on stackexchange narkive permalink

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.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...