ブックマーク / bufferings.hatenablog.com (10)
-
いただきましたー！わーい。脳に収めるぞー！ @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日︵2024年6月18日︶発売！ www.oreilly.co.jp どう書くのがいいんだろうなぁ？ 複雑なコードと向き合うときは﹁あー、これはメモを取りながら読まないと迷子になるやつだ﹂ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから﹁時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ？何かヒントがあるかなぁ？﹂って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー！と思ったのが、説明をTDDで進めていくってところ。好き
-
最近、毎日のようにEMのいくおさん︵ @dora_e_m ︶とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う︵ふだんから
-
コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に︵そのときはこんな感じだったんだろうなぁ︶って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき﹁だった﹂とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。
-
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに﹁この機能いつ出せるかな？﹂って聞かれることはあんまりないと思うけど、もし聞かれたら﹁んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね﹂ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って﹁Mサイズだから2ヶ月くらいだね﹂って話をするだけで済む。﹁2ヶ月くらいだね﹂って言ったものは
-
4/26 に発売されます！ ﹁ユニコーン企業のひみつ﹂をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も﹁なるほどそんな風に仕事をしてるのかー！﹂って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の﹁ユニコーン企業﹂とか﹁テック企業﹂って﹁大きくなってもスタートアップみたいな働き方をしている企業﹂のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を
-
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 ﹁これがなぜか動かない﹂って相談されたときって、いくつかの要素が絡んでることが多い。 なので﹁ここは明らかに問題ないでしょう﹂という一番土台のところからチェックを始める。そうすると﹁え？そこは問題ないと思いますよ？﹂って言われるので﹁うん、それを﹃問題ないと思う﹄じゃなくて﹃問題ない﹄って断言できるようにしようと思って﹂みたいな会話をよくする。 可能性をひとつずつつぶしていくと﹁ここだなぁ﹂って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、﹁ここは
-
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ノД`)シクシク github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
-
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので﹁今の自分の気持ちはどの
-
最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても﹁ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。﹂とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク
-
スクラムガイド2016年版 RSGTの発表のことを色々考えてたら、そもそもスクラムって何だっけー？って思ってしまって、スクラムガイドを読もうとしたら、あれ？2016年版ってのがある http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf さらーっと読みながら、あれー？スクラムの価値基準とかあったっけなー？全然覚えてなかったー。って思ってたら、スクラムガイドの最後に﹁2016年版ではスクラムの価値基準が追加されたんだよ！﹂って書いてあって。おー！そーなのかー！って思った。 スクラムの価値基準 Commitment, Courage, Focus, Openness, Respectの5つ。実際にはこんな風に書かれてる: スクラムチームが、確約︵commitment︶・勇気︵courage︶・
-
1
脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
何年も前に書かれたソースコードを読むときの頭の中 - Mitsuyuki.Shiiba
約束は開発を遅らせる - Mitsuyuki.Shiiba
「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
読みやすいコード（僕にとって） - Mitsuyuki.Shiiba
「スクラムの価値基準」にピンとこなくてウロウロしてきて、腑に落ちた。 - Mitsuyuki.Shiiba
