Zwolnienie projektu open source bez zawstydzenia [zamknięty]

Od dłuższego czasu pracuję nad dość dużym projektem typu open source i zbliża się on do punktu, w którym chciałbym go wydać. Jestem jednak samoukiem i tak naprawdę nie znam nikogo, kto mógłby odpowiednio ocenić mój projekt.

Kilka lat temu opublikowałem niewielką część kodu, który został praktycznie rozerwany (w sensie krytycznym) na forum, na którym go opublikowałem. Mimo że kod działał, krytyka była trafna, ale brutalna. Skłoniło mnie to do rozpoczęcia poszukiwania najlepszych praktyk we wszystkim i ostatecznie wydaje mi się, że uczyniłem mnie znacznie lepszym programistą. Omówiłem wszystko w moim projekcie tak wiele razy, próbując uczynić go idealnym, że straciłem rachubę.

Wierzę w mój projekt i myślę, że może on pomóc wielu ludziom i mam wrażenie, że zrobiłem z nim kilka ciekawych rzeczy. Mimo to, ponieważ jestem samoukiem, nie mogę przestać się zastanawiać, jakie luki istnieją w mojej samokształceniu. Sposób, w jaki mój kod został rozerwany ostatnim razem, nie jest czymś, co chciałbym powtórzyć. Myślę, że moje dwa największe obawy związane z wydaniem mojego projektu, który poświęciłem niezliczoną liczbę godzin, są absolutnie zawstydzone, ponieważ przegapiłem pewne oczywiste oczywiste rzeczy z powodu mojej samokształcenia lub, co gorsza, wypuszczenia go na dźwięk świerszczy.

Czy jest ktoś, kto był w podobnej sytuacji? Nie obawiam się konstruktywnej krytyki, o ile jest ona konstruktywna, a nie tylko dowodem na to, jak spieprzyłem. Wiem, że na StackExchange znajduje się strona z recenzjami kodu, ale tak naprawdę nie jest skonfigurowana dla dużych projektów i nie czułem, że społeczność jest wystarczająco duża, aby uzyskać dobre opinie, gdybym opublikował fragmenty mojego projektu fragmentarycznie (I próbowałem z jednym plikiem). Co mogę zrobić, aby mój projekt przynajmniej w pewnym stopniu się powiódł, nie zawstydzając się ani nie dezinwestując?

O ile projekt nie jest przeznaczony dla programistów (np. Środowisko programistyczne, w którym to przypadku CHCESZ ich skrytykować, jeśli uczysz się jeszcze więcej), nie powinieneś się martwić. Ale nawet wtedy istnieje wiele projektów open source skierowanych do deweloperów, którzy są gówniani, ale ludzie je uwielbiają, ponieważ idą do rzeczy (pomyśl o Codeigniter, który jest bardzo słabo skonstruowany, a jednak jest to najbardziej popularny framework php)

Jeśli jest to aplikacja dla zwykłych ludzi, prawdopodobnie będą dbali tylko o wyniki.

Twój kod ma problemy. Mój też. Czy ktoś jeszcze odpowiada na to pytanie? Ich kod też ma problemy.

O ile nie powiedzmy, 10 linii lub mniej, jest wadliwa. Może tragicznie.

Bycie programistą to CIĄGŁE zmaganie się z ograniczeniami twoich umiejętności i zrozumienia. Może nie być tak w przypadku WSZYSTKICH programistów, ale dla mnie i dla tych, których znam, pracujemy prawie na granicy naszych kompetencji przez cały czas. I ciągle się z tym mierzysz, potem masz miły weekend, a potem wracasz w poniedziałek i robisz to w kółko.

Przez 15 lat pracowałem nad tym życiem, na czym postanowiłem, to jeden fakt: nie jesteś swoim kodem . NAPISZ kod. Wyrok kodu NIE jest osądem ciebie . Twój kod ma problemy, niektóre znasz, inne nie. Zwrócenie na to uwagi pomaga , chyba że wszystko, co możesz zrobić, to źle się poczuć. Złe samopoczucie nie poprawia kodu, tylko sprawia, że ​​czujesz się źle.

Piszesz swój kod i piszesz go tak dobrze, jak wiesz. Może jutro dowiesz się więcej niż dzisiaj, ale dziś zrobiłeś to tak dobrze, jak wiedziałeś. Moja rada: napisz dzisiejszy kod dzisiaj, a kod jutro jutro. W takim razie życzę miłego weekendu i wrócę w poniedziałek, aby napisać poniedziałkowy kod.

Zasadniczo w otwartych źródłach programów są trzy grupy ludzi, którzy patrzą na kod źródłowy.

