目次
趣旨
コードを書いているときに思うこととして、
「プログラミングのときに自分の考えていることと他人が考えていることは違うようだ」
と感じることがあります。
特に仕事としてプログラミングをするようになってから顕著に感じるようになりました。 これを示せるようになれば、それらを議論し、より良い開発に繋げられるのではないかとおもうところがあります。 しかしそもそも自分がなにを考えているかを示せないと感じることもあるので書いておくことにしました。 （多分もっと色々考えてたりするとは思います）
そのためこの記事を読む場合は、いわゆる一般論とは違うかもしれませんし、もしかするとアンチパターンが含まれている可能性もあるということを念頭に読んでもらえればと思います。
あと、実際にはここに書かれているほど理路整然と順番に考えていることは少なくて、行ったり来たりしながら情報を埋めていくように進めていることが多いということを補足しておきます。
始める前に考えること
プログラミングで解決しようとしている問題を理解する
個人的に理解していないことを設計したり実装したりするのは難しいのでまずはこれをやることにしています。
ここから先でしていくことの起点になる部分なので多少時間をかけても理解するようにしています。
- なぜ解決したいとなったのかを理解する
- 問題をより詳細な問題に分割できないか考える
そもそも解決すべき問題なのか考える
実装しなくても解決できることはそっちの方がいいので、そういう問題では無いかを考えます。
また、すぐに解決しなくても良い問題では無いかを考えます。
意外と想定が漏れているだけだったり、コミュニケーションの齟齬でプログラミング以外で解決する問題というのもあったりします。
もちろんプログラミング以外の問題だとしてもチームの問題として考えるは大切なので、解決できるように進めます。
- すでに実装しているもので解決できないか
- 今すぐ解決しなくても良い問題ではないか
- そもそも問題ではないのではないか
より良い解決策が無いか考える
解決すべき問題だとしても、プログラミングによって解決すべき問題ではない場合もあります。
- 作業の工夫で解決できないか
- 既存のツールで解決できないか
実装の前に
だれが関係者か（ステークホルダの理解）
関係者（ステークホルダ）を把握します。
特に他の人に影響する部分がないかは気をつけておくようにします。
コミュニケーションの齟齬によって、結果的にチーム全体の開発速度を下げるようなことにならないように気をつけます。
- 業務上把握していなければならない人はいないか
- 依存する作業をしていて、影響を受ける人はいないか
- 実装の結果として想定外の作業が発生する人はいないか
- 実装されなければ作業が開始できない人はいないか
なにが関係するか（依存するタスクの把握）
他のタスクに依存していないかを確認します。
- 仕事上重要な依存するタスクはないか
- 依存関係として、先に済ませておいたほうがよいタスクはないか
いつから始めるか（優先度）
他に優先すべきことが無いかを考えます。
- より重要なタスクはないか
- 決定ができるタイミングが遅く、今すぐ始めても進められないなどないか
どのくらいの時間でできるか（コスト）
どのくらいの時間でできるか考えます。
これを考えたタイミングで問題の解決に対して費用対効果が悪いということもあるので、実装前に考えずに早い段階でざっくりとした情報を出せるように進める場合もあります。
- どのくらいの大きさのタスクか
どのように実装するか（技術的関心事と設計、実装の順序）
実装のためのアーキテクチャや構造の設計について考えていきます。
より詳細な設計は先に想定しつくすのが難しいため、実装の段階で行うことが多いです。
またそれらをどの順番で実装するかを考えます。
- どのような技術を利用するか
- 解決策に対して適切か（コスト・技術）
- チームとして保守していくことができるか
- より汎用的な解決策はないか
- どのような設計で実装するか
- シンプルか（今は不要なものを含んでいないか）
- 問題領域に則しているか
- 必要な拡張性を有しているか
- 他の人が同じ箇所を触る際に間違えにくいようになっているか
- 1つの場所で1つのことだけ考えればいいようになっているか
- どのように実装するか
- タスクを実装の単位に分割する
- 実装の順序を考える
実装する
他人が見てわかりやすいか
コンパイラに通ることやコンピュータが解釈できるかは重要ですが、現状ではAIがプログラミングをしてくれるわけではないため、人が理解できることは注意深く考えながら実装しています。
- 適切な単位で実装が分割されているか
- 関数やオブジェクトなど
- わかりやすく、勘違いしにくい命名になっているか
- よりシンプルな実装がないか
- VCS上でわかりやすいコミットの単位になっているか
正しい実装になっているか
想定した挙動をする実装になっているかは考えています。
これを確認するためにテストを書いたり、実際に動かしたりするようにしています。
さらに単に確認するだけでなく、確認すべきことを正常系だけでなく異常系なども考えるようにしています。
より早く動く方法がないか
コンパイルや実行時など、早く動くように書けないかを考えます。
とくにより良いアルゴリズムの選択や不用意な重複を作らないなどの他の問題を引き起こしにくいより良い方法は積極的に取り込めるようにします。
（コレクションの選択や操作などはよく出てくるため、特に注意深くなります）
ただし並列化するなどの複雑化を取り込むことには注意深くなるようにします。
車輪の再発明がないか
既存のライブラリや実装に同じものが無いかを考えます。
保守やコスト面などを含めて損が多いため、車輪の再発明は積極的に減らせるようにします。
（単なる学習目的の際はこの限りではないです）
最後に
足りない感じもしますが、自分のプログラミングのときに考えていることの土台はある程度書き出せたかなと思います。
このあたりは、これまでに読んできた本や実際の経験などの積み重ねでできるようになっていった部分は多いと思います。
より良い開発ができるように知識・経験を重ねていけたらと思います。
