プログラムの設計の過ちにいつ気付くのか

他の人から指摘を受けないと筋の悪いコードを書いていることに気づけなかったり、他の人が書いたコードのまずさをうまく言語化できなかったりしてモヤモヤするなぁと思ってこの文章を書いています。(※この文章に明確な結論はありません。)

プログラムを書くようになって3年くらい経過しましたが、よくない設計をして自分やチームを困らせたことが何度もあります。私が設計の過ちに気付くのは大きく分けて以下の4つのタイミングがあります。

  1. 人に指摘を受ける
  2. 新規の機能を追加する
  3. 既存の機能を修正する
  4. コードを読む

人に指摘を受ける

新規の機能を追加する

また、既存の機能に影響は与えないものの、新規の機能から既存のAPIや関数を呼ぼうとしたときに、やけに呼びづらいと感じることもあります。

既存の機能を修正する

「既存の機能を修正する」と「新規の機能を追加する」はオブジェクト指向の文脈でよく言われるopen/closed principleに反していることに気づいたとも言えます。ただ、拡張に対して開いているべき、修正に対して閉じているべきというのはクラスに限った話ではなく、マイクロサービスなどのより大きな概念に対しても当てはまるのではないかと考えています。

コードを読む

オブジェクト指向でのアプリケーションの設計やRDBの設計などは歴史が長く、本質はほとんど変わっていないはずです。しかし、キャリアを積んだエンジニアでも設計を誤ったり、エンジニアによって解釈が異なっていることはあると思います。また、優れたエンジニアでも設計の筋の良さみたいなものをうまく言語化できていないこともあると思います。個人的にはこのあたりがモヤっとしています。

正しいとされている原則を具体的なコードと共に理解しておいて、コードを書くときに都度何が正しいかを考え抜く、問題のあるコードを正しく修正するということを繰り返すことが、設計スキル向上の王道パターンなのでしょうか?

追記

  • DB設計の場合、運用時(設計したものが成長した後)になるまで、設計が本当に適切だったのか、どんな時に問題になるのかを理解できないことがある。
  • 自分自身が考えて設計するのと、他の人に指示を受けて設計をするのでは残るものが異なる。自分で決断することがスキルにつながる。

Software engineer

Software engineer