1. Ludzie, którzy rozważają modyfikację kodu, aby program działał dla nich nieco inaczej, aby przenieść go na inną platformę lub jako punkt wyjścia dla własnych programów. Jeśli kod im się nie podoba, zazwyczaj po prostu go nie użyje i nigdy się od niego nie odezwiesz.
2. Studenci, którzy próbują nauczyć się kodować w używanym języku. Ci prawie nigdy się z tobą nie skontaktują, ale czasami możesz otrzymać e-mail z pytaniem, dlaczego zrobiłeś coś w jedną stronę w drugą stronę. (Szczerze mówiąc, od wielu lat nie miałem żadnej z tych wiadomości e-mail. Myślę, że witryny takie jak StackExchange mogły zastąpić tę interakcję)
3. Badacze bezpieczeństwa, tacy jak faceci z OpenBSD, próbują zdecydować, czy twoje narzędzie jest wystarczająco bezpieczne, aby zostać uwzględnione w ich dystrybucji. Jeśli tak nie jest, ale nadal chcą włączyć Twój program, skontaktują się z Tobą, aby znaleźć sposób na jego zabezpieczenie. (A jeśli twój program stanie się popularny, wyobrażam sobie, że prawdopodobnie przyciągnie również badaczy w czarnym kapeluszu, którzy nie skontaktują się z tobą bez względu na to, co znajdą.)

W prawdziwym świecie ludzie naprawdę nie będą czytać kodu źródłowego z jakiegokolwiek innego powodu, ponieważ po prostu nie muszą. Wcześniej otrzymywałeś tylko tyle opinii, ponieważ opublikowałeś kod na forum, co sugerowało, że chcesz otrzymać informację zwrotną na temat kodu.

Nie sądzę, żebyś naprawdę musiał się martwić o potok przemocy; jedynymi osobami, które mogą się z tobą skontaktować, są ludzie, którzy chcą dodawać funkcje lub naprawiać błędy, którzy przeglądali już bazę kodów i nie krzyczą na wzgórza. ;)

Naprawdę nie rozumiem psychologii stojącej za tym pytaniem ... lepszym pytaniem byłoby „co muszę stracić przez wydanie tego oprogramowania”

Nawet jeśli twój projekt jest pełen zapachów kodu, czy musisz coś stracić?

Nawet jeśli kod jest okropny i ktoś poświęca trochę czasu na napisanie do ciebie ognistej poczty, zgadnij co, prawdopodobnie użył twojego oprogramowania na tyle, aby chcieć wprowadzić w nim zmiany i ulepszyć.

Powinieneś być z tego szczęśliwy! Zaakceptuj krytykę i popraw kod, poproś wściekłego faceta, który poświęcił czas na napisanie do ciebie. Jemu zależy!

Po pewnym czasie maile z płomieniami przestaną działać, ludzie będą nadal korzystać z twojego oprogramowania, nauczysz się na swoich błędach, a luk, o których istnieniu nie wiedziałeś, już nie będzie.

Wolałbym raczej pracować z kimś, kto chce coś zrobić, przyznać się do błędów, naprawić je i iść dalej, niż z kimś, kto nie chce nic zrobić.

Jeśli naprawdę nie czujesz się komfortowo, wypuszczając oprogramowanie pod swoim nazwiskiem, zwolnij je pod pseudonimem. Jeśli się powiedzie, wybierz go jako swój własny, jeśli nie, zmień swój pseudonim :)

Wierzę mocno nie tylko w open source, ale w otwarty rozwój , gdzie ludzie mogą zobaczyć pełną ewolucję twojego kodu. Od prototypu włosów po działający kod ... nigdy nie powinieneś się wstydzić. Stawiasz się tam - to wymaga odwagi. Posiadaj go i bądź z tego dumny. Nikt nie jest idealny.

Im dłużej jestem w tej grze, tym bardziej zdaję sobie sprawę, że jedyną miarą jakości kodu jest doświadczenie klienta. Jeśli piszesz funkcję, jest to wywoływacz tej funkcji. Biblioteka? Twórcy, którzy piszą dla tej biblioteki. Ramy? Adeptów tego. Samodzielny? Osoba lub demon, który uruchamia program.

Ładny kod ma swoją zaletę, nie zrozum mnie źle, ale kiedy jest już powiedziany i zrobiony, jedyną miarą jest „Czy to działa?” Widziałem dużo czystego kodu, który jest błędnym bałaganem, i mnóstwo satanistycznie zaburzonego kodu, który jest całkowicie niezawodny (plus dobre czyste i złe brzydkie :))

Jeśli więc krytycy twierdzą, że Twój kod jest brzydki, kogo to obchodzi. Jeśli powiedzą, że to nie działa - jest to przydatna krytyka (testowanie danych!), Którą chcesz ulepszyć swój program. Trzymaj się, unikaj populacji trolli w Internecie i baw się dobrze przy swoim projekcie!

Zdecydowanie zgadzam się z tym, co powiedzieli inni plakaty: nawet jeśli twój kod jest kiepski i nie ma wysokiej jakości - większości ludzi po prostu nie obchodzi. Każdy, kto kiedyś nurkował w kodzie OpenSource, mógł pomyśleć sobie: „WTF się tutaj wydarzyło”.

