リファクタリングをいつ、どのようにやるか
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか？ リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか？おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
アジャイル界隈研修の感想まとめ
自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
