コーディングは多くの開発者にとって楽しいものです。コーダーであれば退屈することはありません。毎年、多くの新しい言語、技術、フレームワーク、ライブラリが登場します。
コーダーはあらゆるプロジェクトの中心的存在であり、その貢献は極めて重要です。優れたコーダーがいれば、プロジェクトが成功する可能性は大きく高まります。
では、どのような人が優れたコーダーと言えるのでしょうか。短時間で大量のコードを書く人でしょうか。
どの開発者も、コードが増えると次のものも増えることを知っています。
- バグが増える。
- コードスメルが増える。
- サポートが増える。
- ドキュメントが増える。
各行のコードは、コードベースに問題を持ち込み、技術的負債を増やす可能性があります。バグの数を減らすには、一般にコードを少なくする方が望ましい方法です。
例としてバブルソートアルゴリズムを見てみましょう。ゼロから実装するために50行のコードを必要とする開発者もいれば、よく知られたライブラリを使って2行だけで済ませる開発者もいます。
ゼロからコーディングすることと、よく知られた成熟したライブラリを使うことには、どのような大きな違いがあるのでしょうか。
成熟したライブラリには次の利点があります。
- 何千人もの開発者に使われている。
- 十分にテストされている。
- 継続的に進化し、多くのOSとの互換性が維持されている。
- 適切に最適化されている。
- ドキュメントが充実している。
- 保守されている。
優れたコーダーは、既存の解決策を探すことに抵抗がありません。複雑なものを実装する前に、よく知られたライブラリがすでにその処理を行っていないかを確認してください。C++にも、ほかの言語と同様に、STL、Boost、POCOなどの興味深いライブラリが多数あります。
開発者としての私の経験では、優れたコーダーとは、コードを少なく書き、効率的に作業する人です。必ずしも卓越したスキルを持つ技術の達人ではなく、目的に合ったライブラリを探して選ぶ方法を知っている人です。技術の達人はゼロからコードを書きがちで、それがコードベースの品質を損なうことがあります。
では、適切なライブラリはどう選べばよいのでしょうか。
ソフトウェアライブラリを選ぶのは、必ずしも簡単ではありません。特に、特定のニーズに対して競合するライブラリが多数存在する場合は困難です。開発チームがライブラリを選ぶ際には、多くの要因が影響します。その一部を紹介します。
1. ライセンス
最初に確認すべきなのはライブラリのライセンスです。その機能を調べる前に、プロジェクトでライブラリをどう使用するつもりなのかとライセンスに互換性があることを確認することが非常に重要です。
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2. ライブラリはニーズを満たしているか？
当然に思えるかもしれませんが、ライブラリがすべてのニーズを満たしているかを確認するために、小さな概念実証を実際に行う開発者はどれほどいるでしょうか。何らかの理由でライブラリが適していないことに、非常に早い段階で気づくこともあります。
3. コミュニティが活発である
ライブラリを使用していると多くの問題が発生する可能性があります。コミュニティが活発であれば、解決策を迅速に見つけやすくなります。
4. ライブラリの採用傾向はどうか？
ライブラリの人気が高まっているかどうかを知ることは興味深いことです。そのためには、Google Trends を使ってライブラリの長年の推移を確認できます。
たとえば、d3.js API の傾向は次のとおりです。
5. ライブラリに過去の破壊的変更はあったか？
ライブラリを採用する前に、数分かけて「LibraryName breaking changes」でWeb検索し、特定のバージョンで破壊的変更が導入されていないかを確認してください。
これは次の理由で役立ちます。
- 古いバージョンのライブラリ例を使わずに済む。
- 大きな破壊的変更は警告サインになる可能性があります。既存ユーザーとの互換性が優先されていないことを示している場合があり、将来のバージョンでも同様の変更が発生する可能性があります。
6. ライブラリの制約と制限
特定のニーズには優れたライブラリでも、使用を妨げる重大な制限が1つある場合があります。
例として Google Chart API を見てみましょう。これは非常に便利なチャートライブラリです。しかし、ユーザーがインターネット接続を持っている必要があるという、厄介な制限があります。
ライブラリを選ぶ前に、その制限のどれもがユースケースに影響しないことを確認してください。「LibraryName limitations」という簡単なWeb検索が役立ちます。
7. ドキュメント
ドキュメントが充実したライブラリは、特に使用例が多数含まれている場合、利用時に大きく役立ちます。
8. ライブラリ使用時のパフォーマンスを重視するか？
パフォーマンスが非常に重要なコンテキストでライブラリを使用する予定がある場合は、Web上のベンチマークだけに頼らないでください。特定の制約を使って概念実証を作成し、そのコンテキストでライブラリがどの程度の性能を発揮するかをより明確に把握する方が望ましい方法です。
9. アプリケーションはマルチプラットフォームか？
アプリケーションを複数のプラットフォームで実行する必要がある場合は、主に1つのプラットフォームでテストし、開発完了までほかのプラットフォームのテストを待ってはいけません。
最初から対象のすべてのプラットフォームでテストしてください。あるOSでは非常に適切に実装されていても、ほかのOSでは実装が非常に劣るライブラリもあります。
10. 選択したライブラリに対する有力な代替案がほかにもあり、判断に迷っているか？
場合によっては、同じニーズを満たす優れたライブラリが2つ見つかり、どちらを選ぶか迷うことがあります。この場合、コードをライブラリと強く結合させないでください。ラッパーやファサードパターンを使って使用箇所を分離することを推奨します。
もちろん、ほかにも多くの要因が選択に影響します。後で置き換えが必要になる可能性のあるライブラリを採用するリスクを最小限に抑えるには、ラッパーやファサードを使って、その使用箇所をコード内の少数の場所に限定するのが良い習慣です。
アプリケーションと使用しているすべてのライブラリとの結合度を評価し、コードと強く結合しているライブラリを特定して、可能な限り段階的に使用を分離してみてください。
外部ライブラリとの結合を簡単に検出できるツールは多数あります。例として、Javaでは JDepend と JArchitect 、C/C++では CppDepend 、.NETでは NDepend などがあります。