This article translated it with permission of Mr. Abdul Nimeri who is the author of "How" ages faster than "Why".
I used to write a lot of Angular back in 2015. But recently, the JS community has largely moved on from Angular 1 to other libraries, and in turn, so have my projects. I always knew in the back of my mind that technology — and the knowledge that goes along with it — becomes outdated, but this was the first time I experienced it for myself. I wondered: what parts of my Angular knowledge are now obsolete? What parts are long-lasting? And most importantly, how can I make sure that I always get better as an engineer in the face of all those fleeting frameworks and libraries?
私は2015年にAngularを使って沢山コードを書いていましたが、最近のJSコミュニティではAngular 1から他のライブラリに大きく移行しており、今度は私のプロジェクトでも同様な事がおきました。常に技術とそれに伴う知識は時代遅れになると心の奥ではわかっていましたが、この事は私自身初めての経験でした。Angularの知識のどの部分が時代遅れになるのか？どの部分が長く続くのでしょうか?。そして最も重要なことは、これらの一時的なフレームワークやライブラリに直面する度にエンジニアとしてより良くなる為にはどうすればよいでしょうか?。
Let’s start by identifying the fleeting knowledge — the kind that won’t help us 10 years from now. That would be a framework’s API and syntax, like Angular’s syntax for one-way vs two-way binding, or the mechanics for how to make a directive. Knowing those nitty gritty details of Angular and its API is necessary to be productive in an Angular codebase, but it’s useless in any other codebase. I refer to this type of knowledge as the “how” — as in, “How do I do X in Angular?”.
まずは今から10年後に私達を助けないような一時的な知識を特定してみましょう。フレームワークに関するAPIと構文ですが、片方向対双方向バインディングのためのAngularの構文、またはディレクティブを作成するための仕組み。これらのAngularとそのAPIに関する詳細な知識を知る事はAngular上のコードベースで生産的である為に必要ですが、他のコードベースでは役に立たないでしょう。私はこのタイプの知識を"手段"と呼んでおり、"AngleでXをどうやって行うのですか？"の様に使います。
It’s also the kind of knowledge that’s easy to acquire. Picking up the keywords of a framework is easy — just google it, copy paste from StackOverflow, some basic pattern matching here and there, and we’re done. So not only is this type of knowledge fleeting, it’s also less valuable since it’s so commonplace. Companies don’t hire senior engineers for this type of knowledge.
これもまた取得するのが簡単な種類の知識です。フレームワークからキーワードを取り出すのは簡単ですからーググッて、StackOverflowでコピー＆ペーストして、いくつかの基本的なパターンマッチするものを見つけて終わりです。従ってこの種の知識は瞬時に消えていくばかりではなく、一般的ではない為、あまり価値が無いのです。企業はこの種の知識のためにシニアエンジニアを雇うことはありません。
The more enduring kind of knowledge is the “why”. Why does Angular exist? Why does it have the features that it has? What problems is it trying to solve?
より永続的な種類の知識は「なぜ」です。なぜAngularは存在するのですか？ なぜその機能を持っているのですか？ 解決しようとしている問題は何でしょうか?。
Frameworks like Angular may have a short lifespan, but the problems they tackle live on for much longer. Angular was built to tackle the problem of writing, maintaining, and iterating on complex web apps. Any knowledge that helps us approach this problem will be valuable for a long time. In fact, it’s not a huge stretch to swap “web apps” for “software”, and suddenly we’ve got a problem that’s going to last an entire career! That’s the kind of knowledge we want — the enduring kind.
Angularのようなフレームワークは短い寿命かもしれませんが、ずっと長く問題に取り組んできました。 Angularは複雑なWebアプリケーションの作成、保守、反復の問題に取り組むために作られました。この問題に取り組んだ、あらゆる知識はこの先も長い間役に立つでしょう。 実際「ソフトウェア」を「Webアプリケーション」に置き換えるのはそんなに大変な作業ではないですが、突然一生抱えるであろう問題に直面します！ それこそ、私たちが望む永続的な知識なのです。
Asking “why” and getting to those enduring nuggets of knowledge isn’t always easy unfortunately. The context and motivation behind a particular feature is the kind of knowledge that’s harder to come by, but it’s well worth the effort. Let’s go through an example.
「なぜ」と尋ね、多くの知識の中から永続的な物を特定するのは残念ながら簡単ではありません。 特定の機能の背後にある文脈や動機付けに関する知識は、見つけるのが難しい種類の知識ですが努力する価値はあります。 例を見てみましょう。
Say I google “Why should I use Angular”. I might run into reasons like this:
googleに "なぜAngularを使うべきなのか"と聞いてみます。こんな理由が返ってくるかもしれません。
- MVC and separation of concern
- Two-way data binding
- Dependency Injection
- MVCと関心の分離
- 双方向データバインディング
- 依存性の注入
If I don’t know what MVC and dependency injection are and why they’re good practices, then I’m simply left with more questions. Why would I want dependency injection? And why is separation of concerns useful?
もし私がMVCや依存性の注入が何であるか、なぜそれらがベストプラクティスであるのか分かっていなければ多くの疑問が残ります。なぜ依存性の注入をしたいのですか？ そして、なぜ関心の分離は有用なのでしょうか？。
So let’s keep digging (disclaimer — this is super simplified):
さぁ掘り続けよう。（注意 - これは超簡単です。）
- Angular uses dependency injection…
- …and dependency injection is useful for writing unit tests
- …and unit tests are useful for maintaining and iterating on software
- Angularは依存性の注入を使用しています...
- ...依存性の注入はユニットテストを書くのに便利です。
- ...ユニットテストはソフトウェアのメンテナンスと反復処理に便利です。
Got it! Now I learned about dependency injection, which a generic design pattern that’ll be useful to me past Angular’s lifetime. This knowledge also helps me better understand how and when to use that Angular feature, and when I can ignore it. Practical knowledge for our Angular work today, and enduring design pattern knowledge for the future. Win-win!
やりました！今私は今後のAnglarを使う際にも役立つ一般的デザインパターンである依存性の注入について学びました。この知識はAngularの機能をいつ、どのようにして使うべきかを理解するのにも使えるでしょう。Angularの実践的な知識で今日の仕事に使えて、永続的なデザインパターンの知識は将来に役に立つのです。まさにWin-winです！
In general, asking why is a recursive process, just like installing a software dependency. We have to follow all the recursive dependencies until they all resolve, otherwise we end up with broken software — or in this case, incomplete understanding. We have to continually dig deeper until we hit a layer whose value we understand. Kids know this intuitively!
一般的にソフトウェアの依存関係をインストールするのと同じように、「なぜ」を求める事は再帰的プロセスです。すべて解決するまでこの再帰的な依存関係に従わなければなりません、そうでなければ壊れたソフトウェアで終わり、不完全な理解のままで終わってしまいます。私達は価値のあるレイヤーに当たるまで深く掘り下げて調べなければなりません。子供達はこれを直感的に知っています！
Here’s how I (simplistically) imagine the “Why Angular” knowledge dependency tree:
ここに私が（単純化した） "Why Angular"の知識依存ツリーを紹介します。
Angular
├─MVC
| ├─関心の分離
| | ├─ソフトウェアの保守性
├─依存性の注入
| ├─単位テスト
| | ├─ソフトウェアの保守性
| | ├─開発の反復速度
├─双方向データバインディング
| ├─状態を調整する
| | ├──バグを減らす
`` ``
At the top level we have the most specialized and most fleeting solutions: frameworks like Angular. One level deeper, we get into specific patterns that are common across different frameworks: DI, MVC, etc. As we dive deeper, we get into more fundamental software engineering practices, and so on until we arrive at core problems in software engineering.
トップレベルでは、Angularのようなフレームワークが最も特化し、一時的な機能を紹介してます。 1レベル深いところではDIやMVCなど、さまざまなフレームワークで共通する具体的なパターンに分かれていきます。深く掘り下げるにつれてより基本的なソフトウェアエンジニアリングの実践に入り、そしてソフトウェアエンジニアリングの中核となる問題に達するまで、これを繰り返します。
I love this visualization because it exposes the deeper level concepts for what they are: building blocks. Once we dive deep into a framework that uses MVC and learn what MVC is all about, then we’ll carry that understanding over to any other MVC framework we use in the future. It’s just like when a package manager installs a new package and finds one of the dependencies already installed — it can just reuse it.
私はこの依存ツリーが大好きです。なぜならこれらの積み木で深いレベルの概念を説明できるからです。 一度MVCフレームワークを使用してMVCが何であるか深く掘り下げれば、将来この知識を他のMVCフレームワークにも利用できます。 これは、パッケージマネージャが新しいパッケージをインストールした際に、既にインストールされている依存関係の1つを見つけた事と同じです。つまりは再利用できるのです。
Having more building blocks doesn’t just makes us faster learners, it’s also essential for innovating new solutions. Almost every new piece of software is inspired by many other ideas before it. One example is redux, which is inspired by Flux, CQRS, Event Sourcing, and probably more (perhaps Clojure atoms). We stand on the shoulders of giants not just by using the software they built, but by understanding the ideas they introduced.
多くの積み木を持つことは学習スピードを向上させるだけでなく、新しい解決策の革新にも不可欠です。 ほぼすべての新しいソフトウェアの一部は、他の多くのアイデアから触発されているのです。 1つの例を出すとreduxはFlux、CQRS、Event Sourcing、他にもたくさん(恐らくClojureが元)のアイディアからインスパイアされています。巨人の肩の上で先人達が構築したソフトウェアを使用するだけでなく、 先人達が導入したアイデアを理解することで私達は立っているのです。
I often find that the path of least resistance when working on a project is to just look up exactly what I need, paste it in, and ship it. But now I realize that plowing through projects semi-blindly isn’t the best idea for my personal growth.
私はしばしばプロジェクトに取り組んでいる際に最も抵抗が少ないやり方は、必要な事が正確にわかりそれを貼り付けして提出する事だと気付いてます。 しかし今では、半盲目的にプロジェクトをこなすことは私個人の成長のための最良のアイデアではないとはっきり理解しています。
Looking back, I could’ve gotten more out of my Angular experience by:
振り返ってみると、Angularの経験からさらに多くのものを得ることができました。
- understanding Angular’s decisions within the context of the problems it was solving
- asking why and not being afraid of following the rabbit holes
- understanding the motivations and tradeoffs behind the Angular features
- コンテキスト内の問題におけるAngularの決定を理解する。
- なぜを尋ねる事と解決策に従うことに恐れていないか。
- Angularの機能の背後にある動機とトレードオフを理解する。
We should learn frameworks not just to build stuff, but to learn new ideas because once a framework is out of use, the ideas are all that’s left. But when a framework doesn’t teach us anything new, I am reminded of Alan Perlis’s quote:
いったんフレームワークを使い尽くすと後はアイディアだけが残るので、アプリケーションを作るだけでなく新しいアイディアを得るためにもフレームワークを学ぶべきです。 しかしフレームワークが何も新しいことを教えてくれないとき、私はAlan Perlisの引用を思い出しています。
“A language [or framework] that doesn’t affect the way you think about programming, is not worth knowing.”
"プログラミングの考え方に影響を与えない言語（またはフレームワーク）は知る価値がありません。"
Even if frameworks come and go, we can still learn the ideas behind them and become better engineers, as long as we dive deep enough.
フレームワークが出てきたり無くなったとしても、フレームワークの背景にあるアイデアを学び十分に深く理解している限り、私達は良いエンジニアになれるのです。
この記事はredditでも話題になっており、トップコメントが良かったのでそちらを引用して終わりにします。
I think everyone is missing the point here. Whether it's in 6 months or 60 years, technologies come and go. Learning the tiny gotchas of a language or framework is a matter of time. What separates the expert from the amateur is the understanding of why things were done a certain way, since that knowledge translates across languages and frameworks. I always need to easily automate my testing. I always need to make my code reusable. I always need to make my code less redundant. These are just some of the objectives frameworks help you achieve, and understanding how they help you achieve them is far more useful in the long term and will make you a better programmer in general. How they work exactly is something that can be learned in a couple of weeks.
誰もが要点を見逃していると思う。6ヶ月だろうが60年だろうが、常に技術は出てきたり消えたりするものだ。 言語やフレームワークの小さな癖を学ぶことは時間の問題だよ。 エキスパートがアマチュアと違う所は、その知識が言語やフレームワークを超えて流用できるから、なぜその方法で行われたかを理解できるんだ。常に簡単にテストを自動化する必要がある。 常にコードを再利用可能にする必要がある。常にコードを冗長性の少ないものにする必要がある。 これらはフレームワークが助ける目的のほんの一部であって、それらを達成するためにどのように役立つかを理解することは、はるかに長期的に有用であり良いプログラマになれる。だから良いプログラマは数週間程度で正確な動きを学べるんだ。
おわり