手続き型人間診断
・過去に成功した手法があれば余程のことがない限り方針を変更しない
・動いているコードは触るな！が原則
・設計は最初に完璧にやるものである。後で変更が出るのは設計ミス
・コードを小分けのメソッドにすると処理がわかりにくくなるので見つけ次第インライン化する
・ListやMapに独自で複雑な意味を持たせてトリッキーな処理でコード量を減らすと「俺最高」と思う
・エディタをスクロールしないと処理全体を表示出来ないようなメソッドがあっても気にならない
・メソッドのことを関数もしくはサブルーチンと呼び、フィールドのことをパラメータを呼ぶ
・バージョン管理は使用しない（日付つきのバックアップフォルダを大量に作成）orロック式でないと安心して使用出来ない
・Excel方眼紙とExcelVBAによる自動化が大好き
・ウォーターフォール以外の手法が成功するわけがない、と思っている
結果診断
| 一致数 | 内容 |
|---|---|
| 10 | 化石級手続き型人間 |
| 7−9 | 中々の手続き人間 |
| 4−6 | 手続き寄り。今ならまだ変われる！ |
| 1−3 | 現代の標準的プログラマー |
| 0 | オブジェクト指向・アジャイルがお好きですね？ |
何故問題か？
・過去に成功した手法があれば余程のことがない限り方針を変更しない
→糸電話で成功し続けていたら、スマホに乗り換えないのですか？
・動いているコードは触るな！が原則
→触らないことで短期的なリスクは回避できますが長期的には負債を負い、メンテ不全が待ち受けています。
虫歯が出来たら痛み止めでしのいで放置しますか？
治療を行なってきっちりなおしますか？
・設計は最初に完璧にやるものである。後で変更が出るのは設計ミス
→コードを書かなければ見えてこない部分は必ずある。また、ビジネス要求は頻繁に変化し、
それに対して素早く対応する必要があるため仕様を完璧に固めることを前提とするのは時代にそぐわない。
納得が行かない場合はMartin FowlerやKent Beckなどの優れた技術者の著書を読むことを推奨します。
「達人プログラマー」「リファクタリング」「XPエクストリーム・プログラミング入門―ソフトウェア開発」
「アジャイルサムライ」「情熱プログラマー」等。
・コードを小分けのメソッドにすると処理がわかりにくくなるので見つけ次第インライン化する
→部章節項ごとに綺麗に階層化されている書籍と、章立てが全くなく最初から最後まで
ダラダラと書かれている書籍のどちらが読みやすいですか？
また、処理を細かく分けることでテストが容易になり保守性が向上し障害時の原因特定も容易になります。
・ListやMapに独自の意味を持たせてトリッキーな処理を作ると「俺最高」と思う
→説明しないと分からない処理は自己満足。データの振るまいと属性に注目し、オブジェクトとして
扱うことで人間が分かりやすく保守しやすいソースになります。
トリッキーなコードは時間をおいて読み返した場合や、他担当が引き継ぐ場合、また拡張性の面でも
問題になる可能性が高いです。
・スクロールしないと全体を表示出来ないようなメソッドがあっても気にならない
→一般にソースコードは長いほどバグが発生する確率があがります。
原因の特定も困難になり、ユニットテストも困難になります。
また、人間がコードを追う際もスクロールすることで脳内に変数や分岐の内容を
記憶しなければなりません。頻繁に上下のスクロールを繰り返すことになり、処理の流れを
把握しにくくなります。
・メソッドのことを関数もしくはサブルーチンと呼び、フィールドのことをパラメータを呼ぶ
→ノーコメント
・バージョン管理は使用しないorロック式でないと安心して使用出来ない
→バージョン管理は環境上の制約（容量等）がない限りソースファイルだけではなく、
開発に関わるできる限りの資料を管理対象にすべき。
作業の手戻りが防げます。ある特定時点の情報が必要になる機会は必ずあります。
管理ミスによるデグレードが防げます。デグレードはソースコードだけの話ではないので
ドキュメントも管理すべきです。
ロックに関してはコードの単独所有を前提とするがゆえ、という部分もあるでしょう。
コードを共同所有することには以下の利点があります。
共通処理を見つけた際や、全体に適用する修正などを発見したら気兼ねなくソースを編集出来る・
1つのソースコードに対して複数人が触れることで、属人性を排除出来る。
Aさんが休んだら手詰まり、のような状況を避けリスク分散を図れる。
リファクタリングを気兼ねなく行える。コードの品質を継続して高めるために重要。
上記のような共同所有の利点を活かすためには非ロック式のバージョン管理は必須です。
・Excel方眼紙とExcelVBAによる自動化が大好き
→作業の本質、保守性、作業時間を計測してください。
設計自体は何分で終わってますか？Excel方眼紙にまとめるのに何時間かかっていますか？
Excel方眼紙はメンテナンスするのが簡単ですか？
設計の記述を追加するのが目的なのにセルの位置調整と罫線の修正に大幅な時間をとられてませんか？
ExcelVBAの自動化処理は継続した拡張に耐えられますか？
VBAの生産性、可読性の低さ等が障壁になって自動化の適用範囲が貧弱になっていませんか？
異常に重いExcelファイルが出来上がって苦しめられていませんか？
プレーンテキストに書きだした場合と比較してください。
ExcelVBAの自動化は生産性の低いVBAが前提。
業務で登場する大抵の自動化ツールはExcel上でのボタン操作が必要。
それに対してプレーンテキスト＋スクリプト言語などによる自動化はプログラムから実行出来るため
各種自動化の中に組み込むことが可能。
自動化ロジック自体のコード管理、テストコードなどとの連携も容易で拡張しやすい。
また、素材がプレーンテキスト故に二次加工やバージョン管理ツールとの相性もよい。
どうしても見栄えの良いViewが必要になった場合はプレーンテキストを素材に
ExcelやWikiなどに変換すればよいのでは？あくまでマスタはテキスト。
・ウォーターフォール以外の手法が成功するわけがない、と思っている
→ノーコメント
総括
半分本気で、半分冗談で、ぐらいで受け取ってもらえると幸いです(^_^;)
