困難は分割せよ(diffを減らしてmergeしていく話)
超小規模エンジニアチーム*1とはいえ、ときにはでかいリリースの必要性に迫られることがあります。 今回取り組んだ機能実装では、3つのmigration、4つのcontrolller、たくさんのviewとテストのファイルを新規作成しました。
ぼっちにしてはめちゃくちゃでかい機能リリースが控えていて胃がｷﾘｷﾘｷﾘｷﾘ
— べーた (@beta_chelsea) 2018年10月23日
ぼっちでやるにあたって、でかいプルリクはでかいというだけでリスクです。見直しにも集中力が必要でしんどいです。 ちょっとでもまともにリリースするため、自分は全体像が完成したら、切り出せそうなところを抽出して先にリリースするようにしています。困難は分割せよという言葉が合いそうだなぁと思います。
多種多様な意見がありますし、将来の自分が見たら考えが変わっていて後ろから刺される可能性もありますが、現時点での自分のやり方を挙げてみます。
まず master ブランチからfeatureブランチを生やします。featureブランチを育てるだけ育てます。このときcommit名とかにはあんまり気を配りません。とにかく80~90%くらいの完成度を目指してcommitを積みまくります。 ほぼほぼ完成に近づいたら全体を眺めます。全体の中から既存の機能に対する変更や、単体で更新できそうな機能(child_a, child_bとします)を考えます。
masterブランチから改めてchild_a, child_bを生やし、抽出できる機能を移植します。
移植には $ git checkout ブランチ -- ファイル名 を使うと便利です。
$ git checkout -b feature master $ git commit -m "バリバリ開発" ... $ git checkout -b child_a master こうするとfeatureブランチから app/models/hoge.rb をとってこれる。 とってきたデータはステージされている状態となっている。 $ git checkout feature -- app/models/hoge.rb $ git status On branch feature Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: app/models/hoge.rb $ git commit -m "hoge.rbだけ取り出して先にリリースするぞ"
この時点でchild_aのdiffを眺めて、もうちょっと良くできないか考えます。 大抵の場合、膨れ上がったfeatureブランチでは見つからなかった問題点や不足していたテストなどに気づき、この時点で手を入れます。 その後、納得できたらmasterに先にmergeします。
$ git commit -m "さらにリファクタしたぞ" $ git checkout master $ git merge child_a
ここで child_a は feature に含まれるものよりもだいぶ変わっている状態です。 変更を取り込むとき、merge派とrebase派がいるような気がするんですが、自分はrebase派です。 何回も繰り返してコンフリクトを修正するのが面倒なので、自分はfeature ブランチに積み上がったコミット群をひとまとめにしてからmasterにrebaseします。
# featureに移動して10件のcommitをひとまとめにしてしまう $ git checkout feature $ git rebase -i HEAD~10 # 全部squashする。歴史はあとで改変する。 # ひとつにまとまったらmasterへrebaseする $ git rebase master # おそらくコンフリクトするので、うまく修正する。
これをfeatureブランチを機能が分解できなくなるまで繰り返し、最後にfeatureブランチの歴史を整えなおして全機能のリリースが完了します。
一通り書き出したけどあんまり分かりやすいとは言えない説明になった。 うーん、図解とかが入れば良かったかもしれない。 Gitで歴史をどうにかするごにょごにょは別途記事にしようかな。
超細かい作業ログをとっている話
1ヶ月で終わると見込んでいた仕事が終わらなかったのを機に、いったい自分は仕事として8時間をどんな風に使っているのかを考え直すことにした。 本当はいい感じのツールでかっこよく整理できたらよかったのだが、自分が求めるものにジャストフィットするものが見つからなかったため、Spreadsheetに頼った。
求めていた機能として、
- 突発的に発生したタスクを書き留めることができる
- タスクに何時間かかったのかを振り返りできる
- タスクの順序をいつでも入れ替えることができる
というのがあるが、うまくSpreadsheet でカバーできてしまったので、ここ1ヶ月はこのまま運用している。
決まったことを決まったようにこなせる日はなかなか無い。都度、新しく発生した問題やら何やらを片付けつつメインの開発に取り組むという形で進めている。何時間で終わらせるぞ！という目標のあるものは見積もり時間項目に値が入るが、想定できないものや突発的タスクについては入っていない。 記録をつけたことで、自分としては次のような見直しができた。
- 平均して毎日3時間は雑務をこなしている。
- 月に3~5日はまったくコードが書けない日が発生する。
- ...ということを見越して、機能の完成時期を予想する。
あとログを書き込むようになって、作業に詰まったときにどれくらい時間を使ってしまったのかを時間単位で把握できるようになった。結果、諦めたり方針を変えたりするきっかけ作りとしても効いていると思う。
GitHubのソースコード参照リンクを残すときはmasterを避ける
tl;dr
GitHub参考URLをmasterを参照したものにしていると数年後に見直したときに泣くぞ！気をつけろ！(経験談)
こんなときあるよね
GitHubを使っているときなど、ソースコードへの参照URLを残したい場合がある。 このとき、リポジトリからそのまま素直に目的のコードを探しにいき、特定の行番号をクリックすると次のようなURLとなる。 (pluckが好きなのでその部分の実装のリンクを貼ってみる。) https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/enumerable.rb#L124
しかしこのURLには問題がある。 ソースコードは生き物みたいなものなので、masterは日々更新されてしまう。 数ヶ月経った後のこのファイルの124行目は果たしてpluckの実装を指しているのだろうか？ これを誰かが読んでいるときは、すでに全く別の行だか空行だかを指しているかもしれない。 せっかく参考にと残したURLが別の場所を指していては意味がない。
手段1: tagの指定
将来的にも確実に意図した指定を残す方法として、branchやtagを指定してから行番号リンクを獲得するようにしている。 自分としてはどちらかというとtagのほうがバージョン指定がURLに入るのでわかりやすいかなと感じている。 (あっ、v5.2.1の時点ではpluckは114行目なんですね...) https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/enumerable.rb#L114
手段2: Copy permalink
特にバージョン指定も関係ない場合、行を選んだ時の左側の「…」を押すと手っ取り早くCopy permalinkができる。 このときURLは次のようになる。 https://github.com/rails/rails/blob/5431e17733366da1fd10f2cd3039d66a56012683/activesupport/lib/active_support/core_ext/enumerable.rb#L124
おまけ
1行選択したあと、Shiftを押しながら別の行を選ぶと、範囲指定ができる。URLとしては L数字 を - で繋げればよい。
https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/enumerable.rb#L107-L121
英語のcommitメッセージをそれっぽくするためにやっていること
自分がいま管理しているリポジトリは引き継ぎしたものだ。
元々commitメッセージを英語で書く方針で始まったようなので、自分もそれを拙いながらも継続している。
とはいえ母国語でないので時々怪しい文章を書いてしまうし、レビューしてくれるひともいない*1。
そんな状況でもどうにか将来 git log を叩いた人へ何が起こっていたのか伝わるように頑張っている。
現時点で、少しでもマシな英語のcommitメッセージを生成するためには何をしているのかを書いてみる。
動詞で始める
Update ~ 、 Remove ~ とか動詞から始める。
これは色んなところで良く言われるコツらしいので鉄板なのではないだろうか。
Git でより良いコミットメッセージを書く方法 - yu8mada
gitにおけるコミットログ/メッセージ例文集100
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
Google翻訳に意味が通じるか聞いてみる
それっぽく書いてみたら、とりあえずGoogle翻訳にぶち込んで英->日翻訳で意味が通じるかどうかチェックする。 変な意味になってしまっていたら再考する。
Grammarlyに文法チェックを頼む
ただ、Google翻訳は優しすぎて、適当な文法でもそれらしく翻訳してくれてしまう。 文法がおかしいかどうか、Grammarlyにぺッと貼ってチェックしてもらっている。
Grammarly: Free Writing Assistant 英語の文法チェックに！秀逸な英文校正ツール「Grammarly（グラマリー）」の使い方 - Life is colourful.
課金するともっと良い表現などを教えてくれるようだが、無料範囲でも文法上まずいところを指摘してくれる機能がある。 GoogleChrome向けのアドオンもある。アドオンを入れておくと閲覧中のページで英文を入力したときにすぐチェックしてくれる。 Google翻訳上でもアドオンが有効になっているとすぐさま指摘を入れてくれる。
冠詞の a か an かとか The とか複数形にすべきかどうかとか三人称単数とか、英文において気にするべきところは色々あるが、Grammarlyがまるっと面倒をみてくれるのでとても助かっている。
ちなみに
ちなみに、個人プロジェクトだったら、自分は速度/理解度優先で日本語でcommitメッセージ書くと思う。 特に強いこだわりがないとき、これまでの例に倣っていくのが最適かなぁと思っている。
*1:ぼっちエンジニアなので。メンバー鋭意捜索中。
午後のカフェオレの習慣
毎朝、出勤前にコンビニでカフェオレを買っている。
午後3時前くらいに、ほんのり眠たい気分がやってくるので、そのタイミングで冷蔵庫からカフェオレを取り出してきて飲んでいる。 飲むと、なんとなく頭がすっきりして、体感としては集中力を保って仕事を続けることができる。
社会人なりたての時に、仕事中にコーヒーを3杯飲んだことがある。その日の夜、ひどい吐き気とめまいに襲われて大変な思いをした。その体験から、特に検査とかで測ったことはないが、自分はあんまりカフェインに強くないんだろうという自覚を持っている。
カフェオレ300mlくらいで元気になっている自分のケースについてはプラシーボ効果なのかもしれないけど、なぜカフェインを摂取すると集中できると言われているのかのメカニズムを知らないことに気づいた。 今の世はちょっとした「何故？」にはGoogle先生がさっと答えをくれる。 SEOが強いページをいくつか適当に斜め読みしたら次のことがわかった。
- 眠気を促す「アデノシン」を受け付けないように防いでいる
- コーヒー100ml につき 60mg 含まれる
- (カフェオレ300mlの半分がコーヒーだとすると、自分はいつもカフェイン90mg摂っている?)
- 適量は1日300mgくらい(もちろん人による)
- 作用は30分後から4～6時間続く
- 飲み続けていると耐性がつく
斜め読み結果を見るに、意外と午後のカフェオレ習慣はそれなりに理に適っているのではないかなと思えてきた。
ところで「街」の雨宮桂馬をふと思い出して雪印コーヒー牛乳を買う日もたまにある*1のだが、カフェオレはコーヒーと牛乳が1:1、コーヒー牛乳は主体が牛乳でコーヒーはちょっとだけ入っている、と言う違いがあるらしい。自分の仕事の供にはカフェオレのほうがちょうど良いようだ。 けふも元気だカフェオレがうまい。
参考URL
- カフェイン - Wikipedia
- カフェインが眠気を覚ます仕組みと依存性の話 - ログミー[o_O]
- カフェインは結局、ヒトにどんな作用を及ぼしている？ 専門書の著者に聞いてみた | ライフハッカー［日本版］
- カフェインによる覚醒の仕組み「ノルアドレナリン」の生成を促す - ライブドアニュース
- カフェインのとり方｜身体に及ぼす影響とは？ | フミナーズ
- 知っていますか？ 自分のカフェインの「安全量」｜ヘルスＵＰ｜NIKKEI STYLE
- コーヒー牛乳とカフェオレの違い | Coffeemecca
- カフェオレとコーヒー牛乳の違い！ダイエットに最適なのはどっち？ | キュリエスト
*1:コンビニにあるラインナップのなかで、サイズ感とお値段的にグリコのカフェオレが一番リーズナブルだった
オフィスってすごいからホントマジで
コワーキングスペースを仕事場として利用する生活を約2年ほど続けていたのですが、2ヶ月ほど前のある日、とうとうオフィスが爆誕してメンバー全員がそこに通うようになりました。コワーキングスペースでも、スタッフの方々が大変よくしてくださり、快適に過ごせていました。しかしやはりオフィスがあるということの優位性は揺るぎないということをしみじみと感じております。 この感動が新鮮なうちに、コワーキングスペースとオフィスの違いを書き留めておこうと思います。
コワーキングスペース
メリット
- 受付の人にお客さんの一次受けをしてもらえる
- いろんな人のいろんな取り組みを目端に知ることができる
- 気分で座る場所を変更できる（フリーアドレス）
- 掃除が行き届いていて快適
- 観葉植物が元気
- 基本的な文房具類を借りることができた、朱肉とか。
- とにかくリーズナブル
デメリット
- 社外の人が常にいる空間なので社外秘事項の取り扱いに余計注意が必要
- サブディスプレイを置いておけない（ギリギリロッカーに入るサイズのものを都度出し入れして使う人もいる）
- コップなど私物を置いておけない
- 会社の物品も置いておけない
- ミーティングスペースが争奪戦、追加料金が必要な場合もある
- ホワイトボードも争奪戦
オフィス
メリット
- 身内しかいないので喋る内容や画面表示に神経を尖らせなくてもよい
- サブディスプレイを置きっぱなしでよい
- 充電器(私物)を置いていってよい
- ケーブル類(私物)を置いていってよい
- 自分で選んだ良さげな椅子に座れる
- お土産のおやつを堂々と置いておける
- ミーティングをする机に困らない
- ホワイトボードを消したくなければしばらくそのままにしておける
- 好きなBGMを流してよい
デメリット
- いきなり飛び込み営業(?)の人がやってくる
- ひきこもると外界交流を忘れがち*1
- 掃除は自分たちでする必要がある(ルンバが導入された)
- 観葉植物も自分たちでお世話する必要がある
- こまごまとした棚、文房具は自分たちで揃える必要がある
- 維持費めっっっちゃ高価
まとめ
会社には当然オフィスがあって、オフィスにはいろんな設備があるのが当然だと思っていた時代が自分にもあった気がします。 自分はいま、自社サービスを生かしていくために日々キーボードをカタカタいわせていますが、同時に社内メンバーだけで占有できているこの快適なオフィスという空間を維持するためにも頑張らねばという気持ちもあります。 オフィスってすごい。
*1:これは個人的な性質なので治していきたい、勉強会行ったりとか
