Jaký editor pro psaní zdrojáků v jazyce C?

anonym

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #75 kdy: 20. 01. 2019, 00:14:08 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?

Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.

Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.


Kit

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #76 kdy: 20. 01. 2019, 00:23:30 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?
Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.
Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.

Klidně, ale předem upozorňuji, že do Prahy kvůli tomu nepojedu.

anonym

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #77 kdy: 20. 01. 2019, 01:22:42 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?
Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.
Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.

Klidně, ale předem upozorňuji, že do Prahy kvůli tomu nepojedu.

This is the guy! Ty si vazne myslis, ze jsu vsichni na backendu takove lamy, ze nepouzivaji Vim ale poradne IDE? To je uplny vtip. O vimu jsem slysel zatim jen od jednoho apokalyptickeho javascriptare a ccskare, na webdevelopment to je mozna tak dobre...

Raskal

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #78 kdy: 20. 01. 2019, 01:28:36 »
Na Linuxu jsem pouzival KDevelop (https://www.kdevelop.org/) a Netbeans (https://netbeans.org/features/cpp/).

Obe IDE pro me byly OK. Jinak psat se da samozrejme v jakemkoliv textovem editoru, ale pak mozna prichazis o zajimave funkce napomocne pri psani jako je automaticke doplnovani, asistence s refaktoringem, zjednoduseny pristup k napovede, validace kodu a spoustu dalsich funkci, ktere ti pri vyvoji umoznuji soustredit se na problem, ktery ma program resit.

Padlo zde, ze netbeans nejsou OK, ale zadny argument proc jsem k tomu uz nevidel. Sice nejsou primarne pro C/C++, ale to neni dukaz jejich nekompetence.

@Dotcenym: Je to parada, jak se tu huste zminuje vim a emacs. Lidi, ten clovek nehleda hardcore konzolovy editor, ktery si dostavi pro editaci cecka! To by to sem asi napsal! Pta se na to, v cem se dobre pise C. Tento vas pristup zda se mi ponekud kontraproduktivni...

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #79 kdy: 20. 01. 2019, 08:53:11 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?
Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.
Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.

Klidně, ale předem upozorňuji, že do Prahy kvůli tomu nepojedu.

This is the guy! Ty si vazne myslis, ze jsu vsichni na backendu takove lamy, ze nepouzivaji Vim ale poradne IDE? To je uplny vtip. O vimu jsem slysel zatim jen od jednoho apokalyptickeho javascriptare a ccskare, na webdevelopment to je mozna tak dobre...

Na webdevelopment to právě dobré není.


Kiwi

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #80 kdy: 20. 01. 2019, 10:34:47 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?

Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.

Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.

anonym

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #81 kdy: 20. 01. 2019, 10:55:36 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?

Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.

Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.

Kiwi, na co se specializujes, co vyvijis za typ sw? Protoze jsi zkuseny a chytry, tak to nemyslim nijak ofenzivne, jak to tady na rootu vetsinou delam. Ja jsem zazil za svou ne moc dlouho karieru celkem 3 backendove enviromenty (u 3 ruznych zakazniku), a ze nejaka dulezita komponenta se v prubehu let takto rozroste je uplne bezne a skoro mi prijde, ze az nevyhnutelne, ikdzy kazdy vi, ze by to tak byt nemelo. Proto si myslim, ze ty urcite nevyvijis velke informacni systemy, protoze to by bylo pro tebe piece of shit uplne vsechno. Ale mozna, ze mas nejaky svaty gral a umis to lip?

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #82 kdy: 20. 01. 2019, 11:15:17 »
Kiwi, na co se specializujes, co vyvijis za typ sw? Protoze jsi zkuseny a chytry, tak to nemyslim nijak ofenzivne, jak to tady na rootu vetsinou delam. Ja jsem zazil za svou ne moc dlouho karieru celkem 3 backendove enviromenty (u 3 ruznych zakazniku), a ze nejaka dulezita komponenta se v prubehu let takto rozroste je uplne bezne a skoro mi prijde, ze az nevyhnutelne, ikdzy kazdy vi, ze by to tak byt nemelo. Proto si myslim, ze ty urcite nevyvijis velke informacni systemy, protoze to by bylo pro tebe piece of shit uplne vsechno. Ale mozna, ze mas nejaky svaty gral a umis to lip?

hádám, že tazatel vyvíjí jiný typ aplikací.

Kit

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #83 kdy: 20. 01. 2019, 11:20:45 »
Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.

Dělám na projektu, který je ještě o něco větší. To se nasbírá. Je ale fakt, že jsem ho už docela dost zredukoval, protože tam bylo dost zbytečností z IDE jenom proto, že je někdo nechal vygenerovat.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #84 kdy: 20. 01. 2019, 11:51:54 »
Jinak slusne se pise i ve Visual Studio Code, ale je treba mit spravny plugin (na vetsi projekty se mi oplatilo pouzivat plugin cquery)

Vyzkoušel někdo to cquery? To dokáže oindexovat i chromium nebo linux kernel. 350k řádků by neměl být problém.

Hádají se tu dvě skupiny lidí. Uživatelé editorů, kteří nepoužívají nebo neumí použít pokročilý tooling, a Javisté používající monolitická IDE.
« Poslední změna: 20. 01. 2019, 11:55:30 od gll »

anonym

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #85 kdy: 20. 01. 2019, 12:11:24 »
Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.

Dělám na projektu, který je ještě o něco větší. To se nasbírá. Je ale fakt, že jsem ho už docela dost zredukoval, protože tam bylo dost zbytečností z IDE jenom proto, že je někdo nechal vygenerovat.

Ty jsi PHPkar, jenom jestli tech tvych 350000 radku kodu neni z 80% html, to se samozrejme nepocita.

Kit

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #86 kdy: 20. 01. 2019, 12:18:05 »
Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.
Dělám na projektu, který je ještě o něco větší. To se nasbírá. Je ale fakt, že jsem ho už docela dost zredukoval, protože tam bylo dost zbytečností z IDE jenom proto, že je někdo nechal vygenerovat.
Ty jsi PHPkar, jenom jestli tech tvych 350000 radku kodu neni z 80% html, to se samozrejme nepocita.

Dělám na backendu, není v tom ani kousek HTML. To má na starosti někdo jiný.

Kiwi

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #87 kdy: 20. 01. 2019, 12:47:49 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?

Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.

Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.

Kiwi, na co se specializujes, co vyvijis za typ sw? Protoze jsi zkuseny a chytry, tak to nemyslim nijak ofenzivne, jak to tady na rootu vetsinou delam. Ja jsem zazil za svou ne moc dlouho karieru celkem 3 backendove enviromenty (u 3 ruznych zakazniku), a ze nejaka dulezita komponenta se v prubehu let takto rozroste je uplne bezne a skoro mi prijde, ze az nevyhnutelne, ikdzy kazdy vi, ze by to tak byt nemelo. Proto si myslim, ze ty urcite nevyvijis velke informacni systemy, protoze to by bylo pro tebe piece of shit uplne vsechno. Ale mozna, ze mas nejaky svaty gral a umis to lip?
Moje specializace je průmyslová automatizace (a jako editor vim :) ). Nejraději embedded části, ale jsem nucen dělat i na frontendech.

