タピオカは飲みたい、でも列にはならびたくない、たいがーです。

カエルの卵みたいな見た目で飲んだことがないということをよく聞きますが、意外とおいしいので飲んでみていただきたいです…

今朝、通勤中に新しいタピオカドリンク屋さんを発見しました。どうやら昨日オープンだったそうで、お昼休みには少し列ができていて、断念しました。帰り道によって帰るか迷っています。飲みたい。

前回の続きから進めていきます。前回は一度packageというフォルダを作成しましたが、今回は作業していたディレクトリの直下で作成してみました。うまくSlackに通知が来たので、プルリクエストを出していきます。

いざ、プルリクエストを出す際、気になる点がありました。

Gitでの書き方の諸々

プルリクエストのコメントの書き方

今回、requestsとpyyamlをインストールし、それらのフォルダとスクリプト、YAMLファイルをzip化して作業を進めていきます。

その説明をどこかに記載しなければ、テストをしてくださる方が、どのようにしたらテストを行うことができるのかがわかりません。そこで、手順をコメントで記入しておけばいいと教えていただきました。あとから自分が見返しても分かりやすいですよね。

コミットメッセージはどこを、なぜ変えたか

一部動かなかったコードを指摘していただいたものを修正し、動くようになったので、"動くようになりました"というコミットメッセージを行いました。"何が動くようになったのかが、あとから見てわかりにくいかも"と指摘していただいたのですが、どのように書いたらいいのだろうかと迷いました。すると、

1行目は(プロジェクトやチームのスタイルに応じた視点や記法にする前提で)「動くようにした」という意味合いで構わないかと思います。2行目以降で、「変更前はなぜ動かなかったのか」と「何をどう変えて動くようにしたのか」が、後から誰が読んでもわかるように記述してあるとベストかなと個人的には思います。

とコメントしていただきました。そもそもコミットメッセージが複数行書けることを知らなかったので、その時点から驚きました。

どのように変えたのか、ではなくどう変わったのか、なぜ変えたのかを意識して書いていきたいと思います。5W1Hみたいだなと、少し中学の英語を思い出して、懐かしい気持ちになりました。

コミットメッセージも含めて、あとから見る人から分かりやすいようにコメントを記入することは大切です。どのように書けば、相手が一番求めているものに近づくのかという点は難しいところです。

Gitに上げる設定データの名前

設定データの名前を○○_config.ymlと設定した際、サンプルデータを雑な名前で付けてしまいがちでした。

sample_○○_config.ymlという名前にすることで、正しいファイル名を確認するためにコードを読まなくて済みます。とのことでした。

人と一緒に動いているということへの意識や気遣いを忘れがちなので、そのあたりも意識しながらしなければいけないと最近実感しています。

セカンドシーズンが終了しました

一度、作業の終わりの目安が付いたということで、振り返りをしました。前回の振り返りはなんと3月。たった3か月しか経っていないことに驚きました。

前回の振り返りから、EC2インスタンスの起動/停止を行ったり、様々なAPIを使ったり、STS対応を行ったりなど、色々なスクリプトを作成しました。また、新卒の方へのインタビューも行いました。

最近、よく感じているのは、得意とは言えませんが、何か作るのが楽しい！！ということです。解けないときはモヤモヤすることも多いのですが、解けたときにその分うれしくなります。

サードシーズンは全く違うものを制作させて頂く予定なので、体験談を楽しみにお待ちください！！