"Rename Hackathon"をしてみました
チーム内で、お祭り的なイベントとして、"Rename Hackathon"というイベントをチーム内でしてみました。
ルール
結果
- 参加者 : 6人(因みに…4名は日本オフィス。2名はインドオフィス。リネームタイムはリモートで同時に。)
- 30分間に出された総プルリクエスト数 : 32
- ルール違反 : 2件(複数箇所修正、パッケージを1回層削除)
- 重複したため投票で却下 : 2件
- コードレビューで却下 : 8件(まだ一部レビュー中なので増えるかも)
- ということで残ったプルリクエスト数 : 12 ~ 20
- 修正の例
- クラス
- 不要(しかも意味不明)な接頭辞や接尾辞の削除
- 省略されすぎていて分かりにくい名前を展開
- メソッド
- booleanを返すcheckXXXX メソッドを isXXXXX メソッドに
- 変数
- i などの無意味な名前を 意味のある名前に
- クラス
所感
楽しかった
お祭りみたいで楽しかったです。ある程度ゲーム性のあるルール*2をしっかり作ったので、数を競うのも楽しんでくれた感がありました。
コードがきれいになった
これはもちろん。本来なら最初のコーディング時に埋め込まれるべきでない名前もちらほらありましたが、どうしてもできてしまうのは避けられないもの。
また、開発者のドメインナレッジが増すことによってより良い名前を後から思いつくこともあります。
そういった、普段のもやもやを片付けられた良い機会でした。
初級者の学びに
32件中8件はコードレビューで却下ということで、たかだかRenameなんですが、意外と他の人の了承を得られていないんですね。*3
「良い名付けとはなにか」の学びができた、良い機会になったと思います。
「解決策から考える病」に名前をつけたい
…って、タイトルで名前つけちゃってますが。
どうしても人間、「なんとなく思いついたソリューション」に飛びついちゃうんですよね。
寝坊しまくってるから目覚まし時計を買わなきゃ…! ってなりがち。
その前に、そもそもなぜ寝坊しているか? について考えないといけない。*1
※上の画像は以前に書いたこちらの資料より。もともとKPTのやり方を説明した資料ですが、根本的な考え方は共通だと思います。
自分がこの考え方ができるのは… 弊社の入社前課題でもらったこの本のおかげっぽいです。
他にも色んな経験が元になっているのだとは思いますが、「なんで自分、こういう考え方をするようになったんだっけ?」と思案したときに、思い出すのはこの本です。
*1:実際のチームだと…「そもそも寝坊は悪いことなのか? 悪いとしたらなぜ?」まで一旦掘り下げたいところです
JavaのHashMapは無限ループを引き起こす
知らんかった。理由がぼんやりはイメージ湧くけどしっくり来てないので後でちゃんと調べ…たい。(だいたいやらないパターン…)
d.hatena.ne.jp
www.atmarkit.co.jp
wadahiro.hatenablog.com
回避方法はいろいろあるみたいだけど、ConcurrentHashMapをつかってスレッドセーフにするのが楽なのかな?
web.plus-idea.net
価値観ババ抜き大体験会!に参加してきました #devlove
悩めるオジサンの私が、自分を見つけるためにぴったりそうな価値観ババ抜き体験会に参加してきました。
https://devlove.doorkeeper.jp/events/85438
価値観ババ抜きって何?? というのを書こうと思ったのですが 冗長になる&講師じゃない自分が変に説明して誤解が広がっても嫌だな
ということで、上記のイベント告知 及び、コチラの公式サイトのリンクをご参照ください。
http://myvaluecard.com/
いきなり考えさせられる名札書き
何この「どこから来た」って!
ストレートに社名を書こうとも思ったんですが、あぁ、なんかあるんだろうなこれ と 邪推し、こんな感じに。
「『シングルプレーヤーとマネジメントの間』から来ました」って… 今見返すとすごく恥ずかしい。
でもこの手の、自分と対話するゲームするときはこのくらい、のっけから自分を晒していかないとですよね!
ちなみに、この名札は、開始前の雑談以降は全く使いませんでした(笑)
ババ抜きの結果
さて、最終的に5枚のカードが手元に残るのですが… 私の結果はこちら!!
いやいやいやいや 「美」ってなんだよ、「美」って。よりによって俺が「美」って。
って思うんですが。
このカード、偶然にも最初の5枚に入ってまして、
「なんだこれ? すぐ捨てよう」
と思ったものの、
「でも、バグのないシステム、きちんと『切られ』た、読みやすいコードって、まさに『美』だよなぁ」
と思ったら
「これはこれで 大切かぁ…」
と思い
気づけば最後まで残ってしまいました。
また、ゲーム中は各カードはあまり繋がりがなく、バラバラに5枚残った… と感じていたのですが、
よくよく見ていると…
なんとなーく 隣のカード同士の関連のようなものが見えてきました。
まさかの、最後の1枚、「メイン」になったのは…
更にここから追加のワーク。残った5枚の中から1枚のメインと2枚のサブを選ぶことに。
「そら、この中からメインを選ぶんだったら『楽しさ』よ」
と思ったんですが、どうしてもしっくりこない。
どうしてもどうしても気持ちがそっちに行かず…
最終的に私が選んだのは… これ。
「『美』しいシステムを作るには『知識』が必要であり、それを学ぶモチベーションとして支えるのが『楽しさ』」
という、「美」を頂点にしたピラミッドができてしまいました。
えええ…
これだと俺の中で一番大事なことが「美しい」ことになってしまうんですけど……
とはいえ、恥ずかしさとか、どう思われるかとか、そういうのを捨てて、自分に問いかけたときに、
もう一回やったらどうなるんだろう
今回は偶然にもはじめの手札に「美」があったのでこのような結果になってしまったのですが、もし「美」がずっと他の人に持たれていたり、あるいはずっと場にあったとしたら*1、全く違う結果になったのでしょうか。
その場合自分は何をメインに置いたのか…
時期をおいてまたやってみたいものです。
実際、平日の夜にやるのか休日にやるのかでも結果が変わるとのこと。
脳内がお仕事モードなのかプライベートモードなのか、あるいは、仕事モードの中でも何に時間や脳みそを取られているのか といった状況によってかなり結果が変わりそうですね。
最後にお手紙タイム
最後は、一緒にババ抜きをした他の3名に向けて、お手紙を書いて渡す というちょっと恥ずかしいけど嬉しい時間でした。
*1:カードを取られるたびに自分で場から一枚好きなものを選ぶことができるのですが… 自分から「美」は取らないような気がします。それとも今回みたいに、たまたま目があってしまった後に同じ思考になって結局取るんだろうか…
あらゆる「システム」の挙動は入力と出力だけで説明できる
どんな粒度、どんな用途の「システム」も、挙動は入力と出力だけで説明できます。
プログラムのサブルーチン(function, method, ...)
「引数」と「返り値」で挙動が説明できます。
public String greet (String name){ return "Hello " + name + "!"; }
でも、データ更新したりするでしょ? 入力と出力だけじゃ説明できないじゃない!
このようにシステムを見ると、「状態が更新される」ことも挙動の説明としてする必要があります。
ですが、ここだけをシステムとして見ると… DBへの更新は「出力」の一種と見ることができます。
このシステムは、APIのクライアントと、DB という2種類の外部システムに、出力をするシステムです。
プログラムのサブルーチンの場合も同様です。
class Person { String name; public setName(String name) { this.name = name; } }
このコードは、このようにも捉えられますが
nameはPersonから依存があるだけの別インスタンスなので、このようにも捉えられます。
逆にDBからデータを読むようなシステムは、「入力が2つある」と捉えることができます。
バグチケットに各APIのリクエストとレスポンスが貼ってあったらバグの調査は早く終わるのか?
モヤモヤと考えたことを書き出しています。結論ありません。実践もまだしてません。
背景
私は今、こんな感じでInternalなWeb APIが相互作用するサービス*1に関わっています。
また、こんな感じで組織が別れています*2。
さて、このサービスについて不具合が起票されることがあります。
リリース前のQAだったり、残念ながらリリース後、本番可動しているサービスに対してだったりします。
いずれにしても大事なこととして、不具合はここの視点、最も浅いレイヤである、UIの「挙動が期待通りでない」事象として発見されます。
一方システム的には、不具合の原因は以下のいずれかになります(複数の組み合わせの場合もある)
不具合を修正するためには、この中のどこに問題があるかを見つける必要があります。
どうすれば早く原因が見つかるのか
シンプルに、いずれか一つのプログラム(=UI component または API 1~4 のいずれか)にバグが有るケースを考えます。
バグが有る、ということは外から見たプログラムの挙動として、以下の2つのいずれかに分類することができます。
たとえばAPI 3がバグっていて、「正しいリクエストを受けているのに、レスポンスが正しくない」場合
API 3が正しくないレスポンスを返すので、それがAPI 1→UI と伝搬することになります。
この場合、API 3を修正する必要があります。
また、API 2がバグっていて、「正しいリクエストを受けているのに、次のAPIの呼び出しが正しくない」場合
API 4そのものは正しく動作していますが、リクエストが誤っているため期待通りでないレスポンスを返し、最終的にそのレスポンスが原因となってUIの挙動が期待通りになりません。
この場合、API 2を修正する必要があります。
「赤い矢印」が見つかればどのプログラムがバグっているのかわかる
前項で見たとおり、期待通りでないリクエスト、またはレスポンスである、「赤い矢印」
がどこから始まっているかがわかれば、バグのあるプログラムである、「赤い四角」
の箇所が特定できそうです。
ということで、バグが起票された際に、全APIのリクエストとレスポンスがチケットに貼ってあれば、即座にどのAPIがバグっているのかわかるのでは? と考えました。
こんな表を自動生成することはできないでしょうか。
API | リクエスト | レスポンス | 他APIへのリクエスト |
---|---|---|---|
API 1 | to API 2 , to API 3 | ||
API 2 | to API 4 | ||
API 3 | |||
API 4 |
※矢印はイメージです。実際はこの表の各セルに具体的なJsonが書かれます
Spring Cloud Sleuth でTraceIDを発行しているため、一つのUIアクセスから始まる各APIのリクエスト/レスポンスを集めてくるのは技術的には可能そうです。
「赤か青か」を判断するのが実は難しい?
上の表では、API 2は正しいリクエストを受けているにもかかわらず、API 2からAPI 4へのリクエストが間違っています。ここから、API 2にバグが有る、と推測することが可能です。
では、API 2→API 4のリクエストが間違っている と気づくことができるのは誰でしょうか…。API 2はTeam C、API 4はTeam Dが担当しているので、それぞれのチームのエンジニアに気づくチャンスがありそうです。
API 2の担当エンジニアは気づけるか?
まず、API 2の担当エンジニアは、上の表から以下のことに比較的簡単に気づけそうです。
ここから、API 4へのリクエストが間違っているか、API 4そのものにバグが有る という推測は立てられそうです。
しかし、API 4へのリクエストの検証についてはどうでしょうか。
シンプルな間違え*3ならばすぐ気がつけそうですが、もう少し複雑な間違えですとすぐには気づけないかもしれません。
また、API 2の担当エンジニアが、API 4のリクエスト使用を誤って理解しているかもしれません。
レスポンスの正しさの確認のほうが簡単かも
では一旦、「すべてのAPIのリクエストは正しい」と仮定して、レスポンスの正しさだけに注目したらどうでしょうか。
バグの起票時に、UIレベルで「本来Aという振る舞いをすべきところ、Bという振る舞いをしている」ということは記載されています。
この場合、「『B』の原因となるレスポンスを自分のAPIが返している」かどうかの確認は、リクエストの確認の正しさに比べると比較的難易度が低い …気がします。 自分の経験的には。
各APIのレスポンスだけとりあえず並べてみる
レスポンスの正誤の判別は比較的簡単… という前提で、「バグ起票時に各APIのレスポンスが自動的に貼り付けられるツール」のようなものを想像してみます。
API | レスポンス |
---|---|
API 1 | |
API 2 | |
API 3 | |
API 4 |
※繰り返しになりますが、矢印のところには具体的なJSONが入るイメージです
システム構成が頭に入っていれば、以下のような図が見えるわけです。
※データがおかしい可能性もありますが、今は除外して考えます
API 3には絶対バグがないことがわかった!バンザイ! といいたいところなのですが、
UI, API 1, API 2, API 4 のどれもバグ持ちの可能性が消えていません。
これだけでは、あまり何かが解決しているようには思えません。
『複雑なドメインに泥臭く立ち向かう』JJUG CCC 2018 Fall #jjug_ccc
JJUG CCC 2018 Fallに参加し、@su_kun_1899 さんの 『複雑なドメインに泥臭く立ち向かう』というセッションに参加してまいりました。
法律という完全に外部要因で決まって変えることもできないものが要件に深く絡む世界で、
どのように立ち向かっているのか、というお話でした。
今一番読みたかった本が現れたかのように感じたセッション
どうやって複雑なドメインを理解し適切にコードに落とし込むか
というのは今現在の私の最大の関心事の一つでありながら、
もう一段自分のレベルを上げたいのだけれど何を勉強したら良いかわからないのが課題でした。
そんな中、今日のセッションは
- 自分が聞きたかった話を
- 理解できる言葉で
- 体系立てて
話してもらえたセッションでした。
更にいうと、一部の内容は、普段から自分がぼんやりと「思っていた*1」ことを、明確に言語化してもらった内容でした。
以下、私が感じたことが中心です。
順序も元の発表と異なります。ご了承ください。
共感したポイント
一本道を見つける
「変化は受け入れ、一本道に対して複雑さを足していくアプローチをとる」
そうなんですよね。いかに幹を見極め、枝葉と分離できるか。
いまから作ろうとしているプロダクトの背景にある真の目的はなんなのか。
それを見つけ出せることが重要なんだと思います。
モデルを抽出するするために ひたすら write & talk
とにかくなんでも良いから書き始めてみること。
脳内でウンウン考えているだけだと、自分自身が認識するのもなかなか難しい。
サービスクラスがユースケースを表す
すごくわかります。
個人的に、サービスクラスが数行でかけたら価値だと思っています。(というよりはサービスクラスがごちゃごちゃしたら負け)
taichiw.hatenablog.com
コードに書いて、動かして、初めて理解したと言える
今年の私の実体験。
単なるAPIだろうがんなんだろうが、実際に動くものを見て、触れて、初めて理解できることや気づける疑問が人間どうしてもあります。
更にこの時、クソコードだろうがなんだろうが、
とりあえずでも「動いて」、そして一応でも「読める」プログラムがあることによって、それまでに比べて格段に理解がはかどるようになります。
皆さんエンジニアですから。
(クソコードでもよいのですが、「適切な枠で切られている」ことはとっても大事。その中がクソな分には最悪差し替えれば良いのです)
気づかせてもらったこと
最低限のドメインナレッジの勉強は必要
実際の業務のロールプレイをしてみる
手書きで帳票を書く、という言うようなことをしているそうです