テストコードで指摘されたこと仕事での良かった点
こんばんは。kouheiです。どうでもいい話ですが、家のMacbookが立ち上げたときに必ずWifi切り直さないとつながってくれません。中古で古いから限界なのかな。。。サンタさんこないかな。。。
平日は仕事の振り返りとか勉強した内容のまとめが多くなりそうです。今日も仕事の振り返りです。
テストコードで指摘されたこと
実際のコードは載せられませんが、以下のようなテストコードを記載しました。
it 'ユーザーのデータが取得できること' do
expect(json['name']).to eq 'たなかたろう'
end
要するに eq のデータをそのまま表示してみました。このようにした理由としてテストコードは「DRY」より「わかりやすいほうが良い」という記事を見たからです。参考資料
こちらの記事を私なりに解釈して実装してみたのですが、「分かりづらい」という指摘でした。詳細としては「コード読んでいくと突然 たなかたろう が出てきてマジックナンバーになっている」とのこと。
上司からも、値を直書きするならその値が確実に入っていることをコードでわかるようにしたほうが良いとのこと。
let(:params) { { prams: { name: 'たなかたろう' } } }
it 'ユーザーのデータが取得できること' do
expect(json['name']).to eq 'たなかたろう'
end
適当だけどもし直書きするならこのくらい冗長に書いたほうが良いとのことでした。
確かに、わかりやすさが自分に向いてしまって自分にしかわからないコードになってしまっていた。
他人が読んでわかりやすいコードが課題だな〜。変なことしないで素直に書いてみようと思います。
今日の良かった点
本日の仕事中の目標として「他人から意見をもらったら、自分の意見を理由を添えて言う」という目標にしていました。
結論としては目標を行うこと出来ました。ですが、テキストベースで意見を言っていたのですが、送信するまでに時間がかかってしまいました。
理由として、言葉尻とか気にしすぎて送信までに時間を要してしまったことが原因に挙げられます。ここが反省点ですね。
明日はどうするか
一度に全文送ろうとすると長文になってしまい受け手側も読むの負担になってしまうので、短文を意識。チームの方は言葉尻を攻めるような人はいないからラフにテキストベースでコミュニケーション取れるようにする。
この記事が気に入ったらサポートをしてみませんか?