さようなら、クリーンコード（2020）

コード整理への別れのあいさつ

• 同僚が一週間ずっと書いていたコードを、夜遅くにチェックインした。
• グラフィックエディタのキャンバス上で図形のサイズを調整する機能を実装した。
• コードは動作したが、繰り返しが多かった。

翌朝...

• 上司から個別に話したいと言われ、コード変更を差し戻すよう求められた。
• 最初は衝撃を受けたが、最終的には上司の判断が正しかったと気づいた。

段階

• 「クリーンコード」に執着し、重複排除に没頭するのは、多くの開発者が経験する段階である。
• コードに自信がないとき、自分の自尊心や職業的な誇りを、測定可能なものに結びつけたくなる誘惑がある。
• 抽象化を学ぶと、繰り返されるコードを見るたびに抽象化を使いたくなる。

GN⁺の見解

• 重要なのは、コードの「きれいさ」を追求すること自体が目的なのではなく、複雑なシステムを扱う過程での一種の防御メカニズムだという点である。
• 「クリーンコード」は、開発者が未知の領域で道しるべを得る助けになるが、それだけに執着せず、手放すことも学ぶ必要がある。
• この記事は、開発者にとってコードの作成と保守の過程における協業と実用性の重要性を思い出させてくれる、興味深い視点を提供している。

[GN⁺]

Hacker Newsの意見

• 「クリーンコード」はブランド改善が必要

  • クリーンコードの目的は、コードをよりシンプルにし、保守しやすくすること
  • ソフトウェアの価値は、時間の経過とともに変化できる能力にある
  • リファクタリングによって保守がより難しくなったなら、それはクリーンコードではない
  • 元の開発者とリファクタリングについて議論しなかったことは、クリーンコードとは別の問題

• コードの重複が時には良いこともあるが、クリーンコードが悪い証拠にはならない

  • 10行の繰り返される数学計算を関数に置き換えたなら、よりクリーンになる可能性がある
  • PRをレビューし、基準に合わなければ却下すべき
  • クリーンコードの重要性を無視する態度は、結局誰も触りたがらないコードベースにつながる
  • より良いコミュニケーションと節度が必要だという教訓

• 同僚がコピー＆ペーストで大量のコードを書いていた

  • リファクタリングはレビューに出すべき
  • 上司が直接介入して差し戻せと指示するのは悪い兆候
  • コピー＆ペーストが関数を書くより良いという教訓ではない

• クリーンコード版がダーティーなコードを置き換えた可能性が高い

  • チームでの働き方についての教訓が必要

• コード変更時には同僚レビューが必要

  • 良いプロセスが不足していることを認識すべき
  • コードのリファクタリングは必要なときだけ行うべき

• 金融分野では、似ているが異なる製品を扱うことが多い

  • 過度な抽象化を避けつつ、クリーンコードを維持することが重要

• Haskellのような言語は、言語レベルで抽象化を最大化する

  • プロジェクトごとの抽象化を最小限にしつつ、学習コストは高い

• 繰り返される数学計算を別の関数に移すことはクリーンコードに当たる

  • インターフェース形成に見えるリサイズ関数群をリファクタリングするのは誤り

• 悪い抽象化についての説明

  • 将来の利用を十分に考慮せずに設計することが問題

• Rob Pikeは「少しのコピーは少しの依存よりましだ」と述べている

  • DRY原則は時に抽象化を追加するが、その抽象化が十分に直交していなければ、むしろ問題を悪化させる