表に現れない開発箇所で説明しづらいところの言語化
mrsekut.iconは型が好きなので、だいぶ偏っている気はするが、
それを説明していく必要がある
ググりたいがキーワードがわからん
DX
心理的安全性
とか？mrsekut.icon
近いけど惜しい感じはする
「プログラミング 型 説明 営業」とかでググって、時分のググり力のなさに泣いたmrsekut.icon
作っているサービスのKPIツリーのここに効いてきます、というのはわかりやすそうmrsekut.icon 根拠を示しやすい
エンジニアじゃない人にも説明しやすい
長期的なサービスだったり、複数人開発の場合は必ずどこかに効いてくるという確信がある
長期的というか、コードが使い捨てじゃない系のサービス
実験とかは使い捨てなものも多い
わかりにくいもの
例
型をちゃんと書く
テストをちゃんと書く
リファクタリング
ReactならclassをFCに変えていくとか
本家は「しなくてもええよ」とは言っているが
別にやらなくてもプロダクトは回るし、やってもユーザーが直接的に気付かないこともある
パフォーマンスの改善とかならまだわかりやすい
技術選定時の説明
開発的にはコスパは良い
静的なコードリーディングの補助になる
プログラミングはコードを読んでる時間のほうが長い
型はコアな部分をちゃんとかいておけば、あとからそれに頼ることができるので単純に開発が早くなる
バグが見つけやすくなる、というかそもそも生まれにくくなるので、バグの改修自体が減る
バグが出てからその箇所を特定して直すよりも容易
型がないとリファクタリング時に気にするところが増える
壊れないかを気にしながら修正し、その後、手動テストが必要になる
型はバグの特定にも寄与することもある
実際のデータと型の齟齬に気付くとか
手動テストに頼っているとライブラリのアップデートなどに保守的になる
変更が怖くなる
めっちゃわかりやすくするなら、型を書くことで、手動テストをそもそもせずに済むところまで持っていければいいmrsekut.icon
Elmとかわかりやすそう
テストに工数がかかりすぎ
あれをもっとマシにできればいい
モンキーテストだけで品質を担保できるようになればいい
TSがanyをかけちゃうところがそもそも渋い気はする
Haskellとか書いてて、「時間ないしいったんanyにしとこ」みたいな発想はそもそもない
TSの良いところでもあるが、甘んじてはいけない
実際に問題が起きるまで放置して、「ほら〜言わんこっちゃない」って言うとか
良くない
型の健全性を壊した書き方をしてるから、手動テストがないと怖くなる
のか？
そもそもその健全性はどこまで信用できるのか
主観だがtsよりはElmは信用できる感かがある
小さいものしか使ったことがないのであまり公平な比較ではないが
非エンジニアだけでなく、同じチームの人とも型などに対するイメージの共有が必要
どういう場合は妥協するべきか、など
たとえ
タイムカードを出入り口に置くと記録忘れを防止できる
トイレの荷物フックをドアに取り付けることで、荷物を持たないと外に出られない→忘れ物を強制的に防止できる
といういうようなものをコード上でマメに作り込むことで、意図しない挙動を事前に防げます、みたいな?miyamonz.icon
miyamonz.icon
型をつけると、自分が持っているものが何なのかわかりやすくなる
役所に手続きに行くときに、適当にかばんに荷物突っ込んで出発する人
到着して初めて、ハンコを筆箱に入れてなかったと気づく、みたいなことになる
まあこれは私なのですが…miyamonz.icon
コードに型をつけると、荷物の中身チェックのような感じになって安全になる
型をつけると、筆箱の中に必要なものが入っていることを保証できるみたいな
チーム開発なら、BBQに行くのを想定する
雑に皆で「適当に食事持ってきて！」だとつらい
勘所がわかっているとそれでも大丈夫だし
いちいち確認する時間を節約できるが
プログラミングに型を使うと、荷物が自主的に「今、キャベツ入ってます！」って教えてくれる感じ？？なんだそれ
当然ながら、型を上手につけたりするのもそれはそれで難しいというのはあるが、
「社員教育して優秀な社員に逃げられたら損では？→社員教育をしないで、勉強をしない社員に居座られるリスクのほうが高いです」の言葉に似てる
これ誰の言葉だっけ？ググれば出るかな
型で突然ガチガチにやるのは難しいが、少しずつやっていくべき
素振りして結局うまくつかえなかった、でもそれでいい
今の我々には難しかったと考えよう
導入してみてうまく使えなかったら損、という認識は適切でない。
よりよい開発をするためには手段を色々試す基礎体力を上げないと、開発力が貧弱なまま停滞してしまう
という建設性をもって取り組むべきだ、と言ってみる
事前にそれがうまくいく手法だなんて分からないことのほうが多いから甘えないで色々やらせろ、とmiyamonz.iconは思う
わかり易いもの
例
新機能の実装
バグの改修
明らかにユーザーがハッピーになる
「それは本質か？ああん？」という話は置いといて。
わかりやすすぎる
その論理で行くと、絶対にこっちがわに軍配が上がる
まぁ大事だけどな、それはわかるmrsekut.icon
ただ、長期の方を疎かにしてはいけない。後回しにされがち、どこまで後回しにするんだってなる
ところで開発者でない人の合意が得られないとテストが書けないというのはどういう状況？miyamonz.icon
ミニマルに始めると良いので可能なら突然テスト書き始めるといいと思う
フレームワーク選定とか導入が大変だったらできないね
テストできる程度にコンポーネントの結合度を切るようにリファクタリングしないと、とかがあるとすぐには導入でき無さそうよね…
よくあるのは工数とのトレードオフですねmrsekut.icon
リリース日が決まっている状態で、どこまで時間をかけて型を書いていくかみたいな話があったりします
これに時間がかかるのは、もともとやっていなかったから、新規開発中のものだけでなく、この機能に関連する既存のものに型を付けていっているので、というのもある
工数とのトレードオフの場合は、段階的に型をつけていくテクニックを磨くと良さそうmiyamonz.icon
ほんのちょっとだけ、簡単に欲しいとこだけ入れる
粒度を小さく導入する技を磨けば、こっそり?チマチマ入れておく
どこで読んだっけ
anyを許すとかだけじゃなくて、もっとやりようがある気がする
type TODO = any とか
目的の型Tを返すべき関数に、まだ内部的には型づけが整ってない状態のところで
return as Tするのではなく、as Shouldbe<T>的な型を返す
利用側はTとして扱えばいい 、かつ まだ型レベルで完全にTが来るのが保証できないことが分かる
型引数にT渡すの、どこかで読んだのか自分で思いついたのか分からん
コードがjsベースで気軽にts導入できない場合
コメントだけで型をつけられた気がする
ビルドにtsを使わず検査のみやるためにtsを入れて、既存のバンドラを残すことが可能
言語選択のレベルとかだったらたしかに説得は必要そう
微妙に関係ないけど、最近、正規表現はCSS並に壊れやすそうでこわ、ってなったmrsekut.icon