楽したいソフトウェアエンジニア

週一でなんか書きたい

2023-09-25 週 狭い範囲でコーディング

状況

タスクが落ち着いてきたので一つのライブラリアップデートのタスクをした。影響範囲は狭く、テストがなかったのでテストを一つ書いた。ライブラリアップデートの修正は同じようなbuilder呼び出しで冗長だったが一つのヘルパ関数にまとめた。

結果

精神衛生上、良いタスクの進め方だと思った。一度に気にする範囲は狭く確信を持って消化できた。

原因?

長く続いていたフレームワーク更新の作業の反省で、状況把握>テスト作成>修正、という流れで作業が終わった後にテストで補強されていて欲しいと思ったのでこういう作業を意識した。というか普段の機能追加タスクであればできていたことを久しぶりにやった。

感想

テストを書きながらできないような作業は「自分の手には余る」という感覚がある。今後はタスクを小さくするのを怠らないようにしたい。それをするまでが着手準備。

 

20230918週 余裕がない?

状況

長く続いていたフレームワークのバージョンアップが終わり開発のメインブランチにマージするためのPRレビューを依頼した。

結果

とりあえずで修正した箇所についてコメントがあった。自分では判断がつかない箇所だったので有識者に判断を求めた。

最後にチーム外の意見が必要になってしまった。場合によっては時間がかかる。

原因?

該当箇所を修正した当時も、最終的なレビューの今回も自己レビーはしていなかった。

感想

他人の成果物として自己レビーする。昨日の自分や30分前の自分=他人、と考える。その余裕がない時はヘルプを頼もう。

ドキュメント。。。

最近会社で「ドキュメント作ろう」みたいな動きがあるのですが、個人的にはなんだか拒絶反応みたいなのが出てしまって困ってます。

原因としては多分

  • プロジェクト毎の要不要とか考えてなさそう(フォーマットだけはちゃんと1パターンだけ決めてる) -> 意味ないケースが増えて形骸化しそう
  • 作るのが目的化してる -> ドキュメント自体は何かを達成する手段では?

あたりですかね

実際どうなるかはやってみないとわからないと思うのですが、ドキュメント自体、効果が出るのは作ってから少し後になることが多くなるみたいですし、そうなると「この取り組みがダメ」というのが分かるのも少し後になるんですかね。

と考えるととりあえずやってあげようになっちゃうかな。。。

あんまりうるさい奴と思われるのも面倒だし

話して決めることは苦手

苦もなく解決した、と思ったら実はそうではなかった、というお話です。

  • Aが最終目的
  • そのためにBであることが望ましそう
  • Bがなくなる場合にCになりそうなんだけどCの詳細が分からない

という状態の時にCついて確認できそうなMTGがありました。

事前の認識ではBはこれから調整が必要で一応Cになった場合にどういうインパクトがあるか分からない、という状態でした。で、MTGが進んでどうやらBを認識している人がいてそうなるように調整中らしい、ということが分かりました。

で、自分はどうなったかというとその情報に飛びついてCの確認をしようという発想がどこかに行ってしまいました。でもよく考えたらBの確度はまだそんなに高いとは言えなくて「Bじゃないとどうなるの?」という質問が来たときに答えられなくて話が止まりそうという状態でした。

Cが調べる系なら喜んで調べたくらいのこともあったと思いますが、人の作業で色々聞いて把握しなきゃいけないことだったからつい避けてしまったのもある気がします。

人と認識合わせながら進めていくとか、、、これの練習ってあるのかな

  • pull request でこうしたら?じゃなくてまずは相手の意図を確認する、とか
  • デイリー、レトロスペクティブあたりでよく意味が分からなかった部分を聞いてみるとか

あたりかな

こういう人と認識合わせる系も少しずつ、なんだろうな

GoogleでなくChatGPTで調べ物をするメリット

今週は流行りのChatGPTで色々調べ物をしてみました。感触として良いねと思いましたが何が良いのか考えてみました。

ググるのと何が違う?

プログラマー脳では文法などは毎回調べずにフラッシュカードを使って覚えるのが良いと書いてありました。

その理由のひとつにコーディング中にGoogleなどで調べると別のこと(SNSなど)に気を取られて(割り込まれて)コーディングに復帰するまで時間がかかってしまうというものがありました。

その観点で言うとChatGPTでの調べ物は色々なサイトに行ったりしないのでそういう懸念は少ないと思います。

あと、メンバーに「あれなんだっけ?」と聞く感じで聞けるのも割り込みが少なくなりそうな点かなと思いました。

記憶にも良さそう

さらに、調べたことの履歴が勝手に残るので後でフラッシュカードに記録しやすいのも良いですね。

今週は漫然と使っていましたがもうちょっとこの辺りを意識して使ってみたいと思います。

チームが変わってモヤモヤ

チームが変わりました。

自分はリーダーなのでメンバーが変わった感じです。感覚が合うな、と思っていたメンバーとは離れて残ったのはあんまり感覚が合わないなと思っていたメンバーは引き続き同じチームになっています。それでなんだかなぁ、とモヤモヤしていて考え方を変えればモヤモヤがなくなるかなと考えていましたがそういうのは無理だなと考え直しました。

引き続き同じチームになるメンバーには悪いけどその人の書くコードが割とアンチパターン的になることが多いことを逆手に取ればいいのかと気づきました。具体的にはその人の書いたコードをレビューする時に不吉な匂いを感じたらどこかにそういう書き方をするのはいけない、と書いてないかなと探すことにしました。そうしてそのコードを失敗例として扱ってそこから学ぶ材料にすれば良いのか、と。XPでも正しいやり方がわからなければ失敗して学ぼうみたいなことが書いてあると思うのでそういうイメージです。

自分の失敗は気づきにくいけど他人の失敗には目ざといという傾向はあるような気がしますし、個人としては大分前向きに捉え方が変わったんじゃ?と思いました。そのメンバーにはなんかゴメンですが、まあ仕方ないです。表には出さないし。というかレビュー指摘もちゃんと書籍などをあたる分丁寧になる気がするし win win な気もします。 (そうなるといいな)

コードを読むことよりも書くことを考えてしまう

コードレビューとかしていて複雑なコードを読んでいる時に、「自分だったらどう書くか」を考えちゃいますね。

コードリーディングの練習としてはそんなことはどうでも良くて、自分は何故分かりづらさを感じているか、分かった箇所は何故わかったのか、とかを考えた方が良いのかなと思いました。

コードを読む苦痛が減ると仕事の苦痛も減る気がするので読む練習はしたいですね。