Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

達人プログラマー/六章 コーディング段階

達人プログラマーの六章に関するまとめ

  • 偶発的プログラミング

仕様も曖昧。設計も曖昧。そんな状態で作成したプログラムは
一見動いているように見えても問題を起こす可能性が大きい。
慎重なプログラミングを行うことでこれを回避する。
明確な仕様。設計。計画からはじめる。ドキュメント化された仕様に従う。
契約や表明を用いる。作業の優先順位をつける。過去のコードの影響を受けない。
以上によって偶発的プログラミングを回避すること。

アルゴリズムを理解する。大抵は既存の信頼できるライブラリがあるので
自ら複雑なソートアルゴリズムなどを実装する必要はないが中身を理解することは重要。
O(1)定数
O(lg(n))対数
O(n)線形
O(nlg(n))クイックソートヒープソート
O(n2)自乗
O(n3)三乗
O(Cn)指数

DRY原則に反するコード、時代遅れのコード、直行してないコード、パフォーマンスの悪いコード
などを改善するために既存のコードの実行結果を変えることなく内部処理のみを変更すること。
テストの自動化がされていると、回帰テストの工数が大幅に削減出来るために実施のための敷居が下がる。
現実の業務ではなかなかリリース済みのコードは直させてもらえませんよね。
特にBtoBのクリティカルなシステムの場合ならなおさら。
説得の例として好ましくないコードを腫瘍に例えるメタファが紹介されています。
確かにそうなんですよね、腫瘍は小さいうちに切り取ったほうがリスクが低い。
その重要性を説得できないと時おり見かけるような大企業のシステムの大障害のような自体になるわけで。
継ぎ接ぎだらけのシステムは達人技術者を追い払い、質の低い技術者のみをとどまらせて
どんどん質が下がっていく負の連鎖に陥りがち。
この辺は上層部およびお客様を説得するという高度なコミュニケーションスキルが必要ですね。

  • テストしやすいコード

テストしやすいように設計をされたコードは結果として高い品質になる。
直交性が保たれ、再利用性も高い。
xUnitを用いたTDD開発の利点のひとつですね。

  • 邪悪な魔法使い

ウィザードを利用する場合は裏で何が行われているか理解した上で使いましょうという話。

■感想
リファクタリングが重要なのはみんな理解しているが日本のシステム開発現場で
リリース済みでバグも発生していないプログラムをリファクタリングさせてもらった試しがない。
この辺は徹底した自動テストなどが導入されていれば事情も違うのでしょうが
元々そこまで徹底している現場なら直させて貰えそうに思います。
今のところ動いているものは触るな、の鉄則を破らせてくれる現場はないですね。

問題のあるコードの付近に改修が入るのを待つ、という消極的な状況を脱却したい。
影響を数字で表せばいいんですかね?
ここを○○パターンを用いて改修すれば、現状保守に5人月かかっている作業が
今後は1人月になります。初期工数はかかりますが長期的な利益で考えれば必ず利益になります!
・・・とか?


達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (348件) を見る