あけましておめでとうございます。 今年もアジャイルな@HIROCASTERでございませう。 達人出版会でお年玉セールとして、昨年、26人の日本人が生々しいアジャイルソフトウェア開発の成功と失敗を書き記した「サムライエピソード」が40%OFFで期間限定で購入できます。 通常だと800円のところ、480円で購入できます。
![お正月キャンペーン「サムライエピソード」40%OFF(800円が480円で買える) | Act as Professional](https://cdn-ak-scissors.b.st-hatena.com/image/square/5ae8e57c3d12dc22b05961fc4e36394ce9212e07/height=288;version=1;width=512/https%3A%2F%2Fhiroki.jp%2Fwp-content%2Fuploads%2F2012%2F12%2Fsamurai-episodes.jpeg)
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
TDDがアジャイル開発では前提ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテストリファクタリングテスト駆動開発(TDD)継続的インテグレーションこれら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニア一人一人
「ソフトウェアのプロになるには本書が必要だ!」と、ボブおじさんがおっしゃっております。 このボブおじさんは、あの有名なアジャイルマニフェストにも名前を連ねているRobert C. Martinです。 プロとしての最低限必要な知識、姿勢、規律など、教育を受けたり学んだことがあるプログラマはあなたの現場に何人ぐらいいるでしょうか? 今こそ、本書を取って、プロとしての道を歩み始めて欲しい。(amazonでずっと売りきれだったけど、やっと入荷したようだ。すぐに売り切れそうではあるが…) プログラミングの練習 僕はプログラミングの練習というのを意識的にあまりやったことが無い。日本だとTDD Boot Campなどでおこなわれる小さなテーマでプログラミングをおこなうことである。本書の6章に練習について書いてる。 個人的にはRubyKaigiで、ペアプロした外人が、これはToys Programming
スケジュールを立てるということについて、真剣におこなっているのかということに心当たりがあったので。 CSM研修初日メモ – ShiroKappa Blog で、Scrumでのスプリント(イテレーション)が中断されることについて、書かれていたので、経験的なことを書いてみる。 コーチによって、いろいろと意見が分かれるところであるので、一つの意見として参考にして頂ければ幸いです。 イテレーション計画の余裕について イテレーションでこなせるタスクをギリギリの量で計画は絶対にしないこと。開発者にある程度の余裕があって、終了を迎える程度にする。 具体的には、1週間から2週間のイテレーションだと、1日ぐらいの余裕は必要であると考えている。 余裕を与えすぎると働かないのでは?効率が悪い? 自己組織化したチームは、イテレーション内にやるべきことが終わってしまえば、自主的にソフトウェアの改善に勤めたり、次のイ
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15%増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15%多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか?将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
code school という学習サイトがあります。現在は、Ruby on Railsに特化したコンテンツがありますが、確認する限りでは、jQueryやHTML5 & CSS3のコンテンツが近いうちに公開される予定です。 なにが、いまどきなのか? Ruby on Rails(rails3に対応してる)が無料で学習できる Rails for Zombies をやってもらえば、すぐにわかるのですが、rails環境を一切つくることなく、Webブラウザだけで完結しているコンテンツなんです。 つまり、ブラウザにコードを打ち込んでいくと、動作する結果を返してくれるのです。環境作りに苦労することなく、学習に専念できるのです。 初心者向けのコンテンツだからこそ、こういった配慮は大事だなぁと考える。 Rails for Zombies は5章構成になっていて、1章ずつ動画で丁寧に説明されている。英語が聞き取
ガーデニングのメタファーはソフトウェア開発の現実にかなり近いものです。あるルーチンが大きくなりすぎたり、色々なことを実現しようとしすぎている場合、2つに株分けする必要があるのです。また、計画通りうまくいかないものは雑草を抜いたり剪定してやらないといけないのです。 こういったコード記述のやり直し、再作業、再設計を総称して「リファクタリング」と呼びます。 リファクタリングのきっかけDRYの原則に反している直交していない設計時代遅れの知識をつかっているパフォーマンスがわるいクラス、メソッドが長い名前がしっくりこない同じようなコピペコードがいくつも見られ、UIを直すとロジックを直して、DBもなおすとか。非推奨のメソッドを使っていたり。ループ分が多いし、やってることとメソッドの名前があっていないとか。みなさんも、思い当たるようなことはありませんか? タイミングとガン細胞の切除 きっかけを見つけたら、
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか?p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く