ぼくらはコードに住んでいる：エンジニアの「生き生き」とコードの関係性〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （４）
前回は、スクラムでは語られていない「内部の質」について踏み込んで話が弾みました。そして今回は、いよいよ「エンジニアの生き生き」とは何かについて話が進みます。 エンジニアの「生き生き」とは何か？懸田：次の話題ですが、「エンジニアは生き生きしないと」「エンジニアで生き生きって何だよ」というところを少し聞きたいなと思うんですけれども。どうですかね？言い出しっぺの家永さん？（笑） 家永：言い出しっぺ（笑）僕の開発の現場で見たシーンで最初に思い出すのが、これは僕の（会社で）できるエンジニアでワタナベさんという人がいるんですけど、誰かと一緒にステップバイステップでリファクタリングをやってみせるというのをやったんです。その隣の人の感想がすごく印象に残っていて「心が浄化されました。」ということを、すごい笑顔で言っているシーンがあったんですね。それってコードと自分の距離感というか関係性に変化があったというこ
ヘロヘロスクラム、内部の質、変化のための設計〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （３）
ヘロヘロスクラムを見かける話懸田：さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。 和田：ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか？」。 家永：これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。 和田：角さんが訳したやつ。 家永：和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か！？」とドキッとする機会が何度もある。例えば、僕は（Ruby on）Ra
粘土のように設計して外側のフィードバックループを回す 〜 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （２）
和田：そうですね。 家永：もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田：それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永：だんだん変わっちゃって。 和田：単なる作り直しをリファクタリングと呼んでいる、それはある。 家永：ちょっと何だかなあという感じ。「えっ！？」と、ドキッとする事があります。 和田：それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永：全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田：そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田：良い面というのはリファ
内なる秩序の探求〜テスト駆動開発をやめて、なお残すべき習慣とは(7)
はじめに前回は、外側のテストループについて何を作ればよいかの探求について解説しました。今回は、実際に「どう作ればよいか」について、コードや設計の内側の秩序の探求について解説します。 TDDの肝は、動作するきれいなコードを目標に、テスト書いて、 実装して、学んで、リファクタリングして… を小さく繰り返し、内なるコードや設計の秩序化するステップを踏み続けることにあります。では、「動作するきれいなコード」と呼ばれる目指すべき場所は何を頼りに向かえば良いのでしょうか？ プログラミングにはコードや設計の秩序化を図るための定石が幾つか知られています。例えば、UNIXの設計判断（例：一つのプログラムには一つのことをうまくやらせる）、メタファ、名前重要、DRY原則、SOLID原則、KISSの法則、コマンドクエリの分離原則、契約による設計、オブジェクト指向のイディオム、関数型のイディオム、各種の言語やフレー
最初からクライマックス！デプロイから始めよう〜テスト駆動開発をやめて、なお残すべき習慣とは(5)
AmazonでSteve Freeman, Nat Pryce, 和智 右桂, 高木 正弘の実践テスト駆動開発 (Object Oriented SELECTION)。アマゾンならポイント還元本が多数。Steve Freeman, Nat… １．プロジェクト開始直後に本番に近い環境にデプロイする”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。 プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事の
タスクをどんどん、DONE（どーん！）しよう♪
https://www.flickr.com/photos/iyoupapa/30887372435/2017は、勢いよくどーんと行きましょう。今日は、僕の経験とスクラムをもとに、プログラマがどんどんタスクを終わらせ、DONE（どーん！）させるコツをお伝えします。極めて簡単なコツなのですが、アジャイルコーチをやると毎回指導しているのを思い出し書き出してみました。 何ができればDONE（どーん！）なのかタスクのゴールの条件を明らかにするプログラミングのお仕事は、１人で完結することはほぼありません。仕事の依頼主が期待する結果は何か、なにができればタスクが終わったと言えるのかを合意することは欠かせません。また、運用担当やテスト担当などの同僚へどのように引き渡せば、困らないかを把握する必要があります。終わりの条件が多すぎるのであれば、ステップ・バイ・ステップでゴールへ向かうことができるように、ちょ
フィードバックをイチから学び直す〜テスト駆動開発をやめて、なお残すべき習慣とは(4)
前回、テストの４象限を紹介しました。今回からフィードバックについては、複数に分けて解説します。1回目は、フィードバックの基本のキから解説します。次回に実戦テスト駆動を参考に多重のフィードバックを解説する予定です。 フィードバックのおさらい”フィードバック”という言葉は、意味が多義的に使われており、誤解を生じやすいです。Wikipediaのフィードバックを下記に引用します。 フィードバック（feedback）とは、もともと「帰還」と訳され、ある系の出力（結果）を入力（原因）側に戻す操作のこと。古くは調速機（ガバナ）の仕組み[1]が、意識的な利用は1927年のw:Harold Stephen Blackによる負帰還増幅回路の発明に始まり、サイバネティックスによって広められた。https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3
CoolなソロとHotなペアプロのあいだ
チームでプログラミングをする際、幾つかのスタイルが存在します。どの場面でどのスタイルを使うかについて経験を元にご紹介します。 https://commons.wikimedia.org/wiki/File:Pair_programming_1.jpg一人が黙々とプログラミングするソロのスタイル、ソロでプログラミングしつつも「（WIP）プルリクエスト」のオンライン上「コードの共同所有」で集団で洗練させていくスタイル、２人が同じタスクを同じディスプレイを共有し対話しながら難しい問題を解いていく「ペアプログラミング」スタイル、複数人がホワイトボードと巨大なディスプレイに集まって寄ってたかって、議論しながら開発する「モブプログラミング」スタイル、などがプログラミングスタイルとしてよく知られています。 しかし、実際の開発の現場では、「ソロプログラミング」「プルリクエスト」「コードの共同所有」「ペアプ
君はWard Cunninghamを知っているか？（前篇）
AmazonでAndrew Hunt, David Thomas, 村上雅章の新装版 達人プログラマー 職人から名匠への道。アマゾンならポイント還元本が多数。Andrew Hunt, David Thomas, 村上雅章作品ほか、お急ぎ… 君はWard Cunninghamを知っているか？が、その前に寄り道です。今回は、達人プログラマーの序文を書いた Ward Cunningham(ウォード・カニンガム. 以下 Wardと略す)に触れたいと思います。Ward は、今のソフトウェア開発の歴史に影響を与えた活動と成果が幾つかあります。それは、Wiki、パターン、CRCカード、エクストリームプログラミング（XP）、Fit、そして技術的負債です。Ward の名前を知らなかったとしても、いくつかの言葉は聞いたことがあるでしょう。 この記事を書こうと思ったのは、訪問先の若手2年目が達人プログラマーの序
君はWard Cunninghamを知っているか？（前篇）
AmazonでAndrew Hunt, David Thomas, 村上雅章の新装版 達人プログラマー 職人から名匠への道。アマゾンならポイント還元本が多数。Andrew Hunt, David Thomas, 村上雅章作品ほか、お急ぎ… 君はWard Cunninghamを知っているか？が、その前に寄り道です。今回は、達人プログラマーの序文を書いた Ward Cunningham(ウォード・カニンガム. 以下 Wardと略す)に触れたいと思います。Ward は、今のソフトウェア開発の歴史に影響を与えた活動と成果が幾つかあります。それは、Wiki、パターン、CRCカード、エクストリームプログラミング（XP）、Fit、そして技術的負債です。Ward の名前を知らなかったとしても、いくつかの言葉は聞いたことがあるでしょう。 この記事を書こうと思ったのは、訪問先の若手2年目が達人プログラマーの序
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
