makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

アジャイルサムライ読書会 横浜道場 「リファクタリング:技術的負債の返済」に参加しました

2013/7/9(火) アジャイルサムライ読書会 横浜道場 「リファクタリング:技術的負債の返済」に参加してきました。

DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/4513

以下の書籍をターゲットとした読書会なのです。
アジャイルサムライ−達人開発者への道−アジャイルサムライ−達人開発者への道−
(2011/07/16)
Jonathan Rasmusson

商品詳細を見る


場所はいつもの横浜、アットウェアさんです。
参加者さんは20人くらいでしょうか。
今回は「リファクタリング:技術的負債の返済」がテーマということもあり、通常会ながら参加者多いですね~

以下、個人メモ。


ウチのチームは4名です。ホワイトボードと付箋はこんなカンジ。
20130709_yokohamadojo1.jpg

うちのチームのディスカッション、あと各チーム毎の発表の中で、以下のような意見が出ました。
---

■リファクタリングってどこまでやればいいの?
・書籍に紹介されていたリファクタリングの例が、ディスカッションの際に善し悪しが分かれた。
 → ソースの読みやすさは主観が入る。人によって異なる。ペアプロの際にも衝突することがある。
 → んじゃ、リファクタリングの落としどころってどうやって決める?
・互いに合意ができればいいのでは。
・互いに相反する場合は、第三者の有識者に意見を仰いではどうか。

■リファクタリングの方法
・リファクタリングの方法には2種類あるのでは。
 ①リファクタリングをタスクやチケットとして切り出し、リファクタリング自体を可視化する方法
 ②リファクタリングはプログラミングの中にまぶしてしまう方法
・@t_wada さんは②をお勧めしていた。

■ソースコードのチェック
・コードの品質を保つには静的解析も有効では。
・コードレビューだと人手がどうしてもかかるけど、静的解析なら自動化できるし。
・コーディング規約で枠組みを決めるのも有効かも。

■リファクタリングとテストコード
・テストコードがないと、リファクタリングって難しいよね。
・リファクタリングはテストコードがあることが前提。
・「リファクタリング」の定義に、テストがあること、があったはず。
・テストがないなら書けばいい。

■悪いコードってどんなん?
・ドキュメントとコードが一致してないとか
・DBが正規化されていないとか
・バッチファイルがビルド職人の技になって保守できないとか
・etc

■コードレビューやってる?
・プロダクトコードだけじゃなく、テストコードもレビューがないと辛い。
・レビューの前に、「読みやすさ」の認識合わせをしておくべきでは。

■リファクタリングとデグレードのジレンマ
・「動いているコードに手を入れるな!」という思想がある。
・テストでガードしてからリファクタリングすればいいじゃん。

■リファクタリングと新機能開発のバランス
・数回のイテレーションを回したあと、負債を返すイテレーションを1回入れるのはどうか?
 → 負債を返すだけのイテレーションって、お客さんに価値を提供してないじゃん。
・収入のすべてを借金を返すことに当てることはできない。

■技術的負債の原因
・無知
・新しい技術をなんとなく入れてみた
・設計の失敗

■リファクタリングに必要となる能力
・技術的な引き出しが必要になる。
・デザインパターンの知識があればなお良い。

■生産性
・生産性はLOC(Line of Code)で測るプロジェクトがあった。
 → リファクタリングしたらコード行数が減って、生産性がマイナスになった(笑
・リファクタリングで浮いた工数を測る方法がない。

■リファクタリングの禁じ手
・バグ修正とリファクタリングは同時にやるのはダメ。

■リファクタリングには2種類ある
・次の機能を追加するためのリファクタリング
・コードを読み易くするためのリファクタリング

■バグ票
・リリースしたコードに修正を加えるには、バグ票が必要になる。
 → つまり、バグ以外は修正の入口さえ用意されていない。。。
・バグ票を書いて、バグを修正する際に、その周辺をリファクタリングすれば良いのでは?
・バグ修正の工数を多めに申請して、リファクタリングも一緒にやっちゃえばいいのでは?


★感想:
こんだけ暑いと、AEP読書会のようにビール飲みながらやりたい!
...と、激しく思った。思わずTryに書いてしまった。

リファクタリングはやったほうが良いとわかっていながら、上の理解を得るのに苦労している人が多そうに感じた。
特に、リファクタリング工数の捻出と、デグレードの危険性の点で。
バージョン管理と次章のTDDがこの手の問題に貢献するとは思いますが、いずれにせよ難題だ。。。
今日はいろんな意見を聞けて大変参考になりました。



これも頑張って読む!

道場主さん、スタッフさん、参加者のみなさんありがとうございました。
関連記事
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/92-728c4227
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad