- 美しさとは何か？
- 美しさは人が感じる価値
- 驚き、新しさ、安定性、心地よさ、単純さなどを与えるもの
- 驚くものと自然なものに分けられる
- 美しさ（気づき）を感じるには、ある程度の基本的な知識が必要
- 美しさは生存のためのもの。理解できないものを見ると不快感を覚える
- 美しいコードの定義
- コードは一人で扱うものではないため、美しいほどよい
- 理想的には、読んでいて引っかかる部分が一つもないコード
- 自然なコードがよい
- 美しいコードを構成する4つの要素
- 社会的、信頼的、線形的、宣言的
- 社会的で信頼的な側面は安定性を追求する
- 線形的で宣言的な側面は審美性を追求する
- 社会的なコード
- 周囲の状況をすべて考慮したコード
- 慣習やルール、ミッションに従うこと
- 言語の社会性と似ている
- 信頼的なコード
- 信じて使えるコード
- 信頼できなければ自分で確認しなければならないコードになる
- 純粋関数、冪等性、副作用などを考慮する
- 副作用を完全になくすことはできないため、ドキュメントや例外によってその存在を知らせられる
- 線形的なコード
- コードを読むとき、上から下へ一度読むだけで済むこと
- 線形的であれば、脳科学的にワーキングメモリが処理しやすくなる
- 宣言的なコード
- コードが何をするのかを正確に伝えること
- 適切な名前を付けるのがよい
- 脳科学的に短期記憶が処理しやすくなる
- 現実的には
- 美しいコードというものは、一度でぱっとできあがるものではない
- 完璧に美しいコードはそう多くない
- そのため、漸進的改善とコードの修飾という考え方が必要になる
- 漸進的改善
- リファクタリングを行うこと
- 点検と改善を繰り返し、70〜80%の品質を継続して保つこと
- いつ点検と改善を行うべきか？
- コードオーナーシップが曖昧になったとき
- 悪臭を感じるとき
- コードの修飾
- コードを美しく見えるように整えること
- 代表的にはテスト、コードレビュー、ドキュメント化、コメントなどが使われる
- テスト
- コードをより信頼できるものにしてくれる
- 動作を保証し、テスト自体がドキュメントにもなりうる
- コードレビュー
- 検証を通じてコードをより信頼できるものにしてくれる
- コードオーナーシップを共有・伝播するため、コードの社会性も高められる
- 無条件のコードレビューはボトルネックになることもある
- ドキュメント化
- コードをより理解しやすくしてくれる
- ドキュメント化すべきタイミングは、他の開発者がそのコードの文脈や設計、ルールを知る必要があるとき
- UMLのようなツールを使うとさらによい
- コメント
- やむを得ず生じる複雑なコード領域は、文書よりコメントで説明するほうがよい
- コード品質は重要だが、美しいコードが必ずしも成功を保証するわけではない
- むしろ設計や業務プロセスをより考慮すべき場合もある
- コード品質が必ずしも製品品質を保証するわけではない
9件のコメント
ｗｗｗｗｗ
社会的なコードが重要そうですね（笑）
よく整理された良い文章だと思います。チーム内でコード品質が原因の問題が頻繁に発生しているなら、読んで集まって議論するのにも良さそうですね。
難解になり得るトピックですが、すらすら読めますね。ありがとうございます！
やはり段階的な改善が重要ですね。何事も一度で完璧にはいきませんから。
自分が書いたコードに審美的な美しさを感じる趣味は、あくまで個人の価値観にとどめるべきだ。金をもらうプロが会社のコードを芸術的な観点で扱い、ジュニアに変なマインドまで植え付けるようなシニアには、どうかならないでほしい。でなければ開発者をやめて絵でも描けばいいのに、何が芸術だよ……
「美しさ」という言葉に、少しとらわれすぎているようですね
タイトルだけ読む若者
はは、ちょっとかなりオーバーでしたね