だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp モブプログラミングやってきました！面白かったー。疲れたー。面白かったー。 モブプログラミングって？ チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を
#jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀｀)∩ - Mitsuyuki.Shiiba
楽しかった！ DDD & Microservices with Spring Cloud 前半がこれまで僕が経験してきたDDD 後半がこれからのために素振りしておきたいこと これまで僕が経験してきたDDD 最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。 DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ！」と思ってスクラムを導入してたんだけど、しばらくして「チーム
Domain Driven Design で Evans の言う「設計」って何？ #kandddj - Mitsuyuki.Shiiba
「関西DDD.java スタートアップスペシャル」に行ってきました。 会場は楽天の大阪支社ですん。kansaiddd.connpass.com まとめはこちら togetter.com 増田さんがEvansのDDD本の全17章を解説 だいたい、僕が事前に読んだときの理解と近い感じだったので安心しました。bufferings.hatenablog.com まぁ、理解と実践の間にはひどい壁があるから、これからね。 「チームで取り組まないといけない」 印象に残ったのは。「チームで取り組まないといけない」という言葉。何回も出てきた。 これが、僕、すごく苦手なんですよね。啓蒙というかエバンジェリストになるというか。そういうの。 そういうとこダメだとは最近思ってる。 でも、「ぐいっとやるときあるよ。俺は。」みたいなことも仰ってたので、安心もしつつ。 懇親会で増田さんに質問 Evansの言う『設計』とい
Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
僕の中のTDD BDD ATDD - Mitsuyuki.Shiiba
TDD プロダクションコードを書くのを引っ張ってくれるテストのことをDeveloperTestと呼ぶとして。一歩一歩、先にそれを書いてからRed→Green→Refactorのリズムでプロダクションコードを書く。 DevTestは、後でプライベートメソッドにするものも僕はテストしたりするんで、結構細かく大量になってしまう。なので、大切なのは、テストのリファクタリング。それやってないと「テストがあるから開発スピードがあがらない」とかいう状態になってしまう。負債。 下から積み上げて書いていくと、最後には、同じようなことを上のメソッドでもテストしてたりするので、「よし、このクラスの開発終わったー」ってなったら、そのあとにテストのリファクタリングをする。DevTestをUnitTest化する。と僕は呼びます。ま、クラスといわず、レイヤー間とかコンポーネント間のインターフェイスに対するテストまであげ
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba
組織パターンを読んでたら@haradakiroさんに「そんな風にして自分の頭の整理できるよ」と言われ。なるほど。と。なので整理。とはいえパターンに昇華させられるまで考えられたりはできないので雑だよ。 作りながら書いてるから最終的にどうなるかは僕も知らんよ。 立ち位置 最初に立ち位置を簡単に。 僕は自社でWebサービス作ってる会社のいちウェブアプリエンジニアです。 いい感じのチームでコードを書いて過ごしたい！ ↑ じゃあいい感じのチームを自分で作ろう！ ↑ じゃあチームの外側のコントロールしなきゃ！ ってだんだんやりたい場所から遠ざかっている感じ。てイマココ。 まぁこれも悪くない。 開発するときに考えていること まずは何をやるにも信頼関係を築くのが最初に必要よね。ないと色々面倒。 信頼を得て最初に取り組んだのが、プロジェクトのリーダーをBizLeadとDevLeadに分けたこと。 BizLe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
