generated at
Simple or Easy


技術の螺旋を見抜くときに重要な概念
長生きしている技術は一貫してSimpleである

Easy
糖衣構文の成分が強い
jQueryとか、ユーティリティ(lodash)とか

既知の課題を抽象化する
自然と課題へ正しくメンタルモデルで向き合えるようにしてくれる

Easyさを売りにしたフレームワークやライブラリに頼る = 「意思疎通することに通訳を通している」自覚が必要
パフォーマンスが落ちることや暗黙挙動にハマることを考慮しておかねばならない

DSLや独自テンプレート構文系は短期的には流行っても、長期的に廃れることが多い
Dan AbramovReduxの黎明期のDSLエコシステムが乱立した時代にこのことへ言及していた
>As soon as you have such helper used in a codebase new people start to structure their code in similar ways because they think that's how it should be done.
>
> The point of Flux and Redux is to make it easy to suddenly start reacting to the same action in a different place. You don't know which actions you'll need to handle in different places in advance.
>
> One needs to look at the code not just from "how it looks now" perspective but also "how will it evolve" and "how can we reduce risks when requirements change". This pattern locks you into a very particular way of doing things. When you'll get more requirements you'll have to rewrite the part that used this helper anyway. This is why I consider providing such helper harmful, even if it seems to make code simpler in some cases. Requirements change!
>---
>このようなヘルパーがコードベースで使われるようになると、新しい人たちが同じような方法でコードを構成し始める。
>
> FluxとReduxのポイントは、同じアクションに違う場所で突然反応し始めることを簡単にすることだ。異なる場所でどのアクションを処理する必要があるかは、事前にわからない。
>
> コードを「今どう見えるか」だけでなく、「どう進化するか」「要件が変わったときのリスクをどう減らすか」という視点で見る必要がある。このパターンでは、非常に特殊なやり方に縛られてしまう。要件が増えたら、どのみちこのヘルパーを使った部分を書き直さなければならない。このようなヘルパーを提供することは、場合によってはコードを単純化するように見えても、有害だと考えるのはこのためだ。要件の変更!

「今どう見えるか」だけでなく、「どう進化していくか」「要件が変わったときにどうリスクを減らすか」という視点でコードを見る

>@shibu_jp: 「EasyよりSimple」と言う言葉は、通っぽい感じだけど、とことん作り込まれてソリッドになったEasyってのは別格の価値があるよな、ってのはNext.jsを見て思うところ。僕も普段はGoとかSimpleよりな選択が好みなんだけどね。Next.jsはいいやつ。