蚊帳の中の日記

ゆるく生きてます

ペアプロをしてもらって自己の問題のボトルネックがわかってきた

開発 エモい話 ペアプロ

ペアプロをしてもらったのだが、その時の先輩エンジニアにフィードバックを色々問題の指摘やフィードバックをもらって自分の課題を浮き彫りになって面白かったので、鉄は暑いうちに打て精神でブログに書き留めておきたくなった。 自分の開発の仕方や思考プロセスをレビューしてもらって、フィードバックをもらえる機会はなかなか少ないと思うので、今後もこれらを意識して問題克服に努めた（←具体的にどうやって？？）。

思考系

  • どんな粒度で考えれば良いか、思考の粒度や問題の切り出しが自分でできていなかった。
  • ある問題点を見つけて解決する最中に、他の問題点も見つけてそちらも考え出し、色々なことを考えながら進めて混乱してしまうケースが多々ある。問題や思考の粒度を小さく切り分けて、「いま自分はどの問題について取り組んでいるのか？もしくは取り組むべきなのか」をよく確認する癖をつける（問題のフォーカス）。人間の考えられる量には限界があるので。
  • 思考を分離して考える。上の項目とも近いものがあるが、今自分はどの問題を解決しようとしているのか？？他の問題も持ち込んでいないかよく考える。そしてその問題について思考を集中する。思考を集中できるので、気持ちも楽になる。実装でも一部に集中できれば良さそう。一部修正して、その一部のRspecだけ通すように務める。全体のスペックや実装を見るのはその後。そのほうが気持ちが楽になる。
  • 説明などをする時、考える事と文章を組み立てることが一緒になってしまって、結果的に読み手が分かりづらい文章になっていることが多いので、一緒にやらない。コツとしては事実ややったことを羅列して、その後に論理的にくっつけると、思考も分けられて良い。良いコミットメッセージや説明力向上につながるはず。
  • 何が問題なのか？わからなくなったら、書き出してみるのが良い！頭の中で考えるだけでは整理できない。少なくとも自分はそこまで器用なことはできないことがわかった。
  • 図解などは思考や理解の助けになる
  • 悩みすぎずに休憩やリフレッシュを入れることは良いこと。煮詰まりすぎずに、５分とか考えて途方に暮れてしまったら、相談したり、リフレッシュした利するのが良さそう。
  • 言語化し説明できることが、自分の理解の基準とできるだろう。この基準は自分でも一つの指標として持っておくと良いだろう。

開発の進め方系

  • Time.zon.atってどんな形式の日時が返ってくるんだっけ？？となった時に、「Time.zon.at」の用法を覚えなきゃ！ではなく、この処理は気をつけないことがあったな！！！と思い出す癖をつける。詳細な処理などはgoogle先生に聞いてみるのが良い。人間の覚えられることなんて限られているので。
  • typoすることが多いので、変数名などをコピペや補完機能を使って余計なミスを減らそう！努力ではなく、方法でカバーする。
  • 自分がなぜそういう実装をしたのか”結論”を自分の中に落とし込む。落とし込む過程で根拠があることが重要。根拠が会って結論が落とし込めたら、それらを文章に組み立てたり、説明する（説明責任）。説明できたことによって、聞き手が「なぜ？」と考えることが少なくなる。この根拠・理由を言わずに結論だけ話しても「なぜ？」と聞き返され、最悪別の議論に話がずれ込むこともある。”速”を出した開発をするには、そのあたりのコミュニケーションの省略にもつながるので説明責任を果たすことは大事なこと。コミットメッセージに説明責任があればレビュワーは納得感がある。
  • 一発で覚える癖は大事そう。その場でできる限り理解するクセをつける。
  • 木を見て森をみず状態にならないこと。開発のコツとして、まず実装の全体を見て、どういった処理フローになるのか想像し俯瞰する。そうすると実装のイメージも付きやすくなってくる。特に処理が複雑なものについては有効かも。「クラス名どうするとか？？」とか細かいところにフォーカスする前に、全体を見渡すことは特に設計でも重要。大きい粒度で考えて、小さくしていく問考え方にも近い。
  • 細かいところに気が行き過ぎるのは設計の段階では良くないかも。細かいところは実装段階で。
  • 「エラーに出くわす　→　エラーを見る　→　ググる」はあまり良くない。「エラーに出くわす　→　エラーを見る（場合によってはstacktraceも読みとく）　→　ドキュメントやコード・テストを見る　→　それでもわからなければググる」。いきなりググるのは課題や問題を把握せずにgoogle先生に丸投げしている。思考放棄。処理は大体コードに落とし込まれているはずなので、ドキュメントやコードを見て仕様を確認するのが、正しい対策や対応を身につける近道。
  • ドキュメント英語は辛いけど見ましょうよ！ね！（問題を細分化→何がわからないのか出来るだけ切り出す→ドキュメントやソースを見に行く→それでもわからなければググる）
  • あとドキュメントもおかしい場合は大いにある。PRを出そう！くらいの気持ちで読んで見る。
  • Rspecは先にテストしたいことをcontextやdescribeから書いて、そのあとに中身を書いてみる！何をテストしたいのかを考えないといけない。そしてテストは仕様書なので、そこがおかしいのは良くない。読み手が理解しづらいものになる。
  • ペアプロみたいに話しながら進められると、思考の整理になるので良い。
  • 変数に何が入っているとか、ハッシュの構造はどうなっているとか考えてもしょうがなかったら、考えるのめんどくさくなってきたらbinding.pryを使って見てみる！

雑なので、個々についてはまた別の記事で詳細を書こうと思う。