Vlákno názorů k článku Historie vývoje textových editorů: programátorské textové editory pro DOS od mhi - "jednalo o projekt vytvořený jediným člověkem, na rozdíl...

  • Článek je starý, nové názory již nelze přidávat.
  • 24. 11. 2015 13:31

    mhi (neregistrovaný)

    "jednalo o projekt vytvořený jediným člověkem, na rozdíl od komerčních IDE."

    kupodivu velke mnozstvi komercne VELMI USPESNYCH a ZNAMYCH projektu byly tvoreny primarne prave jednim clovekem (a nekolika "poskoky" na reseni drobnych uloh). Je to dle meho nazoru dano tim, ze team leader ma nejakou vizi a jen rozda ukoly co a jak delat, jenze ti pod nim se casto hodi opravdu jen na drobne upravy nejakeho pomocneho kodu.

    Vychazi mi to prave z komunikace s par takovymi lidmi. Kupodivu jsou docela sdilni, i kdyz komunikace je obcas dost obtizna, protoze do jedne vety dostanou tolik o cem by se dala napsat cela knizka, tak potom chapejte jak to mysleli :-).

  • 24. 11. 2015 14:02

    Pavel Tišnovský
    Zlatý podporovatel

    To je pravda, takovej Turbo Debugger maji na svedomi snad jen dva lidi.

    Ale Turbo/Borland C/Pascal delala vetsi skupina vyvojaru (ted myslim verzi 2+, ne ty puvodni jeste pro CP/M). V tom vyvojovem prostredi staci v About dialogu stlacit tusim Alt+I a vyjede seznam. Vlastne, napriste udelam screenshot a bude :)

  • 24. 11. 2015 15:03

    Jan (neregistrovaný)

    "Je to dle meho nazoru dano tim, ze team leader ma nejakou vizi a jen rozda ukoly co a jak delat, jenze ti pod nim se casto hodi opravdu jen na drobne upravy nejakeho pomocneho kodu."

    Viz "Fred Brooks: The Mythical Man-Months. Addison-Wesley, 1975"

    Škoda, že to není povinná literatura pro projekťáky, takže se tito dopouštějí už 40 let stále stejných chyb a není jim pomoci. Brooks totiž přesně toto tvrdí, že SW projekt je ze své podstaty spíš práce stylem jeden operatér + sekundáři, kdy operatér má vizi, představu, jak by to celé mělo vypadat a fungovat, navrhuje a sám píše nejdůležitější části a ostatní lidi má spíše jen k ruce, aby se zabývali mechanickou, méně podstatnou, dílčí prací, jež by ho akorát zdržovala a rozptylovala.
    A vůbec, celá kniha je plná zajímavých postřehů z vývoje velkého SW projektu (systému Multics) a nápadů na jejich řešení. V praxi vidím, že se ale stále opakují tytéž chyby, proto také ty projekty vypadají, jak vypadají, a IT potřebuje stále víc a víc "lidských zdrojů".

  • 24. 11. 2015 17:03

    Lemming (neregistrovaný)

    Problém je, že tohle funguje do určité velikosti projektu. U malých projektů lze fungovat stylem "osamělý vlk" a to umí být opravdu velmi efektivní uspořádání.

    Jak se projekt zvětšuje, je potřeba přibírat pomocníky, protože to už jeden člověk nenakóduje. Těm je nutno vysvětlovat, co a jak mají dělat - a mandaye se začnou utápět v komunikaci místo v kódování. Nepříliš dobří pomocníci potřebují pořádný dohled, dobří ho sice nepotřebují, ale zas vám nebudou ochotni moc dlouho dělat jen "lopaty" hlavnímu člověku.

    U ještě větších projektů pak přichází to, že je jeden člověk v hlavě už prostě neudrží.

    A další problém podobného systému je zastupitelnost. Když má celek projektu v hlavě jen jeden člověk a něco se mu stane nebo se s ním rozhádáte, tak to můžete zabalit.

    Co se týče "strašné" moderní doby, tak výsledkem podobných úvah je třeba pozice SW architekta - člověka co má přehled o pokud možno celém systému, byť na poměrně high-level úrovni, aby to zvládl udržet v hlavě.

  • 24. 11. 2015 17:16

    mhi (neregistrovaný)

    Dovolim si lehce nesouhlasit, existuje nekolik hodne velkych projektu (alespon dnes velkych), kdy na zacatku ten vizionar musel byt, musel navrhnout treba API, apod. Samozrejme, v dalsich fazich dela stale mene prace v pomeru k velikosti aplikace, ale praci velmi dulezitou, a to usmerneni vyvoje. Krasne je absence takoveho cloveka videt na Windows a jeho API.

    Bohuzel nemohu jmenovat konkretni jmena lidi a konkretni projekty, ale skoro kazdy je pouziva.

    Ad PT a Turbo Pascal vyse: s nikym z teamu TP se neznam ani po mailu, ale prave u TP mi kdysi davno nekdo vypravel, ze cely ten design stoji na jednom cloveku a hromade pricmrndavacu (sorry ze takhle znevazuju jejich postaveni :) ). Je to ale jedna-pani-povidala. U jinych projektu to mam z prvni ruky.

  • 24. 11. 2015 20:05

    atarist (neregistrovaný)

    Ad: "ale prave u TP mi kdysi davno nekdo vypravel, ze cely ten design stoji na jednom cloveku a hromade pricmrndavacu"

    však o tom to je, to je rozdíl mezi one man show a týmovou prací, kde je jeden architekt (kterej klidně může programovat strukturu či naopak se zaměřit na to nejdůležitější).

    Právě díky tomu, že tomu supermanovi pomáhali borci s maličkostma, tak to mohl dokončit a asi ho to i bavilo. Ale jinak řešit problémy typu "v této situaci mě nejde menu", na to stačí každej, časově náročná a přitom jak píšeš pricmrndávačská práce, bez které to ale nejde.

  • 24. 11. 2015 21:32

    jm

    U zrodu Turbopascalu byli špičkoví minimálně dva - Anders Hejslberg měl na svědomí kompilátor, Philipe Kahn k němu vyrobil UI, které z TP udělalo bestseller.

  • 24. 11. 2015 21:47

    Lemming (neregistrovaný)

    Já myslím, že nejsme ve sporu. Samozřejmě určitě existují projekty, které na začátku byly obsáhnutelné jedním člověkem a mohly se tak vyvíjet a teď jsou větší. Ale jak se zvětšily, tak se od toho modelu "jeden člověk řídí všechno" muselo ustoupit, nebo se musel přesunout na vyšší úroveň abstrakce.

  • 24. 11. 2015 22:59

    Kiwi (neregistrovaný)

    Přesně to, co píšeš, je IMHO právě to nepochopení celé té myšlenky. Brooks naopak tvrdí, že i velký projekt je třeba vést jedním mozkem. A společně s ním Chuck Moore dodává, že jakkoli velký projekt je možné dekomponovat tak, aby to bylo možné.
    A naopak, i relativně jednoduchý projekt může postupně hypertrofovat do obludné hydry, když chybí autorita, která by ho dlouhodobě vedla.

  • 25. 11. 2015 9:11

    korporát (neregistrovaný)

    Z předchozí odpovědi bych zdůraznil tu zastupitelnost. Z pohledu korporace je spoléhání se na jediného člověka u většího projektu až neúnosně riskantní, ať už proto, že ho může "srazit autobus", či proto, že se tak dostává do příliš silné vyjednávací pozice.

    Ony "stále se opakující chyby" jsou potom pojištěním vůči tomuto riziku a jako každé pojištění se i toto zdá ve většině případů (kdy se nic nestane) zbytečně drahé.