Strach przed wydaniem projektu hobbystycznego - jak pokonać? [Zamknięte]

37

Nie wiem, czy to pytanie jest ściśle związane z tworzeniem oprogramowania, ale spróbuję:

Jak wielu programistów uwielbiam pracować nad projektami hobbystycznymi. Czasami pozornie dobre pomysły okazują się niezbyt dobre, więc rezygnuję z projektu. Ale czasami z projektu wychodzi coś pożytecznego. Więc mógłbym go wypuścić, przedstawić światu, prawda?

Źle. Jakoś nie wydaje mi się, że mogę zrobić ten krok. Obawiam się, że mój kod nie jest wystarczająco dobry, zawsze mogę myśleć o rzeczach, które nie są optymalne, o funkcjach, które można by dodać. Więc niczego nie wypuszczam, tracę zainteresowanie i w pewnym momencie porzucam projekt.

Czy to normalne? Jak przezwyciężyć taką sytuację?

Oliver Weiler
źródło
11
Cóż, to wystarczy dla ciebie i „oni” dostają to za darmo, więc dlaczego mieliby narzekać?
Joachim Sauer
42
„Obawiam się, że mój kod nie jest wystarczająco dobry” - jeśli spojrzysz wstecz na to, co zrobiłeś wczoraj i jesteś z niego zadowolony, to nie poprawisz się.
Roger Lipscombe
9
Jeśli to działa i nie jest kompletnym bałaganem spaghetti, zwolnij go. Z mojego doświadczenia wynika, że ​​cały kod jest krytykowany, przyzwyczaj się do niego. Microsoft wydał cały ładunek kodu do włączenia do Linuksa. Wydaje mi się, że pamiętam, że został odesłany w celu uporządkowania i skończył z połową więcej wierszy. Codziennie patrzę na swój kod i myślę: „O Boże. Czy to napisałem? Doh!
Jaydee,
4
Nigdy nie poprawi się bez ludzi, którzy się na tym bawią. Idź po to!
Scott C Wilson,
4
Chciałbyś! Powinieneś uważać się za szczęściarza, jeśli ktoś zauważy, że opublikowałeś jakiś kod :)
Benjol

Odpowiedzi:

51

Przede wszystkim pamiętaj: wysyłka jest funkcją . Lepiej jest uwolnić coś niedoskonałego niż w ogóle nic.

Należy również zauważyć, że są to projekty Hobby. Jeśli nie dotrzymasz terminów lub stracisz zainteresowanie, to nie jest wielka sprawa. W końcu robisz projekt dla zabawy.

Tom Squires
źródło
23

Połóż to tam.

Nie jest to trudne do zrobienia z serwisami społecznościowymi, takimi jak GitHub lub Bitbucket . Większość rzeczy, które wydasz, prawdopodobnie nie będzie często używana, ale to jest w porządku. Jest to prawie normalne w tych witrynach do kodowania społecznościowego i wiele projektów jest porzucanych (nawet tych przydatnych). Ale największą rzeczą jest to, że inni mogą odebrać to, co zostawiłeś (pod warunkiem, że masz pozwolenie).

Mimo że twoje rzeczy prawdopodobnie nie będą wykorzystywane przez nikogo innego, istnieje kilka korzyści z tego, dlaczego nadal powinieneś to robić:

  • Nauczysz się korzystać z kontroli wersji, co jest czymś, czego wielu programistów nie wie jak, co czyni cię bardziej pożądanym
  • Ludzie mogą wskazywać na problemy; wszystkie możliwości uczenia się, jak robić różne rzeczy
  • Będziesz miał portfel rzeczy, które zrobiłeś online, świetnie mieć je jako uzupełnienie swojego CV
Łup
źródło
3
+1 za „Ludzie mogą wskazywać na problemy” - to ogromna korzyść z oferowania kodu jako open source.
Andrew Thompson,
14

