実務とプログラミングのメモ
久しぶりにプログラムのお勉強などをする。
備忘録気味に疑問点など。
就職してから、新規にプログラムを起こしたことが1,2回程度である。もうずっと保守屋さん。
負の遺産をチマチマといじり続けるのはいやだよ。作られてからリファクタリングなんて一度もされたことのないコードを、影響範囲を最小化しながら調査・改修。モジュール化ってなに？ 過去のプログラマー達がオレを責める。
そんな現場が日本にどれだけあることか。
・エクストリーム開発の手法はチームでの開発に導入可能か？
テスト駆動型開発を始め、コーディングを重視するやり方ではドキュメントの作成についてはあまり触れられないように思う。
対顧客、チーム内、チーム間、様々な対象にコミュニケーションは発生する。コミュニケーションの軸になるのはやはりドキュメントであるわけで、ドキュメンテーションをどうするか？
というテーマでウォーターホール以外の手法を継続調査する必要がある。
ウォーターホール嫌いなんだよ。手戻りしない、課題保留しないプロジェクトなんてないのに、各フェーズが確実に実施される前提とか現実的じゃないもの。
・開発手法は保守・運用を重視して採用すべきだよね
レガシーをいじるとなぜOOPが必要とされるかよく分かる。
OOPの本質は「カプセル化」だね。継承とか多態性とかはおまけです。下手がやると保守性さがるよー。
既存機能がブラックボックスとして扱えることが重要。ブラックボックスとして扱えることが明確な作りになっていれば、オブジェクトになってなくてもいいよ、
と思ったけどブラックボックスとして扱えることを見つけられないことがあるから、オブジェクトにしておくのは重要だわ。再利用可能な部品を使わない人が絶対でてくるので、ドキュメントも重要。
システムは継続的に簡素に構造化されなければならない。３K。なんちて。
・プログラマーの重要性（ちなみにSEとプログラマーを分離する慣習は謎過ぎる）
プログラマーのレベルが保守コストに直結するのは、ちょっと大きめシステムを弄ったことある人なら誰でもわかるはず。
この辺、会社に対して金銭価値として認めさせるにはどうすればよいか？ というのは結構な課題。
説明しても、数で補えばいいとか考える人も多い。インカムをつくるのはPMだからって意識が根底にあるっぽい。
顧客にしてもイニシャル・コストばかり意識される不思議。この辺システムの価値を算出できないため、工数ベースでの金額提示になるってことと絡みがありそう。
ソフトウェア品質を要件に含むことが常識的になるべきだし、ソフトウェア品質を金銭価値に換算して提示できるような仕組みを作ることが重要な気がする。
なんかないかな。
・リファクタリング
嫌なにおいがした時がリファクタリングの時期だ、と偉い人は言っていたけど、
嫌なにおいしかしないモノをぽんと渡されて「やれ」ってのがプログラマ、SEのお仕事だと思うの。
どのように対応していくべきか。それが問題だ。