Ale nie znam nikogo, kto miałby motywację do krytykowania bazy kodu projektu tylko po to, by powiedzieć „koleś, twój kod wygląda okropnie!”. Wszyscy tam byliśmy i wszyscy wiemy, że każdy kod, który teraz piszemy, będzie dla nas dość kulawy w zaledwie kilku aspektach (mój zdecydowanie tak będzie).

Więc nie przejmuj się tak bardzo - ludzie po prostu mają dużo więcej czasu do roboty niż nitpowanie kodu projektów OpenSource.

Prawdziwy kod zawsze gnije i jest brudny, splatany i utrzymywany w przybliżeniu ad hoc. Oczyszczanie ogranicza się do dokumentowania specjalnych przypadków i specjalnych stałych. Istnieje niezgodność impedancji między czystym kodem a światem rzeczywistym.

Zauważyłem również, że każdy kompetentny inżynier może rozerwać kod innej osoby.

Jeśli (1) przejdzie testy i nie powiedzie się cel ORAZ (2) możesz dokonać drobnych zmian tylko z niewielkim przepisem, to dobry kod.

Kilka mądrych słów Reida Hoffmana, współzałożyciela LinkedIn:

„Jeśli nie odczuwasz wstydu w związku z pierwszym wydaniem produktu, wydałeś go zbyt późno.”

„Zdobycie zaangażowania z członkami i zobaczenie, co jest naprawdę ważne, jest całkowicie kluczowe… Aby jak najszybciej uzyskać minimalny opłacalny produkt.”

Myślę, że dotyczy to zwłaszcza projektów typu open source, w których dobry pomysł z obiecującym początkiem zachęca ludzi do udziału i uczestnictwa. Coś tak dopracowanego, że sprawia, że ​​zakładasz okulary przeciwsłoneczne, może nie wywoływać takich uczuć. Ale najważniejszą rzeczą we wczesnym wydaniu jest przełamanie wszystkich twoich uprzedzeń na temat tego, co należy zrobić i zacząć iść we właściwym kierunku.

Kim jesteś? Czy jesteś kimś, kogo ludzie znają jako programistą Boga i martwi się, że Twoja reputacja spadnie? Czy to ty zamierzasz ubiegać się o pracę i obawiasz się, że pracodawca może przeczytać tę krytykę i pomyśleć, że jesteś złym programistą? Pytam, dlaczego boisz się krytyki, jak spieprzyłeś. Możesz zdecydować, które są autentyczne komentarze, a które rants. Weź dobre jako wady i napraw je w następnej wersji. Po prostu czuję, że niepotrzebnie martwisz się krytyką. Pomagasz społeczności open source, która sama w sobie jest bardzo dobrą przyczyną. Proszę, kontynuujcie dobrą robotę.

Jeśli naprawdę się martwisz, użyj pseudonimu online podczas wypuszczania oprogramowania. W takim razie nie ma żadnego wpływu na twoją prawdziwą reputację.

Kiedy / Jeśli spotkasz się z publiczną krytyką, doprowadzi to do ulepszenia kodu i pomoże ci rozwijać się jako programista. To jest dobra rzecz.

Uważam, że w przypadku moich projektów najbardziej konstruktywna krytyka / sugestie są wysyłane prywatnie, a nie publicznie, i nawet wtedy nie będzie prawdopodobne, że otrzymają powódź komentarzy. Dlatego polecam po prostu iść na to!

Powodzenia.

Nie ma nic złego w samokształceniu. Nie możesz być odizolowany, a recenzje kodów równorzędnych mogą w tym pomóc.

Musisz także skupić się na tym, co robisz. Dlaczego przejmujesz się, jeśli otrzymujesz negatywną opinię o swojej pracy? Jeśli dzieje się tak dlatego, że zakładasz, że jeśli spotkasz się z krytyką, to dlatego, że kod jest zły lub nie jesteś dobry w programowaniu, może to być prawda.

Celem tego wysiłku jest upewnienie się, że kod działa i jak najlepsze wyodrębnienie kodu, ale z praktycznego doświadczenia, nie cały komercyjny kod jest gwiezdny. Czasami masz złe wymagania, czasem nie masz czasu, aby zrobić to dobrze. Czasami programiści chcą być geniuszem, sprawiając, że inni wyglądają źle.

Nie wierzę, że możesz się uczyć bez popełniania błędów, zwłaszcza jeśli wymaga to dyscypliny i wysiłku. Gdyby to było łatwe, wszyscy by to zrobili. Po prostu spróbuj ograniczyć błędy do mniejszych, stosując sprawdzone najlepsze praktyki. Zdaję sobie sprawę, że nie zawsze jest to możliwe!

Gdybym martwił się tym, co inni myślą o mnie jako programistą, w ogóle nie poszedłbym w to pole. Biorąc to pod uwagę, po raz pierwszy krytykuję kod, spróbuj wziąć go obiektywnie i wyciągnąć z niego wnioski.