タグ

ブックマーク / bufferings.hatenablog.com (5)

  • エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba

    最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え?そこは問題ないと思いますよ?」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは

    エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
    wwolf
    wwolf 2019/08/23
    「それは何かを確認してそう断言してるの?それとも想像?」的な事を聞くと逆ギレする奴がいるの本当解せない
  • #jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀`)∩ - Mitsuyuki.Shiiba

    楽しかった! DDD & Microservices with Spring Cloud 前半がこれまで僕が経験してきたDDD 後半がこれからのために素振りしておきたいこと これまで僕が経験してきたDDD 最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。 DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ!」と思ってスクラムを導入してたんだけど、しばらくして「チーム

    #jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀`)∩ - Mitsuyuki.Shiiba
  • Webアプリにドメインモデルはやり過ぎ? - Mitsuyuki.Shiiba

    ドメインモデル使うのは良いんだけど。シンプルなWebアプリで使うのって、やり過ぎじゃない?って思ってて。 だって、Webアプリは、DBに直接アクセスしてデータを取ってくる方が、パフォーマンスもいいし、変な詰替えもないし、シンプルでいいじゃん。って。 でも、かといって、じゃあ全部そういう形でいいか?って聞かれると、やっぱりドメインモデルがある方がいいとは思ってる。コードで業務を表現したいので。 なので、最近、僕が、いいなと思う構成はこんな感じ。 業務を表現するコアになる部分はドメインモデルで表現しておいて、それの一面を切り取って見せるWebの部分は、表示専用のDBを持っておく感じ。 来年はこの辺をSpring Bootとかで素振りしてみたいかなー。

    Webアプリにドメインモデルはやり過ぎ? - Mitsuyuki.Shiiba
  • 僕のチームのGitの開発フロー - Mitsuyuki.Shiiba

    を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん?ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを

    僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
  • 開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba

    自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう?と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる

    開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
  • 1