機械の気持ちを考えてコードを書こう

Transcript

1. 機械の気持ちを考えて コードを書こう らり
2. 機械の気持ち 毎度むちゃくちゃなコードを書きやがって ... 最適化する側の気持ち考えろや
3. 機械に優しくするには? • 処理が大変じゃないコードを書く • 人間側が分かる範囲で最適化する ↓ JavaScriptを深くまで知る必要がある 要件に対して最適なコードを書く
4. 例 • 九九の表を作りたい • なんかmapで書くやり方もあるらしい • for文使うとなんかごちゃごちゃするし、mapの方を採用しようかな
5. 例 • 話聞いてなくて、実は九九ではなくて、十万十万だった！ • でも大丈夫！変数Nを定義しているから、そこを変えるだけなんだよね！
6. 例 • 彼はとても大馬鹿野郎でした • 機械の気持ちをとても考えられていません • どこがいけなかったでしょうか
7. 例の解答例 • mapを使っていた • アルゴリズムを適用していなかった • 配列を使っていた • 二重forを使っていた • そもそもちゃんと話を聞いていなかった
8. いろんなソース • 結局JavaScriptの配列ループはどれが一番速いのか ◦ https://zenn.dev/itte/articles/737a3ca709aad0 • ループ速度比較 〜デカい配列のforEachが約10倍遅い〜 【JavaScript】 ◦ https://zenn.dev/rabee/articles/javascript-huge-array-for-each-is-very-slow • Firefoxのfor速度比較が遅すぎると思ったので試してみた（2019/05版） ◦ https://noxi515.hateblo.jp/entry/2019/05/10/221224
9. 考えないといけないこと • O(N^M) (M>1)はとても遅いので、気を付ける必要があるよ • JSがどのような最適化を行うかを知っていると、人間も対応出来たりするよ ◦ https://romgrk.com/posts/optimizing-javascript/ • ビルド結果も似たような考え方だから、どうなるかを考えながらコードを書こう！ (envを含めたり等) ◦ https://zenn.dev/mizchi/scraps/fee64e76afc10d
10. ポインタって知ってる?? • JSではオブジェクトに参照渡しが使われる • ということは、オブジェクトの中の値の参照にはポイ ンタのような考え方が使われる • なので、オブジェクトのアクセスの回数をいっぱいす るとすぐ激重になる
11. メモリー管理って知ってる?? • JSはGCの処理を自動的にやってくれる • そのため、あまり考えないが故にメモリを めっちゃ食いつぶしてることもしばしば
12. 例でもっと考える必要があったもの • 本当に配列で用意する必要があったのか ◦ Mapで用意してもよかったのかも ▪ https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Map ▪ https://nulab.com/ja/blog/nulab/100times-faster-performance-improvement-set-map/ • 常に最悪計算量で考える必要がある ◦ 今回であれば100,000×100,000 = 百億回回る ◦ 百億も回ればスマホは熱くなる ▪ https://quarka.org/100million-data-on-javascript/
13. 機械の気持ちが分かると分かること • The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. • ハードウェア、ソフトウェア、言語、文化、所在地、物理的/精神的能力にかかわら ず、ウェブは基本的にすべての人に向けて設計されています。ウェブがこの目的を 達成できると、さまざまな聴力、視力、認知能力をもつ人々がウェブにアクセスでき るようになります。 ↓ Webは人間に情報を伝える必要がある https://www.w3.org/mission/accessibility/
14. a11yってどうすればええんや • HTMLのDOMを見せて説明出来ないことは機械でも出来ません ◦ 画像のaltとか • DOMのツリーと反する順序や内容を教えたいって時に基本的に使う ◦ row-reverseとか ◦ tabindexとか ↓ 機械に説明してほしいことを人間が伝える必要がある アクセシビリティとは、個人の身体的・認知的能力やウェブへのアクセス方法に関わら ず、可能な限りアクセス可能なコンテンツを開発することです。 https://developer.mozilla.org/ja/docs/Web/Accessibility
15. 何も考えられない方へ • そこまで難しい事出来ないのであれば、ライブラリに頼ろう ◦ デカいデータをゴリゴリに触るなら TensorFlow.jsとか使おう ▪ https://www.tensorflow.org/ ◦ WebGL扱えないのであれば、 three.jsとかに頼ろう　 ▪ https://threejs.org/ ↓ ところで、そのライブラリ大丈夫？
16. インシデント起こした事ありますか? • トロイの木馬化された「jQuery」がnpmやGitHubで拡散 ◦ https://rocket-boys.co.jp/trojanized-jquery-spreading-on-npm-and-github/ • OSS「faker.js」と「colors.js」の開発者、自身でライブラリを意図的に改ざん　「ただ 働きはもうしない」 ◦ https://www.itmedia.co.jp/news/articles/2201/11/news160.html ↓ 使うライブラリはきちんと選んだり、確認しないとどえらいことになる
17. 例 • 状態管理したいな〜 • ライブラリ使いたいな〜 • でもRecoilのコアメンテナの人がレイオフされたらしい ◦ https://github.com/facebookexperimental/Recoil/issues/1495#issuecomment-1439803842 • なんかjotaiってやつがいいらしい ◦ https://zenn.dev/dai_shi/articles/2b222d9230b599 • 人気なやつ選びたいな〜
18. https://npmtrends.com/jotai-vs-nanostores-vs-recoil-vs-redux
19. https://trends.google.co.jp/trends/explore?geo=JP&q=zustand,redux,jotai,recoil&hl=ja
21. 例 • このライブラリの選び方はなかなか危ないところがあります • 自分が仕事で使うと思って考えてください
22. 例の解答例 • zustandとjotaiの製作者は同じだが、所属が違うので、何かあった時にzustandの 方が助かりやすいかも ◦ https://zenn.dev/jotaifriends/articles/a200a3dec620cc • 仕事で使うので、問題につまずきにくいものを選んだ方がいい ◦ 日本でよく調べられている =>記事が多い可能性が高い ◦ 検索で出てこなかったら英語の海に溺れて詰む • そもそも状態管理をゴリゴリに触るかを考えて、Context APIで十分かを考える必要 がある
23. 数字で見えるところから選ぶ • スター数 ◦ いいと思われている数が多い • issue/PRのopen/close数 ◦ どれだけ活発にコードの修正が入っているか • fork数 ◦ どれだけの人間が関わろうとしているか • create/updateの日 ◦ どのくらいの長さ/頻度で更新が行われているか
24. 数字で見えないところから選ぶ • 検索した時の記事の質がいいのが多いか ◦ 分からないことがあった時に解決しやすい • ChatGPTに投げた時に的を得た答えが多いか ◦ それだけ学習するほど質問が飛んでいる • 開発者/グループがどこか ◦ 個人開発だとその人が死んだら終わり • バージョンが上がった時に破壊的変更が少ないか ◦ 多いと上げるのがめんどくさい
25. 仕事基準で選ぶ • メンバーがライブラリをすぐに使いこなせるか ◦ 新卒がメインとかだと難しいかも？ • JSを埋め込みたくない等の制約に反してないか ◦ ビルド結果がどうなるかちゃんと確認すること • 似たようなライブラリが重なってないか ◦ 何も考えずに使うと、同じ用途のライブラリが入ってたりする • ライセンス違反を犯してないか ◦ 四条項BSDが混じってるとめんどくさかったりする
26. ライブラリの選ぶ基準 • そのライブラリ、本当に必要? ◦ 自作でなんとかならない ? ◦ すぐにswiper入れるのやめろ • 信用出来る? ◦ なんとなく調べたらやりたいことをやってるっぽいから入れてない ? ◦ どうせコードコピペで持ってきてるだけだろ • その後の管理出来る? ◦ バージョンアップ対応しないといけなくてぴよさんが泣くよ ◦ 家の片付けも出来ないやつがパッケージの管理なんて出来んやろ
27. まとめ • プログラムがどういう理屈でどうやって動いているかを知り、それに沿ってコードを 書くことによって、常にハイパフォーマンスが出るコードが書ける • 機械の気持ちになることで、ぐちゃぐちゃなコードを書くことが減るはず • 必要であればライブラリに頼ってもいいが、導入するに当たっては色々考える必要 がある ↓ まずはbuttonタグの中にdivを入れるの止めるところから始めよう