Umieszczenie współpracowników w projekcie open source, który jest już wolny od błędów, jest prawdopodobnie trudniejsze niż w przypadku wielu łatwych błędów do rozwiązania, ponieważ są one zachętą dla pierwszych użytkowników do zapoznania się z kodem.

Kiedy Linus po raz pierwszy wprowadził jądro Linuksa, nie był to kompletny, stabilny, wolny od błędów i czysty kod; była niekompletna, gówniana, niemożliwa do przeniesienia i podłączona do klawiatury fińskiej .

Lie Ryan
źródło
3
Uwielbiam tę perspektywę.
TehShrike
+1 dla przykładu Linux.
Calmarius
6

Zasadniczo nie martwiłbym się, czy ludzie lubią mój kod, czy nie. Wydaj ją na podstawie bezpłatnej licencji, jeśli jest przydatna dla ludzi, ale znajdują błędy, nieoptymalne rozwiązania i wymagają więcej funkcji, mogą je naprawić samodzielnie. Korzystanie z GPL lub LGPL pozwoli ci również znaleźć te poprawki, a możesz je zastosować samodzielnie, jeśli uznasz je za przydatne / pasujące.

martiert
źródło
5

Przepraszam, ale robisz dokładnie odwrotność tego, co powinieneś robić!

Zwolnij go tak szybko, jak to możliwe, wysłuchaj opinii użytkowników, a następnie zaimplementuj nową funkcjonalność na tej podstawie. Nie na odwrót!

Thomas Bonini
źródło
Jest to prawdą tylko wtedy, gdy próbujesz zoptymalizować użyteczność. PO wyraźnie stara się zmaksymalizować kredyty uliczne lub przynajmniej zminimalizować zakłopotanie.
Caleb
2
@Caleb: to zawsze prawda. Celem jest zawsze wysyłanie produktu i nigdy nie pisać kodu!
Thomas Bonini
Nie zapominaj, kontrola wersji pozwala ludziom widzieć ULEPSZENIA w kodzie. Widząc, że ktoś zaczynał od złego kodu, ale był w stanie go przekształcić w dobrze wyglądający przykład, pokazuje: a) Mogą się uczyć, b) są gotowi ulepszyć stary kod zamiast go zignorować
Aren
4

Co musisz stracić?

Możesz również pocieszyć się wiedząc, że prawdopodobnie i tak nie zostanie zauważony, chyba że jest naprawdę dobry lub nie wypełni nowej niszy.

A jeśli otrzymasz negatywną opinię - jest to szansa na naukę. Nie marnuj jej.

Evgeni
źródło
„Prawdopodobnie i tak nie zostanie zauważony”. Niestety bardzo prawda.
user16764
3

Zupełnie normalne, w każdej dziedzinie poza oprogramowaniem. Upewnij się, że działa w kilku różnych środowiskach, napisz plik README i wrzuć go do github / codeplex / etc. Pokonanie tego po raz pierwszy jest jedynym sposobem na przezwyciężenie lęku.

Drugi, trzeci i n-ty czas to zabawa!

Matt Stephenson
źródło
1

Oto jeden z powodów wydania niedokończonego oprogramowania: zacząć budować społeczność. Jeśli chcesz, aby Twój projekt stał się użytecznym narzędziem typu open source, potrzebujesz innych programistów. Jednym ze sposobów na ich przyciągnięcie jest wcześniejsze wydanie, a następnie (publiczne) wprowadzenie ulepszeń. Nie dodawaj tych funkcji w tajemnicy - rób to publicznie, na stronie Github lub gdziekolwiek. To generuje aktywność w historii.

Inni programiści nie chcą pracować nad pozornie porzuconym projektem. Tak więc publiczne prace rozwojowe pokazują aktywne i ciągłe zainteresowanie. Warto celowo przechowywać kilka funkcji w rękawie, aby można je było dodawać publicznie.

Steve Bennett
źródło