Ale proto jsem psal "komponenta" do uvozovek. Kdybys napsal, že děláš na aplikaci, která má 350 kLOC, beru. Ale pod komponentou si představím stavební blok. Pravda, pod tím se dá představit i jeden blok atomové elektrárny - jako jedna komponenta. Ale stejně mi to připadá takové... nelidské, aby "komponenta" měla statisíce řádků. A dost mě dráždí, když se někdo holedbá počtem LOC svého projektu. To přece není nic, nač by měl být člověk pyšný nebo čím se chlubit. Vyvstává u toho totiž otázka, zda je to opravdu tak velký projekt, nebo je jen tak blbě napsaný. U těch embedded částí je obvykle člověk nucen u toho víc přemýšlet vzhledem k omezeným možnostem "malých" procesorů (bohužel už se taky šíří nešvar, kdy se na triviální úlohu raději nasadí kanón, aby se na něm dal rozjet nějaký poměrně velký OS, pro nějž se napíše párřádkový prográmek zajišťující požadovanou funkcionalitu, který ovšem z daného OS využívá jen nepatrný zlomek). Ale u těch frontendových aplikací mě to dráždí jak červený hadr býka - každou chvíli si připadám jak Feynmann, když zíral na větu "jednotlivý člen sociální skupiny často přijímá informace cestou vizuálních symbolických kanálů", aby po nějaké chvíli došel k závěru, že autor chtěl jen napsat "lidé čtou". Tak přesně tak se dnes programuje - pak se nedivme, že projekty mají statisíce, miliony LOC. Prostě když srovnám software ze 70. až počátku 90. let s tím současným analogickým, tak si kladu otázku, kde se projevuje ten řádový rozdíl v počtu LOC na funkcionalitě toho software. Zatím mám pocit, že ten počet LOC akorát úspěšně kompenzuje rostoucí výkon hardware, takže výsledný dojem je podobný. Mladší generace se na starší počítače dívá skrz prsty, aniž by znala jejich schopnosti a možnosti. Ale počítač ADT 4000 z produkce ZPA (klon HP 2100) dokázal uřídit 800MW elektrárnu a lidi, kteří ho to naučili, byste spočítali na prstech jedné ruky. Dnes tam máte řádově výkonnější systém, který programovalo řádově více lidí a software má řádově více LOC, ale přitom dělá v podstatě totéž. A dokonce to nebylo ani rychleji uvedené do provozu, ani to není spolehlivější.

