これは2019年11月29日に開催したTypeScriptイベントYYTypeScript#11のイベントレポートです。
YYTypeScriptは一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆるく・ワイワイ話しながらTypeScripter同士の交流を深める「双方向的な座談会」の形式になります。集まった人たちで「今日話たいこと」「聞きたいこと」をいくつか挙げていき、それをテーマに雑談していきます。
今回の配信動画
YYTypeScript #11 の生配信の録画をアップしました!https://t.co/wbNbpho9NX
— suin (@suin) November 29, 2019
過去回の配信動画 → YouTubeプレイリスト「YYTypeScript」
前回 → YYTypeScript#10「TSを自分のスキルにしようと思ったキッカケは?」「publicは省略する派ですか?」「Auth0ってどうなの?」「GraphQLを使ってみての感想」「Javaを忘れてTSを書くべきか?」「テストって先にやります? あとにやります?」 - Qiita
雑談
YouTubeの動画でTS入門者におすすめのやつを紹介する
- TS触ったことなくて、触ってみたいけど、いまいちちょっと難しそうだなと感じる人にオススメの動画。
TypeScript入門 #01:トランスパイルとTypeScript - YouTube
- if文とかfor文の説明もしてくれているくらい初心者向け。
- 明日から使ってみたいと思わせるような内容。
- 見てみてどんなことが学べた?
- TSで書いたらこうなるけど、JSだとこなる
- TSの良さ
- 型が使えて、堅牢にプログラミングできる
- いっこ10分くらいでさくっとみれる
- 日本語のやつ少ないとおもってたけど、あるんだね
- ドットインストールとかにもあった
- 動画じゃないけどTS Deepdiveよんでる
- でも初心者向けじゃないから難しい
- 動画を見てわかってからこれよんだほうがいいかも
- まずざっくり理解するのが大事
- TSの入門者向けの動画が気になる
- 動画で勉強できるのっていいよね
- 動画で勉強したことないけど、どんなところがいいの?
- なれてきたら本のほうがいいとおもう
- 動画のほうがヒトから説明されているのでわかりやすい
- 作る過程がみれるから理解しやすい
- ひらがなで学ぶJSを読んでいるけど、あんなかんじなのが動画になってるかんじ
- 英語はいっぱいある
- JSとかは膨大にある
- O'reilly Safariに結構ある
- 結構充実している
他の言語に入るときにどうやって勉強するかききたい
- 前の言語で作ってたのと同じようなものを作ってみる
- 同じものを他の言語でつくると、違いがわかる
- PHPで簡単につくれそうなやつをTSでつくってみる。みたいな?
- そうそう
- 目の前のタスクを付け焼き刃でやっていてあんまり伸びなかったことを反省していて、
- 最初は基礎をがっと入れた後に、興味があるところに行くのが大事だと思う。
- 本だと体系的に学べる。
-
TodoMVC
- いろんな言語で同じToDoアプリが作られていて面白い。
- バニラのJSもあるし。
-
Scripting Languages I: Node.js, Python, PHP, Ruby - Hyperpolyglot
- こういう言語比較サイトを見ながらやります
- ドキュメントをななめ読みして、今使っている言語との違いを把握してから
- アプリを作りながら続きを学んでいく。
- 掘り下げたいときはSDKとかドキュメントを見に行く。
- 新しく学んでいる言語でいままでなかった機能を試して、学習モチベーションを上げてく
- 逆に、新しい言語で学んだことを元の知っていた言語で実現してみるなどもすると、使えるスキルの幅が広がる
- ウェブを見ても分かるっちゃ分かるけど、書籍が出ていればそれ買って、概要を全体像をざっくり把握してからやってる。
- 洋書も買う。
- 点ではなく、面で把握する
- 電子書籍ってばーっとめくるとか、並べて読むとかが難しいので、あえて紙の書籍を買ってる。
- 私も書籍派だなぁ。とりあえず入門書を1冊やって、後はググるのがメイン。
- この機能を作りたいっていうのがあるから新しい言語を使い始める
- 作りたいもの主導
- あんまり新しい言語を勉強したことはないが、Reactを1週間で学んだときのこと
- いきなり本を読んでも分からないので、TodoMVCをgit cloneしてきてソースコードを呼んだ。
- 模写も大事
- 紙に書き写すペーパーコーディングが有効
- 逆引きTips本を買うのもあり
- プログラミング教室で学んだ。
・・・
逆にプログラミング教室ってどうなの?
- 逆にプログラミング教室ってどうなの?が聞きいてみたい。ググるとだいたいアフィリでいいことしか書いてないし
- あんまりいい噂は聞かないけど
- 若かったときに「自分より詳しい人がいっぱいいるんだ!」と思って行ったら、そうでもなくてがっかりした。
- 入ってみないと分からない、博打感あるよね。
- 初心者だと疑いようもないし。
- 選び方を知りたいです!
- 全部無料カウンセリングしてもらって、
- ウェブで評判をリサーチしました。
- アフィリエイトが少ないところを選びました。
- スクール行ってようが、本人の努力次第ってところは正直ありました。
- それはあると思う
- 受け身で頼り切ってるひとは、どんどん辞めていくイメージでした。
- 得た知識だけで勝負するだけじゃだめで、その知識を元に、今持ってない知識を取りにいけることがエンジニアとして大事だと思う。
- うちのスクールは特殊でほとんど自習
- 宿題を出されて、それをやってくるかんじ。
- 1日12時間勉強しろと言われた。
- スパルタすぎる感はあった。
- 実務に入ったら、スクールの5倍くらい大変だった
- いきなり5,000行のコード直したりとか……
- それは場所によりましねw
- いきなり5,000行のコード直したりとか……
- 実務に入ったら、スクールの5倍くらい大変だった
JSに詳しくないチームで、新規プロジェクトをTSで始めるに当たってのアドバイスを下さい
自分含め、ほぼみんなJSのスキルが無い状況で、TypeScriptでやるならどんなはじめかたをしたらいいか?
- どんなチーム?
- BackboneJSとCoffeeScriptで作られた既存のフロントエンドを改修することはできるが、バックエンドがメインなので、そこまで詳しくないというレベル
- ES6以降もそこまで自信ない。
- いつまでも古いスタックでいくわけにいかないので、TSなど新しいスタックにシフトしていきたい。
- 社内案件なので、技術選定は小回りがきくプロジェクト。
- JSのアプリケーションとしての難易度は引く。
- 2人くらいのチーム。
・・・
- 学習コスト?
- 今からBackbone
- TSはいれずにJSでいくって方針もありそうだと思いました。いきなり違う言語するより混乱しなそうかなと。
- 社内案件なので、チャレンジするのもありかも。
- JS/TSに限らず新技術入れるとほぼほぼギスギスする気がするので、まずメンタルを鍛える
- 2人チームなのでギスギスはしなそうですね。
- うちのチームはギスギスしたことあります。
- TS導入派と反対派で対立したことが。
- なんでTSを導入しようということになったんですか?
- コード量が膨大で、バグが少なくなく、そのバグも減らしたくて。
- 反対派の意見は?
- 学習コストと外注先との関係もあったので。
- どのくらいのタイミングで?
- あと半年でプロジェクトが終わるというタイミングだった。
- 結局よくよく話してTSは導入できた。
- チームメンバーは今のスキルで満足していて、新しい技術を取り入れたいと思っていない可能性がある
- 経営的にも新しい技術スタックに拘らず、古いスタックでもノウハウを貯めて高速化した方が利益率も維持でき、人材採用、外注先の幅も広がる(それだけ、買い叩くことが可能になる)
- 同感です。リファクタリングだったり再実装は工数削減の経営戦略としてありですが、漠然としたモダンな技術スタックを採用したいってメリットがなかったりします。
- TS導入で一番ハマっているところは型
- 型はがんばらないという方針にしたら、うまくいくようになった。
- 型を頑張らないってどういうこと?
- anyで済ませちゃうとか
- もっと工夫すれば型で表現できるけどしないとか
- 普通のJS+型とか
- 最初から100%、TSの機能を使おうとすると学習コストがすごく高くなる。
- TSで行けそうかどうかやってみる
- TSで1週間位やってみて、やっぱりTS無理!ってなったらトラインスパイル後のJSを使ってJSに戻ることが出来る
知っている人がいたら、React Hooksを使っていて、Reduxを導入すべきかどうか
- どういう使い分けをするべきかなど
- Hooks使っているならRedux要らないという意見もネットでちょいちょい見るが。
・・・
- 分からないので、やってみます。
- HooksはReduxと重複する部分としては、Contextに状態を持たせられるようになった。
- 昔はpropsでバケツリレーしてたので、ReduxでContext的なことをしてた。
- 依存の少ない UI の state は hooks でやってメインの State 管理は redux でやってます
- hooks での redux-persist(永続化系) と redux-devtools (デバッグ)の代替方法がわからなくて移行できてなかったりしてます
- コンポーネントステートの弱点はステートの階層がビューの構造に依存すること
- 個人的にはStoreはMobXがめっちゃ使いやすかったので、ずっとこれ使ってます
- どちらかではなく組み合わせるのも手だと思います。
- collapse の開閉状態みたいなコンポーネントの外から参照しないような state なら内部でもって、ドメイン知識に関わるステートなら Redux みたいな
バックエンドにもっと関わるにはどうしたらいい?
仕事でフロントエンドだけに絞られているが、バックエンドにもっと関わりたい。
バックエンドにも興味があるが、どっちもやったら中途半端にならないかどうか心配でもある。
ちなみに、10年前に作ったプロダクトを5人くらいで保守している。
・・・
- あと2ヶ月でプロジェクト終わるってことですが、今のプロジェクトで関わりたいのか、次のプロジェクトで関わりたいのか?
- 会社の方針が見えないのでなんとも言えないですが、
- もっとアピールしていったほうがいいかも。
- BFF (backend-for-frontend)
- microserviceを束ねてフロントエンド
- 自分で学んでいくこともありだと思う
- 転職するのもあり
- ステップアップで考える
- 遠い先でなく一歩先を見る
- 着眼点
- 変化の早いものでなく、変化しにくい領域を基礎をして学んでおく
- ex.) BFFは2〜3年後には別の新しいアーキテクチャに置き換わっている可能性がある
- 設計を学ぶ
- ソフトウェアの凝集度を意識するといろいろと見えてくるかも
参加してよかったこと(参加者の感想)
- TypeScriptに関わらず、新しい技術を導入する時の考えた方が参考になりました。
- Typescriptを皮切りに実際他に色々な話が出来たため、有意義だった
YYTypeScriptは毎週やってます
YYTypeScriptについてワイワイ話したい方は、YYTypeScriptのイベント情報をチェックしてみて下さい。
以上、YYTypeScriptのレポートでした。次回もワイワイやっていきたいと思います! では、また来週!