ReadingAgileSamuraiInActsystems20130415

← ReadingAgileSamuraiInActSystems

第25回 アジャイルサムライ読書会 in アクトシステムズ道場

日時: 2013年04月15日 12:05-12:55

参加者: 5名

第13章 リファクタリング：技術的負債の返済

◆ リファクタリングしてますか？

置かれた環境にかなり影響されるよね？

• いいソースを見てるかどうかで違ってくる

Javaを使い出してからするようになった。

• 統合開発環境(Eclipse)が補助してくれるので便利
  • 何してくれる？
    • 名前変更
    • メソッドのサブクラス／スーパークラスの移動
    • その他色々
  • 静的言語のなせる技。
  • Rubyではムリ(たぶんこれからも。。。）
• COBOL、VBなど言語に限らすしてる。
  • 言語でなく人によるかな？

してるつもりだけど、ちゃんとできてるかは疑問

◆ リファクタリングの手順、タイミングは？

製造の中でヤル（TDDのリズム）

PS(詳細設計)の段階でまとめる。

• 最大で10人規模のプロジェクトで実績あり。もっと大きくなるどどうなるか不明。
• レビューは時間を掛けてしている。

◆ リファクタリング後のＰＴはどうなるんだ？

修正したらテストしないといけないじゃない？

• だからテストの自動化があるんじゃない？
  • でもUnitテストは品質保証じゃないし。。。
• PTの工程があるんじゃったら前にしないといけない
  • ホントに大丈夫かはテスト担当者が品質保証しないと。
• アジャイルはそもそもテスト工程ってあるのか？
  • 実際のところわからない。
  • 受け入れテストを自動化することが推奨されてるけど。。。
    • 受け入れテストがパスすれば品質保証としてOK？

◆ お手本はあるのかな。ＶＢとか。リファクタリングしないといけないことはなにか？

リーダブルコードがお勧め

• 特別なことは書かれてないけど
  • わかりやすい表現で書かれている。ボリュームがちょうどいい（２〜３日でサクッと読める）。
  • 新メンバーにはぜひ読んでもらいたい１冊
• 格言「ボーイスカウトの発想」
  • 来た時より綺麗にして帰る。
    • ソースが汚れていれば、機能を追加する前に綺麗に
    • 機能追加したあと汚れてしまったら綺麗にしてから帰る。
  • わかりやすい表現だね。（一同）
• ソースコードは汚くなるものです。
  • リファクタリングは必ず必要。

◆ 課題

ソースコードはドキュメントとして定義しては？

• 設計のアウトプットもソースコードってのはアリ？
  • QMS的に許される？
  • 設計書を作ることが目的ではないのでソースコードがドキュメントとなればいいのにね。
    • 検討したいね。

コードリーディングを支援する仕組みがほしい

• Redmineにもリポジトリコミット時にメールで通知してくれるプラグインがあるので導入したい。

テストポリシーが人によってまちまち

---

次回 2013年05月07日(火) 12:05〜12:55