手戻りを少なくして開発効率を上げるためにやっている2つのこと
簡単に結論
- 開発効率を下げる1番の要因は手戻り
- 実装に入る前に実装方針を検討することで手戻りを少なくできる
記事の背景
先日こんな記事を読んで、自分も気をつけていることをまとめようと思ったのがきっかけです。
困っていたこと
DeNAに新卒として入社したときに研修の講師から「すぐにコードを書くな」とよく言われました。
- どんなクラス設計にするのか
- 要件に見落としているポイントはないか
を深く検討した上でコードを書き始めないとダメだという意味でした。
実際に僕も新卒入りたての頃はとにかく手を動かし始めるというアンチパターンを踏んでしまっていました。
最も開発効率を下げる要因とは何か
開発効率を最も下げる要因は、手戻りだと思っています。
これはプログラミング以外の他の業務でも言えることですが、僕は以下のようなことをよくやってしまっていました。
- 成果物が求められていたものと微妙に違っていて作り直さなくちゃいけない
- 途中までプレゼンスライドを作ったけど、なんか微妙だから1から作り直す羽目になる
- コーディングの途中で実装が汚いことに気づいて、最初から実装し直す
ビジネス書とかに結構書いてある「安心したくて、手をとりあえず動かしてしまう」というアンチパターンだと思います。
手戻りを少なくして開発効率を上げるためにやっていること
プログラミングをする上で手戻りをなくすためには以下のようなことを気をつけています。 (ここで述べているのは個人レベルでの話です。チームとか組織まで話を広げるともっとたくさん出てくるので話題の範囲を絞ります。)
フローチャート
少し大きめの機能を実装するときは必ずフローチャートを作成してから実装に取り掛かるようにしています。
これによって実装上以下のようなメリットがあります。
- 関連するシステム的な概念やビジネスロジックを簡単に整理できる
- 実装前に大まかな実装方針を検討することができる
また個人的な開発効率の範囲では余談ですが、フローチャートを作ると以下のメリットもあります。
- ドキュメントとして残せる
- コードレビュー時に実装内容を理解してもらいやすい
コメントだけで実装する
フローチャートを描いて、いざ実装!とやりたくなるんですが、この段階でもまだ実装には手をつけません。
実際にコードを書く段階になって以下のようなことに気づくからです。
- 実装しながら見落としていた詳細に気づいてフローチャートが間違っていること
- 既存の実装の制約上、やりたいことができないこと
- コードを書きながらもっといい実装があることに気づく
実装してから初めて気づくことは思ったよりもたくさんあるのですが、実際にコードを書いてしまっているとせっかく書いたコードが無駄になってしまいます。
そこで僕はコメントだけでコードの実装を考えるということをよくしています。
def calculate_amount # ここで不正チェックする # 全部終わったらメールを送信する end def send_finish_email # 完了を通知する # メールの受信拒否設定をチェックする end
このようにメソッドだけ作って中の処理をコメントで一旦書いていきます。
こうすることで、実装して初めて気づく詳細を知ることができつつ、手戻りを最小限に抑えることができるようになりました。
その他でやっていること
手戻りを最小にするためにやっていることではないですが、その他にやっていることを最後に紹介します
スニペットの保存
こちらの記事で詳しく書いていますが、何度も同じことを調べたり、よく使うコードはメモしておいた方が効率がいいのでScrapboxに保存しています。