"Velký informační systém" je velmi vágní pojem a měřítko LOC je velmi pochybné. A když si pohlédnuv na to stádo kolem sebe někdy položím otázku, zda to opravdu nejsem já, kdo je mimo, tak si vzpomenu, že existují lidé, kterým ani já, ani nikdo z toho stáda nesahá ani po kotníky, ale dospěli nezávisle ke stejným závěrům, jako já:

https://www.youtube.com/watch?v=ubaX1Smg6pY

Proto jsem přesvědčen, že čím více LOC, tím horší kus software. Chtěl bych někdy vidět software, jehož půl milionu LOC se také odráží v jeho funkcionalitě. A zároveň, k čemu se taková funkcionalita prakticky využívá. Jestliže CAD na návrh mikroprocesorů může napsat jediný člověk tak, že se vejde na 3.5" disketu, a narozdíl od molochů od Mentorů umí navrhovaný chip odsimulovat v reálném čase na úrovni polovodiče i se zohledněním teplotních poměrů (OKAD Chucka Moora), tak mě těžko může někdo přesvědčovat o tom, že něco nejde napsat kratší.

Kit

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #88 kdy: 20. 01. 2019, 13:13:28 »
Proto jsem přesvědčen, že čím více LOC, tím horší kus software.

Uvažuji stejně. K čemu je mi knihovna, která má 5000 LOC, když téhož výsledku dosáhnu na 50 řádcích? Navíc bez chyb, které v té knihovně jsou a mí předchůdci je museli pracně obcházet?

anonym

Re:Jaký editor pro psaní zdrojáků v jazyce C?
« Odpověď #89 kdy: 20. 01. 2019, 13:44:36 »
Vim mi produkuje krásný kód přímo, v podstatě ho nerozeznáš od kódu napsaného v IDE a nemusím se přitom nějak zvlášť snažit. Hlídá závorky i odsazení a identifikátory našeptává.
Jak generujes ve Vimu method call hierarchie?

Předně se naučíš psát kód tak, abys tuto zbytečnost nepotřeboval. Jinak je k tomu určen plugin ctags.

Kite Kite, Kytiku... kdy ty uz konecne pochopis, ze neni na svete jen ten tvuj webdevelopment. Moje komponenta ma 220 tisic radku kodu, vsech radku vseho mozneho vc. liquibase je tam 350tis. Mohl bys nam to nekdy prijit na backend s tim svym VIMem nandat.
"Komponenta", co má 350 tisíc LOC? To není "komponenta", ale piece of shit.

Kiwi, na co se specializujes, co vyvijis za typ sw? Protoze jsi zkuseny a chytry, tak to nemyslim nijak ofenzivne, jak to tady na rootu vetsinou delam. Ja jsem zazil za svou ne moc dlouho karieru celkem 3 backendove enviromenty (u 3 ruznych zakazniku), a ze nejaka dulezita komponenta se v prubehu let takto rozroste je uplne bezne a skoro mi prijde, ze az nevyhnutelne, ikdzy kazdy vi, ze by to tak byt nemelo. Proto si myslim, ze ty urcite nevyvijis velke informacni systemy, protoze to by bylo pro tebe piece of shit uplne vsechno. Ale mozna, ze mas nejaky svaty gral a umis to lip?
Moje specializace je průmyslová automatizace (a jako editor vim :) ). Nejraději embedded části, ale jsem nucen dělat i na frontendech.

