Kromě argumentace autoritou, vlastní zkušeností a zdravým selkým rozumem?
V kostce - nejdřív bys měl napsat unit testy, abys byl schopný rozhodnout, zda program (nebo ta část, kterou zrovna píšeš), dělá to, co dělat má. Program bys měl psát tak, aby byl přehledný, snadno pochopitelný a pracoval správně. Ono i to je dost práce a často zjistíš, že zadání nebylo zcela dokonalé a je potřeba přidat další testy a udělat další úpravy, aby to fungovalo a dělalo co má.
V této fázi má cenu optimalizovat pouze pokud narazíš na omezení pamětí, nebo program běží opravdu naprosto neúnosně dlouho z hlediska ladění (nikoli budoucího užití) a průběžně testovat, zda sis tam nezanes nějaké chyby.
Teprve když ti všechny testy prochází a zároveň vidíš, že program dělá to, co dělat má (a nedělá to co dělat nemá), tak má cenu se začít zabývat optimalizacema, aby to co dělat má dělal rychleji, s menšími nároky na paměť, refaktorizovat ho a tak.
Protože optimalizace stojí poměrně dost času, práce, znepřehledňuje ti program a odvádí od konečného cíle. Pokud s nima začneš příliš brzo, tak se ti snadno stane, že program nikdy nedokončíš, protože budeš pořád jen přepisovat další a další kusy kódu, dokud ti nedojde čas a motivace. Zároveň se do toho snadno zamotáš a ztratíš přehled o tom, co všechno to má dělat a co a jak to přesně dělá. Nemluvě o tom, že pracně optimalizovaná část se může nakonec ukázat být zbytečná a z programu ji celou vypustíš (takže všechna ta práce přijde nazmar), nebo hůř nevypustíš, když už sis s ní dal tolik práce a pak budeš všelijak kroutit ostatní části, abys ji nemusel smazat a dostaneš o mnoho horší výsledek.
Samozřejmě se taky může stát, že zoptimalizuješ kus programu, kde výpočet stráví jen nepatrný zlomek času a zkomplikuješ si tím následné odstranění skutečného úzkého hrdla (ať už proto, že nezbude čas a síly před dokončením programu, nebo že věci zašmodrcháš tak, že bude pekelně těžké s tím cokoli dělat).
Další věc je, že když napíšeš program, co se spouští občas a běží sekundu, tak je zbytečné s jeho psaním trávit desetkrát víc času, abys někde ušetřil pár milisekund.
A pokud ten program běží neúnosně dlouho, je možné, že jsi někde zvolil nevhodný algoritmus a je potřeba zvolit jiný přístup. (Takže třeba nakonec pracně optimalizovaná část vypadne.) Nebo se ukáže, že program z principu věci stráví v jednom malém kousku 99.99% času a tak je vhodné optimalizovat tento kus a nikolli všechno/cokoli okolo.
Takže je lepší to nejdřív napsat čistě, pak se podívat, zda to nebrzdí špatný přístup či algoritmus a pak teprve optimalizovat jednotlivé části, počínaje těmi, které žerou nejvíc zdrojů.
(A samozřejmě každý krok prohnat těmi unit testy, abys viděl, zda to pořád ještě funguje a nezanesl sis tam nějakou chybu jako vedleší efekt optimalizací. Eventuálně naopak pokud testy padají a výsledek je přitom správný, zda není chyba v testech.)
Taky se může ukázat, že použití pekelně účinného algoritmu na třídění velkých polí to vlastně brdí, pokud je ve výsledku použit na něco, co nikdy nebude mít víc než pár položek a zvládne to lépe algoritmus méně dokonalý, který ale má výrazně nižsí konstantní časovou složku. (Použít vyvážené binární stromy pro tisíce položek je lepší než bublesort. Pro tři položky je tomu naopak.)
Takže já bych nejdřív napsal testy, pak program a pak se podíval, co ho na reálných datech skutečně brzdí a to případně opravil.
Má ten tvůj local state tři položky? Použij čisté řešení.
Drží tvůj local state 5000 položek z Excelu překonvertovaných do JSON a ty to řešíš JS v prohlížeči u klienta? Asi máš především úplně jiný problém k řešení. (a nejspíš to povede na totální změnu nejen modelu, ale i použitých jazyků a prostředků)
(A samozřejmě - pokud ti to s kratším a stylově čistým řešením neprochází testama, tak nejdřív oprav chyby a pak teprve přemýšlej o efektivitě přiřazování jednotlivých proměnných)