Velikost aplikací aneb jak klesá úroveň vývoje

[lobo]

Tak nejlepsi je neco naprasit a optimalizaci se zasadne netrapit. Vzdyt to vzdycky jde zahodit a udelat znovu, napriklad podle noveho, idealne jeste zprasenejsiho pocatecniho navrhu. Po urcitem mnozstvi iteraci se do dobreho reseni musi trefit i uplny vul, protoze mnozstvi moznosti je prece jenom omezene. https://en.wikipedia.org/wiki/Delayed_ejaculation

Mně teda přijde lepší vydat aplikaci za půl roku vývoje s tím, že dělá to požadované (včetně požadavků na výkonnnost), než možná za 5 let, kdy to místo 50%CPU bude brát 10....

to samozrejme ano, ale v rozumnych medziach...
ked sa ti tabulka s 25 riadkami a 7 stpcami z databazy zobrazi na stranke za 7 sekund, nieco je hrozne zle...
potom sa pozries do kodu co niekto sprasil, urobis upravu na 3 riadky a trva to <1sec
je rozdiel na nieco povedat - je to 'dost dobre a netreba to zlepsovat zatial'
alebo povedat 'po 3 dnoch googlovania to uz takmer funguje aj ked nechapem ako a uzivatel si pocka 7 sec , lebo lepsie to nespravim ani ked sa pose^iem'

[Reklama]

[Xaomi]

Juro nebudes ty taky bastlic lepic kodu? Alebo projektak, architekt v nejakej korporacii, kde sa na performance ale totalne serie a v podstate tie projekty, ktore sa robia nikoho nezaujimaju, dolezite su loove.
V dnesnom svete vyvoja to je ako s vyrobou domacich spotrebicov. Nevyraba sa kvalita, ale kvantita.

Je uplne jedno kdo to je. Zalezi na tím, jestli ma pravdu nebo ne.

Prozradim ti jedno male tajemstvi. V byznysu, a tam spada i komercni vyvoj aplikaci, jde v prvni rade  o loove. Neni pravda, ze ty projekty nikoho nezajimaji, snazi se je delat ta, aby byly nejziskovejsi.

[Xaomi]

To vas urcite ucili na nejakej ekonomickej skole

Daj lepsiu definiciu.

Ekonomii by meli ucit na kazde skole, aby studenti byli pripraveni na realny zivit a nezili ve svete iluzi a pohadek.

[Juro]

Dodam, ze clovek, ktory sprasi aj jedoduche veci, nema dost skusenosti na to, aby si dopredu spravil vyrazne lepsi interny navrh. Taketo predcasne optimalizacie juniorov vzdy koncia 2x vacsim nestabilym a neudrziavatelnym kodom, ktory povazuje za sofistikovany len jeho autor.

[borekz]

Tvůrci hw si za to mohou sami:
1. Každý si vymyslí svoje proprietární API, asi aby aplikace nešly spouštět na hw od konkurence. Jenže to právě vývojář chce a raději použije šrot typu Cordova, než by psal nativní aplikace pro tři nebo ještě víc API. Pro Windows se i profi aplikace dělají v Qt.
2. Android Studio z bůhvíjakého důvodu přidává do aplikací standardní fonty a grafiku, které snad patří do systému a ne do aplikace. Porovnejte "hello world" v Androidu a ve Win32.

[Reklama]

[jpu]

Vacsinou sa taketo nazory ala Juro vyskytuju u korporatnych ludi, ludi robiacich na nejakych IS, pre banky, stat, eu dotovane prokekty. Skuste tieto vase nazory pretavit do leteckeho priemyslu, do zbrojarskeho priemyslu, telco priemysel. Aplikacie pre POS terminaly.
Toz to tak byva v dnesnej dobe, ked vacsinu sa robia IS, minimalne u nas a v CR, vsak dnes su IN webove veci, a kvazi manazeri sa biju do prs, ake cisla vykazuju

[Ivan Nový]

Čím to je? Optimálním rozdělením zdrojů, které určují kognitivní schopnosti kolektivu. Až zase bude železa málo, bude se optimalizovat. U AI už to tak je. Z hlediska vědomí individua to jsou procesy, které nelze ovlivnit, vychází z plošné znalosti věci, které jakémukoliv jednotlivci, či menší skupině jednotlivců chybí. Jednotlivec může jen sdílet nějaký vlastní názor na věc a ten se buď uchytí a nebo ne, podle toho co je zrovna potřeba, ale o tom ten jednotlivec nemá ani páru.

