俺がコードを書くのが遅かったのは、なぜだったのか? 真剣に考えてみた
最近、「あれ？俺、タスクをこなすのが早くなってる？」と感じる事が増えた。具体的な時間を計ったわけではないが、スプリントの終盤ではなく、半ば、もしくは前半で土台が出来上がっている事が多くなったり、スプリントでこなせるタスクの量、レベルも上がったなと感じる事が増えた。
アウトプットに直結する「コードを書く」ということについて、そもそもなぜ俺は遅かったのか、言語化してみたくなったので書きなぐってみる。
ちなみに、半分宣伝だがこの記事を読むと私の背景やコンテキストがより明確になるかもしれない。
設計や、やるべきことが明確でない
スプリントで新しい問題に取り組もうとするとき、その問題をどうやって解決するのか考えるのはエンジニアの仕事であり、実現するためのステップや複雑さをいかに減らすのかがエンジニアの醍醐味でもある。
これから実装したり、修正しようとしている機能に対して、どのようなアプローチを取って良いかわからないときは、コードを書く手は止まっているはずである。
「そもそも設計や分析をちゃんとやってから取り組めよ」案件ではあるが、残念ながら私のチームでは思ったとおりにできていない事が多かった。
初学者がしばらく迷った末に書き始め、実装した設計は大体誤っており、Github の PR でレビューを依頼する頃にはすべてが遅すぎる状態になっている。ほとんどの場合、すべて書き直しに近い指摘を食らうか、レビュー力がないチームだと最悪その悪い設計のまま取り込まれてしまう。
何がダメだったか
私もなかなか周りに質問できないクチの人間だったので、二進も三進も行かなくなって誰かに助けを求める前に、とにかくプロダクトのコードベースを調べた。
とにかく調べて、似たようなユースケースがなかったか考えて、ひたすらコードを漁った。ただし、読んだのではなくて、目を通しただけだったので、実力になってはいなかったと思う。
どうすればよかったか
ここで本来やるべきは Miro でも手書きでもなんでもいいので、チームメンバーとモデリングを共有すること、早い段階でフィードバックを得て、安心感を得ることだった。
How が思いつかない
シンプルに経験不足。
設計を考えたり、モデリングを共有する前に自分でそのアイデアが浮かぶスキルレベルに達している必要があった。そうでないと、いつまで経っても私はテックリードの考えた設計にしたがって実装するしかできないからである。
そのためには、基本的なモデリングの方法はもちろん、たとえば非同期処理や、低負荷なデーターベースアクセスといった事も頭に入っている必要がある。
何がダメだったか
特に、後者については、単純な CRUD を実現する延長線上のアプリしか個人で開発したことがなかった私にとって重大だった。たとえば Ruby on Rails でよく使われる Sidekiq による非同期処理は実装パターンやそのコードベースにおけるお作法を知っていないとその時点で設計の引き出しが絞られてしまい、結果的に破綻する。なので、どのように解決するのか、を自分で考えられる力は継続して育む必要がある。
どうすればよかったか
残念ながら、今の私が言えることとして、これを解決してくれるのは、ひたすら経験を積むしかないと思っている。
言語の基礎的な部分を暗記できていない
サードパーティーライブラリといかないまでも、言語組み込み関数やよく使う標準ライブラリは、検索せずに覚えたほうが絶対に良い。
最近読んだ「プログラマー脳」でも語られているが、人間は大きく分けて長期記憶と短期記憶、2 つの記憶装置があり、短期記憶で覚えられるのはせいぜい 2 ~ 6 個程度である。
チャンクと呼ばれるカタマリとして、実質的にその数を増やすこともできるが、基本はそうなのである。
何がダメだったか
私は TypeScript / JavaScript が得意だったが、仕事では Ruby そして Rails をフレームワークで使っている。
あるデータに対する操作として、TS であればどのようにコードを書くかある程度頭の中でイメージできる。
ただ Ruby で書く場合、Ruby における文化や、メソッドを知らないため、TS だったらどのように実現するかを考えてから、それと似たような手段を都度関係するクラスやメソッドを検索していた。
特に私は記憶力が弱い。
思い出せないクラス、メソッドを使うというのはつまりコードを書く手を止めて、Google 検索なり、今なら ChatGPT を開くということで、まずその時点で時間をロスしている。
そして、たいていの場合、検索するついでに私は Slack や Twitter を開き、本来の目的（＝忘れていたメソッドの使い方を一時的に覚えたので、それを使うこと）を忘れ、そしてついには自分がどんなコードを書こうとしていたのか忘れるのである。[1]
どうすればよかったか
言語の基礎的な文法や、プロダクトでよく用いるお作法は、もっと早い段階で覚えると幸せになれたかもしれない。
ただこれは結果論で、他にも覚える事はいっぱいある時期から今にかけてやってきているので、一概に「覚えてなかったからダメ」というわけでもなく、「検索するための頭のインデックスはあったので仕事はできたけど、速度を上げたいなら覚えよう」という話なのである。
ちなみに「プログラミング言語の文法を素早く習得する方法」という章が「プログラマー脳」にあって、原始的だが合理的なので興味ある人はトライしてみてほしい。
テストの書き方で躓いている
この記事を書いているちょうど一年前に、当時のテックリードに「テスト駆動開発を学べ」と言われた。私がソフトウェアエンジニアにジョインする２ヶ月前のことである。
今では TDD が好きで、 Red / Green / Refactor のリズムがうまくできている時は本当に自信を持って取り組めていると感じるし、何より自分の居場所がわかる安心感を感じる。
ただ、初学者にとってテストを書くためには普通にコードを書くのとは少し違った考え方を要求されるし、慣れが必要なことでもあると思う。
そもそもテストファーストで取り組むべきでないシーンもある。
何がダメだったか
私の場合、意地を張ってテストから書く事に拘っていた。FactoryBot の使い方ですらも曖昧な頃だった。TDD は初めてにせよ、テストを書いた経験は今までもあったので、モックする考え方はあるものの、その書き方を調べる事に時間を費やしたりした。
どうすればよかったか
TDD を良いリズムで実践するなら必要最低限のテストの文法は空で書けるレベルになっているべきだと思うし、どんなテストの仕方をするのかもイメージできているべきだと思う。
ただ、テストを後から書くのは気持ち的な労力がいるし、コードが取り込まれてからテストを書く気持ちにはなれないかもしれない。だから、PR にテストを含めていれば OK という緩和ルールでも良いかもしれない。
ちなみに、伊藤淳一(@jnchito)さんが書くブログの最近の投稿に「あーこれは無意識にやってたかも」というスタイルがあったのでこちらで紹介します。
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発
必要最低限のテストの文法は空で書けるレベルになっているべきだと思うし、どんなテストの仕方をするのかもイメージできているべきだと思う。
私はスプリントに取り組む際、どちらかが欠けている事が多くあったので、テストが書けるようになるまでのスプリント初期はかなり時間を食い、TDD のリズムが出来始めてからスプリント終了にかけて開発速度が上がっていく、そんな繰り返しだった。
コードを読むのが遅い
設計が頭に入っていて、How が明確であり、コードもある程度書けて、そしてテストファーストで実装ができる。
それでも、コードを読むのが遅いと、いつまで経ってもコードを書くステップへ進めない。
エンジニアの業務のうち、7〜8 割は既存のコードを読むことだと言われている。コードが読めないとそもそも設計を考えつくこともできないかもしれない。
コードを読むのが遅い原因はいくつかあって、それを具体的に言語化して説明してくれているのが、先でも紹介した「プログラマー脳」だ。
何がダメだったか
この本によれば、おそらく私はこんな状況だったのだろうと思う。
- クラスやメソッドから処理の概要をつかもうとする。だが経験値（≒ 長期記憶）が浅く、引き出しがないので、中身を読んでいく必要がある
- 見慣れないメソッドや、複雑な処理手順に頭が混乱する。別のクラス、メソッドを呼ぶ場合はそれらをコールスタック的に読み進んでいく
- ライブラリや言語組み込みのメソッドの使われ方がわからないので Google で調べる
- 短期記憶や頭の処理回路が弱いので、ここまで読んできたコードの概要を自分用のメモに残す。すべて終わってからようやく全体像がわかる
どうすればよかったか
私の場合は、上述したような経験値の低さと、言語の習熟度の低さがコードリーディングの速度そのものに直結していたので、この 2 つが解消していくにつれてコードを読む速度も上がっていった。
「プログラマー脳」では、こうしたコードを読む力を育むためのテクニックや演習問題も紹介されているので、これらも今後取り入れていきたい。
また、ひたすらコードレビューするのも良いムーブで、私は最近自分のチームに関係のない PR も目を通したり、コメントを残したりしている。
集中できていない
私から見て、強いエンジニア達は上記のいずれも完璧にこなせていると思う。それでも彼らには生産性がとても低い時がどうしてもある。集中できていない時だ。
集中できない原因は色々ある。
- SNS やメール、メッセンジャーツールが気になったり、通知に気を取られてしまう
- 誰かに話しかけられる
- 体調的な要因（お腹が空く、眠い、トイレに行きたくなる、頭痛などの体調不良）
- 精神的に参っている
- 環境が合わない（椅子の座り心地、雑音、明るさ）
あんなに強いエンジニア達も、所詮人間なので、上記のような障害に日々悩まされている。
ただ、彼らなりに自衛の手段はもっているから強いエンジニアとして君臨しているのであって、私も「集中できない」を言い訳にし続けられないのである。
何がダメだったのか
まだまだ深堀りの余地はあるが、規則正しい生活はとても大事だった。
特にリモートで仕事をしている日は、朝活できるぐらい心身ともに健康な時もあれば、業務開始ギリギリまでベッドにダウンしている時もある。
そういう日は大体いつまで経っても集中モードに入れず、無限に Slack を眺めたり、「調べごと」と称してプロダクトのコードを「眺める」だけの非生産的な時間の比重が多い一日になるのである。
どうすればよかったか
上記で挙げた順に、自分ができそうなことを考えてみた。
- 集中したい時間を決めてその時間はすべてのツールの通知を無効にしたり、アプリを終了する
- ハイブリッドな勤務形態であれば、出社する日は「話しかけられる日」と割り切って業務を進める日にする
- 事前にコンディションを整える、低気圧に負けず薬をしっかり飲む
- よく寝てメンタルをリセットする
- 自分が集中できる環境にお金を投資する
また、ポモドーロテクニックも有効で、私はよくこれを使っている。知らない人はぜひ調べて試してみてほしい。
上記はあくまで「『私が』コードを書くのが遅かった」原因の振り返りで、これを読んでいる皆さんにはまた別の事情があるかもしれない。
ただ、共通する・共感できることもあると信じているので、悩んでいる方は参考にしてみてほしい。
また私が悩んだ事について良いアドバイスがあればぜひ気軽に教えてくれると嬉しい。
参考
/ 以上
-
「プログラマー脳」でもまさに言及されている ↩︎
Discussion