Yuki's Tech Blog

仕事で得た知見や勉強した技術を書きます。

DAY4(2022 6/6) ~ DAY8(2022 6/10)

モニタースタンド


DAY4(2022 6/6)

  • ある機能Bの作成をした。作成する中でgemのエラーが発生したので、解決するのにすごい時間がかかった。Railsのエラーの中でインフラ関連のエラーやgem関連のエラーは解決に時間がかかるので、どうにかしたい。よく使うgemは、徹底的に使いこなせるようになるべきだと感じた。

  • ある機能Bのレビューまで完了した。

  • 30分集中して仕事するを繰り返すのが良いと、何かの本で読んだので、この日以降、実行してみた。気持ち集中力が上がった気がする。

  • 大きいタスクを渡されると、色々やらないといけなくて、テンパって結果的に全然進まないことがある。何をすれば良いか分からない感じ。なので、タスクをめっちゃ小さく分解して、小さいタスクを集中して順番にこなすようにした。

DAY5(2022 6/7)

  • ある機能Cの作成をした。50%くらい完成した。いつからか分からないが、機能作成する場合、まずは既存の似たような実装のコードを見たり、Qiitaを検索して見ていた。良さそうな実装があったらコピーして値を変えたりしていた。自分のやり方をCEOに話すと、「まずは何も見ないで自分で考えて実装してみた方が、エンジニアとして成長するよ。今のやり方だと、新しい機能を作る時に作れなくなる。いくらでも失敗して良いし、会社の経営は考えなくて良いから、自分のスキルを磨いてほしい。」と助言をいただきました。なので、この日以降、フルスクラッチで実装しようと決心する。本当に分からなかったら質問するようにする。(ある程度できるようになったら、既存の実装の汎用的なコンポーネントを使ったりすることにした)。まずは実装方針をノートに書くようにした。

DAY6(2022 6/8)

  • 引き続き機能Cの実装をする。フルスクラッチで実装したことによって、自分が思っている以上にReact Hook FormやMUI等のライブラリの使い方が分かっていないことを知る。なので、この日はひたすらドキュメントを読んでいた。

  • 投資していただいているVCの新入社員向けの交流会に行った。自分と同じように未経験からエンジニアになった方がいた。親近感が沸いたので、気づいたらその人とラーメンを食べに行く約束をしていた笑。会社が3人しかいないので、このような横のつながりを提供していただいてすごい嬉しいです。

DAY7(2022 6/9)

  • 引き続き機能Cの実装をする。前日にドキュメントを読みまくったおかげで、スラスラとコードを書くことができた。この日で80%くらい完了した。

  • 入社祝いとして、CTOからモニタースタンドをいただきました。すごい見やすくなって、姿勢も良くなり嬉しかったです。

DAY8(2022 6/10)

  • 機能Cの実装がようやく完了する。完了したときは、めちゃくちゃ嬉しかった。レビューを受けたので、レビューを修正した。来週の月曜にレビューを再度頂くかもしれない。

  • clipyのスニペット機能を知る。今までなんで使ってなかったんだろうってレベルの機能だった。早速色々登録した。

  • ホットコーナー機能を知る。今までなんで使ってなかったんだろうってレベルの機能だった。早速色々登録した。

開発における気づき

  • ファイルを探す時間を極限まで減らす。ファイル探すときはcommand + f、command + p、command + shift + fを使う。

  • フロントエンドでサーバー側にアクセスする場合、最終的には値が返ってくるので、どんな値が返ってくるのか、どのurlやhttpメソッドでリクエストを投げるのかを事前に知っておく。

  • このコンポーネントはどのファイルで、どのディレクトリにいるのかを瞬時に言えるようにする。

  • 考えがまとまらないなら、今何が分かっていないのかを分かるようにする(無知の知)。

  • TypeScriptのエラーなら、〇〇 TypeScriptで調べる。

  • ネットワークタブのレスポンスタブでレスポンスボディが見れる。type xhrはAjaxリクエスト、head :okがサーバー側から返されたらレスポンスボディはない。

  • ディレクトリはABC順になっているので、直接ファイルを探す場合はそれを意識する。脳に疲労をかけないで、サクッと探せるようになる。

  • プルリクやコミットの粒度に気をつける。プルリクが大きいと見る人が大変なので、自分のタスクとかけ離れている内容は別のタスクとして切り分ける。

  • clipyのスニペット機能がすごい。アクセスできるまでの時間を極限まで減らすと、すごいストレスフリーになると感じた。すごい。

  • 開発するときはまずは自分で方針を考える。ネットなどの既存の実装に囚われすぎない。自分で考えて実装する。

  • サステナブルな開発をしたいので、開発が便利になるツールやガジェット、時短アイテムには積極的に投資するようにした。あとは体が資本なので健康的な生活をする。

  • 開発スピード上げたいなら、言語やフレームワーク、ライブラリを自分の中で枯れるまで使いこなす。

  • 30分間隔で集中する。大きいタスクを小さいタスクに分解してノートに書いたり、コードを書く前にまずは方針をノートに書く。

  • コピーは絶対command + cでやる。GUI操作だと遅い。

  • GUI操作で遅くならないようにするために、GUIを画面から消す。

  • ホームポジションから極力手を離さないことで、作業効率を倍増させることができる。

  • ブランチで作業中の時、別のブランチに移動しないといけなくなったら、スタッシュをしてから移動する。

  • 最新のメインブランチにリベースするなら、メインブランチの最新の状態をプルしてきてからリベースする。

来週の月曜にやること

  • ローム拡張機能を社内PCに導入する ( Holmesのショートカットキーをcommnad + shift + kに変更しておく。よく見るサイトだけをブックマークする)。

  • Dockを非表示にする。

  • メソッドジャンプを導入する

所感

何も見ずに開発したことによって、「なんでこの方法で実装すべきなのか?他の方法でも実装できる。」「このライブラリの他の使い方はないのか?」等を考えたり、CTOと相談することができました。人のコードを参照していただけだと、ここまで深い階層の話はできなかったし、自分で方針を考えて作る力も培われないので、本当にやって良かったです。機能作成にベストプラクティスはあっても正解はないと思うので、自分で方針を考えて実装する力をもっとつけたい、、新しい方針を自分で考えるためには、もっと根底の知識を身につけるべきだと感じました(web技術、ネットワーク、プロトコルLinuxApi等)。
あと、コードを書いていると気づいたら1日が終わっているので、1時間あたりの生産性をもっと高めたいです。コードを書く時間が長いせいで、アウトプット比重になっているので、インプットできる時間も取り入れたい、、まずは言語やフレームワーク、ライブラリの理解、ツールやショートカットキーの習得を通して生産性を上げようと思います。実装力や方針を考える力は経験によって培われると思うので、どんどん失敗してチャレンジしていこうと思います。

以上です。
6/11からの5日間も頑張ってきます!