[Ivan Nový]

Optimalizovaný kód není kvalitní. Je málo abstraktní. Nevyjadřuje podstatu problému, příliš kopíruje obraz železa.

[jpu]

Tento debil zas prisiel

[Juro]

Vacsinou sa taketo nazory ala Juro vyskytuju u korporatnych ludi, ludi robiacich na nejakych IS, pre banky, stat, eu dotovane prokekty. Skuste tieto vase nazory pretavit do leteckeho priemyslu, do zbrojarskeho priemyslu, telco priemysel. Aplikacie pre POS terminaly.

S tymto oblastami je to uplne kompatibilne. Ak je sucastou zadania, ze to ma napr. bezat na nejakom embedded systeme, kde to ma konkretne poziadavky na pamat, procak, velkost, spotrebu energie, tak potom opravnene riesim navrh a implementaciu konkretnych  nefunkcnych poziadaviek.

[tnr]

Vacsinou sa taketo nazory ala Juro vyskytuju u korporatnych ludi, ludi robiacich na nejakych IS, pre banky, stat, eu dotovane prokekty. Skuste tieto vase nazory pretavit do leteckeho priemyslu, do zbrojarskeho priemyslu, telco priemysel. Aplikacie pre POS terminaly.
Toz to tak byva v dnesnej dobe, ked vacsinu sa robia IS, minimalne u nas a v CR, vsak dnes su IN webove veci, a kvazi manazeri sa biju do prs, ake cisla vykazuju

To si popsal ale v dusledku docela presne... Aby se neco optimalizovalo na velikost, tak to prvne zakaznik musi chtit (=musi to zaplatit, typicky to muze prodrazit vyvoj).

U embedded systemu nic jineho nezbyde.

[JardaP .]

Mně teda přijde lepší vydat aplikaci za půl roku vývoje s tím, že dělá to požadované (včetně požadavků na výkonnnost), než možná za 5 let, kdy to místo 50%CPU bude brát 10....

Mozna by stacilo nemit v tymu jen lepice, ale i par lidi, kteri veci rozumi do hloubky a stravi nejaky ten den poradnou analyzou. V dusledku pak nenapisete dalsi registr vozidel, ale reseni, ktere mozna neni totalne optimalni, ale prijatelne. Kolikrat mam pocit, ze se dnes koderi spokoji spis resenim totalne neoptimalnim, ktere lze naprasit za co nejkratsi dobu, protoze dneska mame rychle stroje, tak at se z nich kouri, zatimco aplikace se plazi.

[JardaP .]

Skuste tieto vase nazory pretavit do leteckeho priemyslu, do zbrojarskeho priemyslu, telco priemysel.

Haha, to by byla p​r​d​e​l! Letadlo spadne, protoze lehly Widle a nepodarilo se rebootovat pred narazem do zeme. Anebo nespadlly, ale rebootovaly se kvuli update, ktery trval dele, nez 3,5 vterin. Tank z druhe svetove valky rozstrili moderni tank proto, ze se strelecka aplikace nejdriv nemohla pripojit k databazi a potom po rebootu 5 minut cekala na vyrizeni SQL dotazu, ze ktereho pak dalsich pet minut pocitala zamerovaci parametry.

[Kiwi]

Přemýšlet u vývoje se vyplatí vždy. Švihat bezmyšlenkovitě miliony LOC a nepřemýšlet o výkonu, dokud to nezačne být problém, se taky vyplatí vždy. Protože ve chvíli, kdy program zprasený by design narazí na hranice železa, už můžete udělat jen jediné - celé to zahodit a začít od začátku. Navíc v každém programu odpovídá každému LOC určitá pravděpodobnost, že je v něm chyba - ovšem včetně knihoven, jež daný program využívá, a včetně OS, na němž běží. A včetně složitosti HW - viz průsery Intelu.

Ale proč omílat dokola to samé, když mnohem povolanější lidé to už před lety dokázali vystihnout lépe:

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

[Kiwi]

Švihat bezmyšlenkovitě miliony LOC a nepřemýšlet o výkonu, dokud to nezačne být problém...

...je cesta do pekel vždy.