Ale proto jsem psal "komponenta" do uvozovek. Kdybys napsal, že děláš na aplikaci, která má 350 kLOC, beru. Ale pod komponentou si představím stavební blok. Pravda, pod tím se dá představit i jeden blok atomové elektrárny - jako jedna komponenta. Ale stejně mi to připadá takové... nelidské, aby "komponenta" měla statisíce řádků. A dost mě dráždí, když se někdo holedbá počtem LOC svého projektu. To přece není nic, nač by měl být člověk pyšný nebo čím se chlubit. Vyvstává u toho totiž otázka, zda je to opravdu tak velký projekt, nebo je jen tak blbě napsaný. U těch embedded částí je obvykle člověk nucen u toho víc přemýšlet vzhledem k omezeným možnostem "malých" procesorů (bohužel už se taky šíří nešvar, kdy se na triviální úlohu raději nasadí kanón, aby se na něm dal rozjet nějaký poměrně velký OS, pro nějž se napíše párřádkový prográmek zajišťující požadovanou funkcionalitu, který ovšem z daného OS využívá jen nepatrný zlomek). Ale u těch frontendových aplikací mě to dráždí jak červený hadr býka - každou chvíli si připadám jak Feynmann, když zíral na větu "jednotlivý člen sociální skupiny často přijímá informace cestou vizuálních symbolických kanálů", aby po nějaké chvíli došel k závěru, že autor chtěl jen napsat "lidé čtou". Tak přesně tak se dnes programuje - pak se nedivme, že projekty mají statisíce, miliony LOC. Prostě když srovnám software ze 70. až počátku 90. let s tím současným analogickým, tak si kladu otázku, kde se projevuje ten řádový rozdíl v počtu LOC na funkcionalitě toho software. Zatím mám pocit, že ten počet LOC akorát úspěšně kompenzuje rostoucí výkon hardware, takže výsledný dojem je podobný. Mladší generace se na starší počítače dívá skrz prsty, aniž by znala jejich schopnosti a možnosti. Ale počítač ADT 4000 z produkce ZPA (klon HP 2100) dokázal uřídit 800MW elektrárnu a lidi, kteří ho to naučili, byste spočítali na prstech jedné ruky. Dnes tam máte řádově výkonnější systém, který programovalo řádově více lidí a software má řádově více LOC, ale přitom dělá v podstatě totéž. A dokonce to nebylo ani rychleji uvedené do provozu, ani to není spolehlivější.

"Velký informační systém" je velmi vágní pojem a měřítko LOC je velmi pochybné. A když si pohlédnuv na to stádo kolem sebe někdy položím otázku, zda to opravdu nejsem já, kdo je mimo, tak si vzpomenu, že existují lidé, kterým ani já, ani nikdo z toho stáda nesahá ani po kotníky, ale dospěli nezávisle ke stejným závěrům, jako já:

https://www.youtube.com/watch?v=ubaX1Smg6pY

Proto jsem přesvědčen, že čím více LOC, tím horší kus software. Chtěl bych někdy vidět software, jehož půl milionu LOC se také odráží v jeho funkcionalitě. A zároveň, k čemu se taková funkcionalita prakticky využívá. Jestliže CAD na návrh mikroprocesorů může napsat jediný člověk tak, že se vejde na 3.5" disketu, a narozdíl od molochů od Mentorů umí navrhovaný chip odsimulovat v reálném čase na úrovni polovodiče i se zohledněním teplotních poměrů (OKAD Chucka Moora), tak mě těžko může někdo přesvědčovat o tom, že něco nejde napsat kratší.

jak vidis, muj prispevek ma spoustu radku protoze se mi nechtelo minimalizovat tvoji odpoved a jen jsem klikl na qute :)

Ta komponenta na ktere pracuju je sracka, ale videl jsem i mnohem mnohem horsi - v tech 350000 radcich je totiz aspon vcelku poradek. Spousta kodu je tam redundantniho, je tam rada funkcionalit ktere se preplacavaly dalsimi funkcionality s tim, jak chodily pozadavky z businessu a cas na refaktoring by byl tak znacny, ze se to nikomu delat nechtelo. V enviromentu, kde jsem, pracuje celkem asi tak 100 lidi, a historicky se na tom enviromentu prostridali lidi s fluktuaci 10% rocne.

