Optymalizacja kodu - JS

Question

Tak przedstawiony kod, chcąc aby wykonywał się krok po kroku co dany czas x razy wygląda tak:

function numberone()
{
//akcja niezależne od siebie
setTimeout(numbertwo,3000);
}

function numbertwo(
){
//akcja niezależne od siebie
setTimeout(numberthree,5000);
}

function numberthree()
{
//akcja niezależne od siebie
setTimeout(numberfour,1000);
}

function numberfour()
{
//akcja niezależne od siebie
setTimeout(numberfive,7000);
}

....

 

 

"Zoptymalizowałem" do

 

dla parametru y wartość 1

function execute(y){

if( y==1){ //akcja niezalezna od siebie;}
if (y==2){ //akcja niezalezna od siebie;}
if (y==3){ //akcja niezalezna od siebie;}
if (y==4){ //akcja niezalezna od siebie;}
...


setTimeout(execute,3000,y+1)
}

 

Kod niby krótszy, ale powstaje problem ponieważ czas 3000ms jest pomiędzy każdym wykonaniem, a powinien być wskazany i się różnić.

 

Jak zrobić profesjonalnie aby dane akcje, wykonywały się co jakiś czas?

Answer 1

Polecam zrobić sobie tablicę, w której będą obiekty zawierające funkcję oraz czas, po którym ma zostać ona wywołana i po prostu przelatywać przez tę tablicę. PoC: https://jsfiddle.net/Comandeer/s51ptg6j/

Comments

To nie jest dobre rozwiązanie, z kilku powodów:

• zamykasz funkcje w strukturze, utrudniając ich używanie w innych kontekstach,
• co jeśli funkcje mają argumenty?
• co jeśli jedna funkcja przekazuje wartość do drugiej?
• niepotrzebna "rekurencja" utrudniająca analizowanie kodu

---

zamykasz funkcje w strukturze, utrudniając ich używanie w innych kontekstach

Co to za problem dać tutaj tylko referencje do funkcji?

• co jeśli funkcje mają argumenty?

Można je owinąć w anonimową, można użyć bind, można wtedy pomyśleć nad innym sposobem.

• co jeśli jedna funkcja przekazuje wartość do drugiej?

Wtedy stosuje się inny sposób. Niemniej akcje są niezależne od siebie, więc ten problem w tym wypadku nie istnieje.

• niepotrzebna "rekurencja" utrudniająca analizowanie kodu

Prawdę mówiąc nie wiem, co niby tu aż tak mocno utrudnia tę analizę. 

---

No ok, wszystko jest do rozwiązania - to wiem, natomiast imho lepiej od razu rozwiązać to generycznie, a nie dla szczególnego przypadku.

---

imho lepiej od razu rozwiązać to generycznie, a nie dla szczególnego przypadku

YAGNI. 

---

Nie na tym YAGNI polega.

---

A na czym?

---

YAGNI polega na nie implementowaniu domniemywanych ficzerów (bo wymagania są zmienne) a nie na nie pisaniu generycznego, czystego kodu.

Poczytaj: https://martinfowler.com/bliki/Yagni.html

W szczególności:
 

Now we understand why yagni is important we can dig into a common confusion about yagni. Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify. Yagni is only a viable strategy if the code is easy to change, so expending effort on refactoring isn't a violation of yagni because refactoring makes the code more malleable. Similar reasoning applies for practices like SelfTestingCodeand ContinuousDelivery. These are enabling practices for evolutionary design, without them yagni turns from a beneficial practice into a curse. But if you do have a malleable code base, then yagni reinforces that flexibility. Yagni has the curious property that it is both enabled by and enables evolutionary design.

Yagni is not a justification for neglecting the health of your code base. Yagni requires (and enables) malleable code.

I also argue that yagni only applies when you introduce extra complexity now that you won't take advantage of until later. If you do something for a future need that doesn't actually increase the complexity of the software, then there's no reason to invoke yagni.

---

YAGNI polega na nie implementowaniu domniemywanych ficzerów (bo wymagania są zmienne) a nie na nie pisaniu generycznego, czystego kodu. 

Problem polega na tym, że nie zgadzamy się co do generycznego, czystego kodu. Moim zdaniem funkcja biorąca tablicę funkcji i wykonujące poszczególne funkcje z niej wraz z odstępami pomiędzy nimi jest generyczna. Fakt, przepisanie tego na funkcje asynchroniczne sprawi, że stanie się też o wiele czystsze od obecnego rozwiązania. Z kolei uważam, że Twój kod, owszem, jest czysty, ale nie generyczny. runAll jest zbyt proste, by zapewnić generyczność.

Co więcej, Fowler się ze mną zgadza.

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.

Tego typu ficzerem jest obsługa zależności pomiędzy poszczególnymi funkcjami czy wartościami przez nie zwracanymi czy też obsługa funkcji mających parametry.

I also argue that yagni only applies when you introduce extra complexity now that you won't take advantage of until later.

I znów: obsługa tych zależności lub parametrów jest dodatkową złożonością, której na chwilę obecną nie wykorzystuję i być może nigdy nie wykorzystam. A w zależności od stopnia tych zależności, złożoność może bardzo szybko podskoczyć.

Yagni is only a viable strategy if the code is easy to change, so expending effort on refactoring isn't a violation of yagni because refactoring makes the code more malleable.

Łatwiej jest zmienić konfigurowalną funkcję execute, bez konieczności dotykania faktycznej logiki aplikacji, niż funkcję runAll, gdzie każda zmiana jest zmianą logiki.

---

I dla kompletności: wersja mojego rozwiązania na async/await.

Answer 2

Do sprawdzania kolejnych wartości jednej zmiennej używa się switcha, a do cyklicznego wywołania funkcji setInterval.

Answer 3

Najelegantsze rozwiązanie jakie przychodzi mi do głowy to:
 

function a (x) {
  console.log(x)
}

function b (y) {
  console.log(y)
}

function c (z) {
  console.log(z)
}

function delay (ms) {
  return new Promise(resolve => setTimeout(resolve, ms))
}

async function runAll () {
  a('foo')
  await delay(3000)
  b('bar')
  await delay(1000)
  c('baz')
}

runAll()

 

CodePen: https://codepen.io/caderek/pen/OQRMjX?editors=0012

Funkcje nie są w żaden sposób powiązane z delayami (ani z innymi funkcjami), flow jest prosty i liniowy.

Comments

Z tym, że obecny flow zakłada, że funkcje a, b i c są synchroniczne. W chwili, gdy nie są, całość zaczyna się komplikować (i dostawienie await to akurat najmniejszy problem w tym).

Dodatkowo rozwiązanie jest sztywne i wymaga po prostu wypisania wszystkich funkcji po kolei wraz z delay. W przypadku, gdy dostarczamy listę funkcji, można ją w locie modyfikować. Pozwala to też na wielokrotne ich wykorzystanie w wielu różnych miejscach.