過去は未来に復讐する3
やっと本題(・∀・)
前の話を要約すると
- 世間には『標準』の(より望ましい)ルールがあると思っている
- ただ、状況によって(標準より望まくない)『例外』ルールを使わざるを得ない事もある
- 自分達としてはその状況に納得して『例外』ルールのドキュメントを作る
- 『例外』ルールのドキュメントがいつのまにか広まる
- 『標準』ルールを知らない人達は、その『例外』ルールが例外であることを疑わない
みたいな恐怖があるということなわけですが。
で、なんか今、既視感を覚る状況にあったりするんですよね(´Д`;)
今関わっているC#の某案件ですが、コーディング規約がチト独特でね…。
そこにC#がはじめてとか言う人を入れて開発している状況を見ると、将来的に前と同じような事が起こるんじゃないかと思ったり(´Д`;)
後、C#以外の言語*1しかしらない人達が、GCやusing/IDisposableについて正しい知識を得ないまま開発しているっていうのも、将来に悪い芽を残さないかなと心配で。
GCやusingとかいう以前に、基礎を知らないままプログラムをしている人達も多いわけですが。
そりゃ、プログラマの単価は安いし給料も少なくなるよ、っと…(´・ω・`)
社員・パートナー問わず、新人でもない人達に型や配列の基礎を教えている自分を省みて、情けなくなるというかなんとも言えない気分になるんですが。
本とかを買わないまでも、せめてこの辺くらいには一通り目を通しておいて欲しいと思うわけです。
基礎を分かっていないと、設計にしてもおかしな形を標準だと思いこんじゃう可能性があるしね。
この案件でも、特に外部に投げている一部機能のソースは基礎が分かっていないというか、設計が酷すぎるような。
管理チームのメンバーも、この辺の設計の酷さには目をそらしている気がする(´Д`;;)
それでもステップあたりのバグ抽出件数とかからは品質に問題が無いといっている喜劇(。∀ ﾟ)
まあ、主要機能じゃないのがまだ救いかな…。
逆に言えば、無理矢理なスケジュールを守ろうとするために、少しでもコアメンバーから手離れできる部分は、人数を確保できれば質は問わないような所に丸投げしていると言うことで、完全にマネジメントの失敗なわけですけどね(｀д´)
あと、コーディング規約を作るような状況なら、まずはオブジェクト倶楽部のやつを見てみましょうよ、っと言うことで。
http://www.objectclub.jp/community/codingstandard/
どうしても愚痴っぽくなっちゃうので、少しだけでも改善する方向の内容を盛りこんでみましたということで。
…いや、本題はどうすれば将来に禍根を残さずに済むかなんですけど…、さて(´ω`)
