JJUG EclipseCollectionsで学ぶコード品質向上の勘所に参加してきた。 #ccc_gh2 #jjug_ccc

本日、参加したJJUGのセッションで、品質と言う面で色々考えさせられたセッション。

GSの伊藤さんが発表された資料はこちらになります。
http://www.goldmansachs.com/gs-collections/documents/2016-05-21_JJUG_CCC.pdf

今回は、品質向上という観点での話がメイン。
EclipseCollectionsの使い方ではない。

EclipseCollections
Eclipse Collections - Features you want with the collections you need. (日本語ページ)

特に刺さった部分を、走り書きですが、幾つかまとめます。

コードの品質とは？

ソフトウェアの品質とコードの品質はイコールではない。→ 実装時点で直接ソフトウェアの価値に影響を与えるコード品質
・インタフェースの品質（UI、API）
・実装の要求適合性・バグの存在
・実装のパフォーマンス（メモリ使用量、実行速度）

実装時点では必ずしもソフトフェアの価値に影響を与えないが、時間軸に沿ったソフトウェアの価値の増加率（生産性）に影響を与えるコード品質

・保守性（可読性、一貫性、簡潔性、等々）
・拡張性、再利用性
・テストカバレッジ

技術的負債

・コードの品質と引き換えにソフトウェアをリリースするスピードを重視した実装
・時間を経るにつれ、利子を払うかのごとく開発生産性を圧迫する
・技術的負債は必ずしも悪いわけではない(会計のB/Sで例を示した)

コードの品質のバランス

・ソフトウェアの特性によってどこの品質に重きを置くかは変わってくる
・コードの品質を議論する際には文化的な側面も多く、開発チームで「良いコード」「悪いコード」の認識を共有することも非常に重要
　　・組織のエンジニアリング文化
　　・プロジェクトチームのエンジニアリング文化
　　・個人がエンジニアとして育ってきた環境)

技術的負債とのつきあい方

技術的負債を完全になくすのは、ある程度の規模のソフトウェア開発に
おいてはほぼ不可能といえる
良いソフトウェアは技術的負債を「コントロール」する
・費用対効果を見積もる
・優先順位をつけ、技術的負債を戦略的に採用する
・返済計画を立てる

• 例：UnifiedSetとUnifiedSetWithHashingStrategyの重複
– UnifiedSetWithHashingStrategyは初期実装時点でUnifiedSetとのコード重複
が多く存在
– 戦略的に反DRYを許容
・そもそもの実装の複雑性から、重複の排除には時間がかかる
・重複は2クラスのみにしか存在せず、保守性への影響は限定的
・テストカバレッジを保障することで将来のリファクタリングは安全に実施できる
・すぐに重複を排除するよりも他の機能にリソースを投資したほうがライブラリにとっての価値が高い
– Issue Trackerに登録し、フォローアップ
– バージョン7.0のリリースでは重複を排除

文化の違いなどは、受け入れた上でコードレビューに臨むべきだということ。
実践編の技術的負債の付き合い方などの話は、今まで言語化できなかった部分が言語化されていて良い資料だと思いました。
すごく良いセッションだったので、是非資料を見てみてください。