Problem objemnosti techto komponenty je natolik komplexni, ze pochybuju, ze by to dokazal vyresit sebelepsi vyvojar. Faktory ktere zde pusobi a jsem si jich vedom:

1.) Velke mnoztvi vyvojaru vede k celkove prumernosti a celkova prumernost vede ke srackoidnimu kodu protoze tak pracuje prumerny vyvojar nejen ve fazi implementace, ale i ve fazi analyzy pozadavku a davani zpetne vazby stupidnimu zakaznikovi, ktery zadava pitchoviny ale musi se ctit, protoze je to zakaznik.
2.) Vyvoj softwaru formou bodyshopingu, kde IT korporaty ziskavaji marze z odporacovanych mandays, nemotivuje k redukci kodu, ale k prumernosti. Prumernost znamena prebytecnost kodu a vede k potrebe dalsich pracovnich sil, cili ke zvyseni prijmu korporace, coz je pro korporaci v podstate chtena vec - neni v jejim zajmu aby byla vyjimecne dobra a psala krasny cisty kod s minimem potrebnych pracovnich sil, prave naopak by rada byla spise prumerna.
3.) Zakaznikuv management si o to rika sam, protoze i ten tlaci cenu za vyvojare dolu co jen muze, coz samo rovnez nemuze vezt k vyjimecnemu vyvoji.
4.) Zakaznici zpravidla vystrci nejakeho debilniho product ownera, napr. sociolozku, ktera nikdy nenapsala ani hello world.
5.) Management ktery rozhoduje o vecech zpravidla tvori lidi, kteri rovnez nikdy neprogramovali. V podstate stavbu ridi lidi, kteri v zivote nedrzeli v ruce cihlu. Napr. muj momentalni projektovy manager je vystudovany politolog, videl jsem i hudebnika.


Dale tvoje business logika je beztak mnohem jednodussi nez u techto systemu. Ty mas u enbedded zadani jasne, u techto informacnich systemu je zadani zpravidla nejasne, navic velmi opinionated a jeste navic nezminimalizovane. Mnohem vice se implementuje zadani adhoc, tak jak proste prislo od analytiku, protoze jako vyvojar neznas zakouti business logiky dostatecne jasne na to, aby jsi ho zpracoval.

Dam priklad: rekneme ze delas treba telco, to je takove pekne pro predstavu. Operator, treba O2, ma ruznou nabidku mobilnich tarifu a dalsich kokotin kolem toho. Kdyz se nad tim zamsylis, vsechen ten bordel je redukovatelny do jednoduche male tabulky:

Cena za 1 minutu volani
Cena za 1 MB dat
Cena za 1 sms
Cena volani do zahranici

Na sve SIM pak mas kredit, kde odvadis automaticky pravidelnou platbu. A operator ma jen tento jeden tarif - vic neni potreba.

Tohle je technicka minimalizace nabidky sluzby operatora. Kokoti v managementu a lisaci v marketingu kolem toho ale vymysli hromadu kokotin ve forme ruznych tarifu a pausalu a ruznych "vyhodnych: nabidek. Udelaji to proto, ze vi, ze lidi jsou dementi a mysli si, ze maji takto produkt usity na miru, presne pro jejich potreby a ze je to pro ne vyhodnejsi. V realite ale to pro ne neni vyhodnejsi ani financne - oni se jenom domnivaji ze by melo byt, a jeste k tomu musi mit hlavu plnou pitchovin obsahujici nabidku operatora - mozna ze je to soucast marketingu a vymyvani mozku zakaznikum, vytvareni koureove clony, ktera nasledne znemoznuje zakaznikum se orientovat v konkurenci.

No a ted si predstav, ze mas zadane takovehle shity a mas to jako vyvojar implementovat. Tyhle shity uz ze sve podstate jsou neminimalizovane shity, a kdyz se k tomu prida zpravidla nekompetentni management tak vzniknou jeste vetsi shity, ve kterych se uz jednotlivec nevyzna a nelze je uz snadno minimalizovat do nejake osekane podoby. No a presne takoveto shity se potom promitaji i do backendu, ktery je nasobne objemnejsi, nez by musel byt, a stoji hromadu zbytecne prace.