かずきのBlog@hatena

すきな言語は C# + XAML の組み合わせ。Azure Functions も好き。最近は Go 言語勉強中。日本マイクロソフトで働いていますが、ここに書いていることは個人的なメモなので会社の公式見解ではありません。

問題調査でドツボにはまった状態から抜け出す技術?というか気にしてるところ

なんとなく、牛尾さんの以下の記事を見て自分が気を付けてることをメモしておこうかなと思ったのでメモ。

qiita.com

まずハマらないために

何か新しいことをやるときは、それだけにフォーカス出来る状態で練習を一度する

既存のプログラムとかに〇〇を組み込もう!!というときは〇〇の中で使いそうなものを当たり前ですが事前にきちんと勉強する時間をとるとトータルで早く終わることが多いです。 きちんと勉強しなくても、クイックスタートを見ながら自分のプロジェクトに追加とかもできますが、これはうまくいくと一番最速で取り込めるけど、うまくいかなかったときに正しい最短手順を知らない状態なので、あれが足りないのかなぁ?これが足りないのかなぁ?あれ?さっき足したあれって実はいらないのかなぁ?とか試行錯誤が入ると、経験的にちゃんと学習して取り組んだほうが最終的には早くなると思ってます。

背伸びはなるべくしない

何かやろうとしてわからないときは、焦らずわからないものに関して上でかいた、それだけにフォーカス出来るようなかき捨てプログラムを書いて足場を固めてから、その上で本当にやりたいことに取り組む。

これは、やってるときりがないというのはあるけど、自分が使いたいものに直接関連してるものへの理解度は、ハマらない確率を上げる重要な要素だと思ってます。 なので、背伸びしなくても出来るようにまわりの足場はきっちり固めて土台を積み上げて取り組もう。

ブログを書く

「〇〇について完全に理解した」と思ったり、そこに少しでも近いづいたらブログに書く。 数日~数年たって「〇〇について完全に忘れた」状態になっている将来の自分が読んで喜ぶようなものを書いておくとはかどる。

ついでに、ほかの人にも喜ばれる。最高。

ハマったときは

ここは大丈夫だろうという思い込みを無くす

ハマってるときは何か間違えてるのだけど、無意識に「〇〇は大丈夫なはず」だという思い込みで本当に基本的な部分をすっ飛ばして応用的な部分にフォーカスしていることが多いなぁと自分では思ってます。

なので、ハマってる人に相談されたときはハマってる内容を聞いたら一つずつ、そこに至るまでの手順を遡って確認するようにしています。 そうすると大体、このライブラリ使ってエラーになってるからコードが何処か間違えてるという状態から、実はライブラリをつかうための依存関係がきちんと定義されていないとか、そういう所で問題が見つかったりします。

ハマってる時は、大体思い込みや無意識で確認を飛ばしてる場所に間違いがあることがあるので、人に相談されたらその人がフォーカスしてない部分について確認するようにしようと思ってます。

ハマらないために書いたことをやる

「ハマらないために」の部分で書いた内容をやってない場合はやります。 結果として、ハマらず出来るようになることもある。

相談する

自分でどうしても解決できないことは、自分の頭の中で気づけない部分でハマってるので別の視点で見てくれる人に相談しよう。 そうすると、きっと自分がやってるちょっとしたミスに気付いてくれると思う。

まとめ

思ったことをつらつらと書いただけですが、なんとなく自分はこうしてるかなぁということを過去に書いたことが無かった気がしたのでメモがてら。

基本大事ですよね。