ソースコード品質概論 なぜソースの品質を追求するのか tk-engineering.com
まず初めに なぜ、今更「概論」なのか 色々なところで「くソース」について語ってきました しかし、それが「何故悪いのか」という視点が若干あいまいなままでした（反省）。 そこで改めて「ソースの品質」について定義し、それが何故悪いのかを明らかにします。
An apology サンプルソースは一行もありません！ コーディングネタもありません。 では、気を取り直して行ってみましょう。
ソースコードの品質とは まず、品質とは…（大雑把なまとめ） 機能性 機能要件を満たす事 信頼性 故障しないこと（≒エラーで落ちないこと） 機能性 機能要件を満たす事 信頼性 故障しないこと（≒エラーで落ちないこと） 使用性 利用者にとって使いやすいこと 効率性 応答速度や、リソースの有効利用 保守性 拡張、修正がしやすいこと 移植性 配布、他システムとの共存利用 この辺りの話にかかわります ここを掘り下げていきます
ソフトウェアの保守性 保守（=maintain)とは… ソフトウェアを維持するために必要な作業 それらに合わせるために必要な作業 「気が変わった」とか 法改正に伴う変更とか 会社合併とか 新しいバージョンのOSのリリースとか その他諸々、なにひとつ「変化しない」ものはありません それらに合わせるために必要な作業
保守とは ライフサイクルの中でもっとも長い期間 新規構築の期間より保守の期間が長いのが 一般的
保守とは-2 保守性が悪いと… 保守に必要な工数が増大する →経済的に問題 →士気の問題 例：価格は安いが燃費の悪い車は良い車？ 保守要員は永く同じプロジェクトにとどまる傾向があるので 飽きる！！ 新規構築の方が注目される、或いは技術的に面白そうなので、やる気が出ない！！ 過去のソースを解析するという作業は多くの場合、 楽しくない！
さらに悪いことに… エンドユーザから簡単に見えることでも、やたらと時間がかかるので、お客さんも嬉しくない。 儲からないので、経営側も嬉しくない。 がんばって解析してもあまり喜んでもらえないし、技術的挑戦もないので、技術者も嬉しくない。 こうして誰も幸福にしないシステム ができあがる。
そうならないためには… 保守性を考慮したシステムを作る！ まず、「何が保守性を向上させるのか」 を考えましょう。 というか、「保守性を低下させるものは何か！」 を考えたほうが面白い！！
保守性を低下させるものは… Developerの立場で考えてみると… これらが何処から生まれるか… 保守性を考慮しない設計 保守性を考慮しない実装 これらが何処から生まれるか… 単なる無知 納期に追われる「デスマーチ」や「やっつけ」 その他諸々 せめて無知はなんとかしようよ…
保守性の高いシステムは… 「早い」「安い」「使える」な機能改良 誰でも保守できれば… 簡単に直せれば… 突然の法改正でも安心！ →お客さんも幸福 誰でも保守できれば… →経営的にもアレコレ嬉しい。 →技術者も新しい技術のプロジェクトに移れる。 簡単に直せれば… 夢の「定時退社」！な日々がくるかも… 要するに、みんな幸せ！！（一応理想は高く…）
究極の目標は… 「直しやすい」 「誰でも直せる」 これが、我々の目標です。 っていうか、「我々」って誰!? そんなシステムを実装、設計の視点から… これが、我々の目標です。 っていうか、「我々」って誰!?
キャッチコピー 「後は頼んだ!」 →誰でも直せる。 →すぐ直せる。 「カンファレンスのため休みます。」 そういう活動にも取れる時間を！
と、大きく出てみましたが… 要するに、「くソース」を笑いましょう。 そして、何故それが笑えるかを考えましょう。 それを肴に楽しいひと時を過ごしましょう。 以上！！