issues
search
KATO-Hiro
/
Daily-hit
Wants to make & prototype list inspired by https://masuidrive.tadalist.com/lists/1941485/public
MIT License
0
stars
0
forks
source link
記事「クソコードを読ませない」を読んで
#1292
Closed
KATO-Hiro
closed
1 year ago
KATO-Hiro
commented
1 year ago
要約
筆者から注意事項
個別の内容を非難するのではなく、概念そのものに言及
どんなコードが該当するか?
スコープが無限に広い
不要にmutable
情報量のない変数・関数名
どこかを触ると、全体がすぐに壊れる
認知負荷が高い
過剰な抽象化
難しい
「動いているコードが一番えらい」という考え方も
向き合う必要ながある状況
バグの原因調査
仕様の書き起こし
式年遷宮
レビュー
向き合い方
実装を読まずに済ませられないか?
挙動を把握し、正しく動くなら、その箇所を読む必要はない
コードを読まずに済ませるための技術
ドキュメントを書く
サービス全体からみたレポジトリの役割
設計方針
再現性のある起動方法
API仕様書を書く
In / Outを明記
swagger
正しいAPI仕様書を書く
実装と仕様が一致するような機械的な仕組みを導入
スキーマファースト、スキーマファイルからバリデータ作成、バリデーション
コメントにwhyを書く
コードを読む人の「なぜ?」に先回りしてコメントを
情報をURLから辿れるように
議事録やメモを残す
GitHub Issue、Slack、Discordなど
型を書く
関数のIn / Outを明示
実装に合った実例を
型を分ける
取りうる状態はユニオンで表記
テストを書く
実際にどう動くかという仕様でもある
取りうる値でのテストが充実していると、ソースコードが何をしているか把握できる
E2Eテストを書く
ユーザからの使われ方を機械的に説明するために有効
テストだけ別のworkspaceで定義して、コンテナ同士テストする方法もある
ログを出す
検索・可視化しやすいように、構造化ロギング
tracing
opentelemetry系のツール
Rustだとマクロを書くだけ
アラートを出す
事前にわかるなら、事前に
エラーに名前をつける
JSならカスタムエラーを定義
エラーにトレースを含める
Node v18から利用できる
サービス間通信の呼び出し元を明記
呼び出し元がログから分かるように
認証を必須に
後から触る人が改修しやすいか?を常に意識
テストはあるか?
暗黙の前提に依っていないか?
モジュールの責務ははっきりしているか?とりかえ可能か?
何があると嬉しいか?
明瞭なコードを書く技量がないなら、いかに読ませないかがコツ
感想
読みやすい・分かりやすいコードを書くように、という技術書は多い
どうしたらコード読ませずに済むか?、という視点が新鮮に感じた
Keep
+
Problem
+
Try
+
出典
https://blog.ojisan.io/kuso-code-wo-yomasenai/
要約
感想
Keep
+
Problem
+
Try
+
出典
https://blog.ojisan.io/kuso-code-wo-yomasenai/