miso_soup3 Blog

主に ASP.NET 関連について書いています。

問題の沼から抜け出す方法

コードを書いていてハマることはよくあるのですが、とある方法を行うようにしてから、問題解決までの時間が短くなったと感じました。その方法を書きます。とはいっても、どれもよく言われることだと思います。

すぐに試せる環境を用意しておく

疑問に思ったときのために、1分以内にコードを書いて動かせる環境を立ち上げられるようにします。「〜 Playground」でググると言語毎にたくさんのツールを見つけられます。なるべく早く、自分が億劫と思わずに済む簡単な方法を見つけます。

例えば、自分は RxJS を試すために stackblitz.com のサイトをブックマークしています。RxJS の他に Angular、TypeScript も試せます。

f:id:miso_soup3:20200619171714p:plain

この方法を身につけるまでは、既存のプロジェクト(たとえば業務のプロジェクト)の中でコードを書いてデバッグしていたり、空のプロジェクトを動かしていたりしていました。それですと複数の要因があるので、本当に知りたい挙動を確かめられないことがあります。また、実行するまでの時間が遅いです。しかし、Playground のサイトでは瞬時に実行できますし、書いたコードの共有も簡単です。「次にこうするとどうなるんだろう?」という次の疑問もすぐに解決できます。書いたコードの URL をメモしておけば、いつか思い出したときに探し出すのも簡単です。他人に共有すれば、「それってこういうときどうなる?」という会話も生まれてさらに深堀できます。そして実行した後でようやく、公式ドキュメントの内容をちゃんと理解できます。

思い返せば、すごいエンジニアは「これってどうなりますか?」と話しかけた後、ものの数秒でコード例を提示していた気がします。

重要なのは、疑問に思ってから実行できるまでの時間を短くし、億劫にならないことだと思います。

作業ログの書き方を見直す

もし何か問題にハマってしまったときは、作業ログの書き方を変えます。試したこと、成功したこと、失敗したことを、全て書くようにします。

自分がハマっていたときの作業ログを思い出すと、単語だけを書いていたり、次にやること・調べたサイトのリンクを貼っていただけでした。解決できないのでテックリードに相談すると、「やったことは全て書いた方がいい」「条件を洗い出し、成功と失敗も全て書く」という旨のアドバイスをもらいました。このとき自分は「成功したことも書くのか」と思いました。その後、作業ログを Slack の自分宛ての DM から、Google Documents に変えました。成功したこと、考えたこと、疑問に思ったこと、書いたコードをストーリー仕立てで文章化しました。このときの気分はまるで、ゲームによくある日記を書く博士のようで、楽しい時間でした。やってからものの数十分で、成功する状態から失敗する状態の境界線を見つけられました。これは所謂ラバーダッキングの手法かと思います。それまでは、自分の作業ログの形が変だとは気付けませんでした。

作業ログについては、ひげぽんさんの 第9回 ログのすすめ:継続は力なり―大器晩成エンジニアを目指して|gihyo.jp … 技術評論社 の記事が好きです。

ミニマムプロジェクトを作成する

自分が触っているフレームワークのミニマムなプロジェクトはすぐに作成できるようにしておきます。Docker, docker-compose, Angular, .NET Core などなどいろいろなフレームワークがありますが、そのミニマムな環境を用意することに躊躇しないことです。クロスプラットフォームであれば、Mac, Windows, Linux のどの環境でも作成します。思えば自分は、開発マシン以外の環境でミニマムプロジェクトを作成するのを避けていて、Google 上で解決方法を探していたのですが、すごいエンジニアは数分でミニマムプロジェクトを用意して解決していました。