Att välja en stack är ett långsiktigt åtagande du gör med ofullständig information, så rätt tillvägagångssätt är att besluta utifrån kompromisser, inte hype. Det mest glittriga ramverket på konferensscenen är sällan det som tjänar projektet väl om två år. Min standardbias är mot tråkig, beprövad teknik om det inte finns en konkret anledning att avvika.
| Välj beprövat när | Överväg nytt när |
|---|---|
| Standardproblem, kända mönster | En verklig begränsning som ingen mogen lösning löser |
| Team måste röra sig snabbt | Du har tid och lust att lära dig |
| Långlivat, måste vara underhållbart | Vinsten är stor och mätbar |
Ett stackbeslut formar i det tysta rekrytering, utvecklingstakt och driftskostnad i många år, och att vända på det senare är brutalt dyrt. Att välja teknik för att den är spännande istället för för att den passar är ett av de vanligaste och mest skadliga misstagen för tech-ledare. Att besluta medvetet, med kompromisserna skrivna ner, är vad som skiljer ett arkitekturval från ett modevål.