Ile jeden programista może zrobić sam? [Zamknięte]

13

Gdy produkty opracowują całe zespoły ludzi, ile jeden programista może osiągnąć samodzielnie? Innymi słowy, czy jedna osoba mogłaby napisać Photoshop, słowo MS itp.? A jeśli nie, czy tworzenie stron internetowych byłoby obszarem, w którym jeden programista mógłby wiele zrobić?

błotnik 1901
źródło
2
Nie jestem pewien, o co tu pytają. Jeśli masz mojo do opracowania oprogramowania, możesz to zrobić samodzielnie - w sieci lub nie. Może to zająć trochę czasu, ponieważ MZ nie opracował Facebooka w ciągu jednego dnia.
CoolBeans,
Zajrzyj na blitwise.com, aby zobaczyć pracę pojedynczego dewelopera .
Michael K
Wydajność kodera jest bardzo zróżnicowana. Niektórzy koderzy kodują 10x + szybciej niż inni ...
Denis de Bernardy
2
Gdyby to był pojedynczy budynek devloper, photoshop i słowo ms, miałyby one rozmiar około 1/100. Nie uważam tego za złą rzecz.
JeffO,
1
To zależy. :-)
richard

Odpowiedzi:

14

Zacznij od małego

Linux jest obecnie znacznie większy niż jego pierwsze wersje, ale ważne jest to, że wyszedł z wystarczającą ilością rzeczy, aby zyskać przyczepność.

Tylko jeśli warto

Mam osobistą zasadę, że duże rzeczy są warte zrobienia, jeśli zasadniczo różnią się od pozostałych. W przeciwnym razie nurkujesz w czerwonym oceanie .

Dobrze zacząć, ale nie zawsze zrównoważony

Jeśli twoje oprogramowanie jest wystarczająco dobre, możesz poważnie się nim zająć. Weźmy na przykład Markusa „Notcha” Perssona, twórcę gry Minecraft. IIRC rozpoczął grę sam, a kiedy gra zyskała na popularności, zaczął szukać współpracowników, a nawet założył firmę.

Przynosząc satysfakcję z osiągnięcia czegoś samemu, duże projekty wykorzystują swój potencjał dzięki współpracy programistów, a nie jednemu geniuszowi, co prowadzi mnie do następnego punktu.

Mit

Sprawdź The Myth of the Genius Programmer , przemówienie Bena Collinsa-Sussmana i Briana Fitzpatricka na Google I / O 2009. Powinieneś mieć tam wszystkie fałszywe oczekiwania. Najważniejsze, że chcę tutaj wspomnieć, że czasami jeden programista dostaje uznanie za całość, podczas gdy za tym stoi więcej ludzi.

To zdecydowanie możliwe

Innym przykładem, oprócz Linusa Torvaldsa, jest John Carmack. Przeniesił Wolfensteina w zaledwie cztery dni, kiedy EA oszacował pełny zespół na dwa miesiące.

To nie jest ilość kodu, ale wiedza architektoniczna i techniczna, która pozwala osiągać wielkie rzeczy za pomocą mniejszej ilości kodu, niż można by się spodziewać.

Biorąc pod uwagę umiejętności i wiedzę (powyżej średniego poziomu), możesz sprawić, że dużo pracy wydaje się mało.

dukeofgaming
źródło
7
+1 IMO, Linus nie ma gówna na Carmacku. Jego rzeczy to legenda.
Steven Evers
1
kim jest legenda? Linus lub John. nie dostałem twojego slangu z powrotem
Chani
1
@RYUZAKI: Myślę, że komentarz @ SnOrfusa to całe pytanie dotyczące angielskiej wymiany stosów.
Spoike
1
@RYUZAKI - John ma legendę w komentarzu SnOrfusa.
ocodo
1
Czy Carmack dostał pełną pensję dla zespołu za 2 miesiące za 4 dni pracy, czy tylko klepnięcie w plecy?
Drew
5

Ze względu na charakter wykonywanej pracy sam opracowałem kilka całkiem dużych aplikacji. Tak, to wykonalne. Mógłbym o tym mówić godzinami, ale nie mam teraz dużo czasu, więc oto kilka zalet i wad osobistych doświadczeń.

Plusy:

  • masz pełną kontrolę i nie ma drużyny, z którą mógłbyś walczyć, więc możesz wybrać to, co uważasz / wiesz za najlepsze. Nie marnuj czasu na niekończące się dyskusje na temat małego aspektu kodu.
  • masz całą architekturę w głowie, wiesz dosłownie wszystko na ten temat, obsługa klienta to pestka, ponieważ znasz wszystkie odpowiedzi sam
  • dużo się uczysz o wszystkich aspektach programowania. Interfejs użytkownika niskiego, średniego, wysokiego poziomu, ...

Cons:

  • bez drużyny, z którą mógłbyś walczyć, więc czasami podejmujesz złe decyzje, o których nikt ci nie mówi
  • łatwo się w nim zagubić, nie widząc już dużego obrazu. I nie ma nikogo, kto mógłby ci pomóc. (z wyjątkiem SO / SA i podobnych:])
  • spędzać dużo czasu na obsłudze klienta, którą wolisz poświęcić na programowanie
