ぐっちーと話してて TypeScript の話になったので、ちゃんと本を読んでみた。

あとは CodeGrid の記事と。

TypeScriptことはじめ | CodeGrid
https://app.codegrid.net/serie...

なるほどなるほどという感じで、使う場面はすぐなさそうだけど、時々見るコードの中に出てくる意味が少しだけ理解できた気がする。

フロントエンドまわりは色々ありすぎて、調べていること自体がわかっていないのか、それに関係することがわかっていないのかがよくわからなくなるときがあるのだけど。
（そもそも基本的なことを理解できていないのも事実）
一度そう言うのがあった時にこうやって改めて本などで読むと少しは理解が進むような気はする。

とはいえ、書籍の内容全てを理解できたわけではないので、またそれは次に遭遇したときに改めて。。。

こういうルールがあるというのは安心感とかコードの質に繫がるところあるなー。
複数人で開発するなら必須だろうな。

そもそも論としてコンパイル後のファイルだけ直されて、コンパイル前のソースが直っていないとか。
css と sass みたいな話だけど、そういうものだと思っておかないといけない気がする。
そのためにビルドする環境含めて共有されてて、コマンド叩けば誰でも作れるような状態になってる、、、と。

コミットすればそれが反映されるようになっているとかも、サーバー上で直接編集されて、元のコードが変更されていない、みたいなことにはならない仕組みが必要だなー。
面倒であってもそこをちゃんと作っておけば、不毛な作業やミスはなくなるだろうし、1回限りの話ではないだろうから、その構築が面倒にならないような仕組み作りが必要そう。

どこまでやるべきか、、、はチームや組織によるだろうけどー。