stijn
źródło
3

Przy odrobinie poświęcenia i umiejętności jedna osoba z pewnością może wiele osiągnąć. Nie jest to jednak łatwe, wystarczy być dobrym programistą. Aby odnieść sukces w projekcie, często musisz pomyśleć o przypadkach użycia, projekcie interfejsu użytkownika, dokumentacji, wsparciu i wielu innych sprawach. Gdy sprawy zaczną się zmieniać, a liczba użytkowników będzie rosła, wszystko to w pojedynkę stanie się nierealne - w tym momencie albo więcej ludzi wchodzi do projektu (poprzez udział społeczności, zatrudnianie ludzi lub w inny sposób), albo projekt umiera.

Władimir Palant
źródło
1

Zależy to od oprogramowania, które on / ona próbuje opracować, ograniczenia czasowego i umiejętności. Jeśli opracowuje prostą aplikację MIS, jest bardzo prawdopodobne, że może to zrobić w krótkim czasie. Próba opracowania oprogramowania tak skomplikowanego jak Photoshop, MS Word, Blender, Flash itp. Jest możliwa, ale zajmuje dużo czasu i ma najbardziej podstawową funkcję, a funkcje są proste.

Tomek
źródło
1

Wszystko zależy od umiejętności, czasu i chęci. Im więcej masz wiedzy, tym mniej czasu zajmie Ci osiągnięcie czegoś. Zdobędziesz niezwykle intymną znajomość bazy kodu jako jedynego programisty, który może również przyspieszyć proces rozszyfrowywania / refaktoryzacji / debugowania.

Osobiście pracowałem nad aplikacją do przesyłania z komputera na serwer. Zakodowałem aplikację serwera, aplikację komputerową i przetestowałem to wszystko sam. Napisałem nawet instalator aplikacji. Wymyśliłem sposób, aby umożliwić przeciąganie i upuszczanie ikon na pasku zadań w systemie Windows, a nawet skończyło się na pisaniu nowej biblioteki Java od zera. Zrobiłem to w ciągu roku, który jest wciąż w fazie rozwoju i testów.

Cały ten projekt był jedną główną próbą. Codziennie po szkole pracowałem nad projektem, a także w weekendy. Czy jest tak masywny jak MS Word, Photoshop itp.? Nie. Projekt jest wciąż duży i wciąż się rozwija i można wiele osiągnąć.


źródło
Zobacz, o to się zastanawiałem ... może to potrwać dłużej, ale skoro wiedziałbyś, co robi cały kod, prawdopodobnie łatwiej byłoby go debugować. I wspaniałe doświadczenie edukacyjne.
fender1901
@ fender1901 Cóż, programowanie powinno być ciągle nauką, dzień, w którym nie jest, kiedy albo wiesz wszystko, albo musisz znaleźć trudniejsze zadanie.
1

Aktualnie pracuję nad takim projektem w wolnym czasie (jest to aplikacja internetowa, a nie aplikacja komputerowa, ale zasady są takie same). Oto, co znalazłem do tej pory:

1) Nie wymyślaj koła na nowo . Używaj istniejących bibliotek / frameworków, zamiast robić wszystko od zera. Jedno zastrzeżenie tutaj: pamiętaj, aby zwracać uwagę na licencje, które dotyczą wybranej dystrybucji / wydania / dowolnego modelu. Niektóre licencje copyleft będą wymagały otwartego źródła „pracy pochodnej”. Niektóre licencje zezwalają wyłącznie na użytek niekomercyjny. Śledź biblioteki / frameworki, których używasz, abyś mógł zapewnić odpowiednią atrybucję na ekranie / obszarze „Kredytów” / cokolwiek innego

2) Pracuj iteracyjnie . Jest to związane z tym, co powiedział dukeofgaming w „Start Small” . Bardziej prawdopodobne jest, że będziesz trzymać się projektu, jeśli zobaczysz wyniki. Dopóki nie zobaczysz, że coś działa, jakikolwiek rozwój, który wykonujesz, jest odpowiednikiem malowania w ciemności.

3) Nie bój się prosić o opinie / pomoc wcześnie . Możliwe, że nie jesteś dobry we wszystkim. Jeśli jesteś świetny w drobiazgowym podejściu do kodowania, prawdopodobnie masz do czynienia z interfejsem użytkownika. Dotyczy to również odwrotności. Nigdy nie boli zasięgać porady od tych, którzy są lepsi od ciebie w określonym obszarze. Wielu ludzi będzie tego unikać, ponieważ martwią się, że ktoś ukradnie ich pomysł. Nie martw się o to - jeśli ktoś spróbuje cię skopiować, oznacza to, że jesteś w coś wartościowego. Pomysły są tanie, wdrożenie jest kluczowe. Apple nie wynalazł odtwarzacza MP3, Microsoft nie wynalazł systemu operacyjnego, Facebook nie wynalazł sieci społecznościowej, a Google nie wynalazł wyszukiwarki. To, co zrobili, sprawiło, że było to atrakcyjne dla użytkowników (i nie było do bani).

Daniel Kitchener
źródło