プログラミングの設計の壁をどうやって乗り越えるか

305, 2020-02-22

目次

プログラミングの設計で大事なこと

プログラミングをやっていると必ず突き当たるのが設計の壁です。
調子よく開発が進んでるかと思いきや、設計の壁に当たって思うように開発が進まなくなる……。
そんな経験は、まぁある人ない人いると思いますが、大規模なプロジェクトほどこういうのが顕著に現れます。

かと言ってプログラミングにおける設計は、

  • これがベストだ!

  • これを使えば必ず成功する!

という万能の斧などは無く、日夜、世界中のプログラマーが試行錯誤をしながら模索をしていることです。
つまり、設計に詰まって途方に暮れているあなた、悲しむ必要はないんですね。
その悲しみは万人が経験するであろうことなんです。

ファイト!

今回はこの設計の壁について考えてみたいと思います。
要点は↓です。

  • 破綻する前に試行錯誤しよう

  • アーキテクチャ

  • リファクタリング

設計が破綻するとき

プログラミングでソフトウェアの設計が破綻するときはどんな時でしょうか。
私はこんな時だと思います。

  • 拡張できなくなった時

  • 手に負えなくなった時

まず拡張できなくなった時ですね。

拡張できない

拡張できないソフトウェアというのは、もう拡張の「か」の字もできません。
まったく手を加えるスキがなくなるんです。まるで歴戦の剣豪に睨まれているかのようです。
油断してると「袈裟斬り!」などと言いながらセグフォと共になで斬りにされてしまいます。

ソフトウェアの運命というのは拡張され続けることにあると言っても……いや、C言語などは枯れていることが美徳だったりしますが……ある程度、差し支えないところがあります。
拡張できなくなったアプリはその場でご臨終です。チーンという何かを鳴らす音とともにターミナルが真っ赤に染まるわけですね。

そういった意味でこれは、手に負えないと言っても良いかもしれません。

手に負えない

手に負えないソフトウェアというのは、もうどうしようもないものです。
手を付けられないということですね。

依存関係がぐちゃぐちゃで、モジュール同士がしっちゃかめっちゃか相互依存しあって、関数もなにをやってるのかさっぱりわからないしコメントもない。
動くは動くけどセグフォするし、そのセグフォもどこで落ちてるのかよくわからないし、もうコードを見るのも嫌になる!

あ、帰ります

はい。帰りたくもなります。
医者に見せたら「なんでこうなるまで放っておいたんだ!」とお叱りを受けるレベルでしょう。
もっとも、ソフトウェアを見せられる医者がいればの話ですが。

手に負えないソフトウェアは、愛着もなくなります。可愛くないんです。育てようという意欲が全くなくなって、放置プレイになります。
なんだかソフトウェアも哀れになってきますね……。しかし、仕方ないんです。にんげんだもの。

設計が破綻してからできること

設計が破綻したらできることはあるのでしょうか?
この窮地を救ってくれる会心の手が、なにかあるのでしょうか?

ありません

残念ながら、ないんです。

なにかあるはずだー!

と言っても、そんなものはありません。
つまり、一度設計が破綻したらジ・エンドです。
「設計の破綻=プロジェクトの座礁」ということですね。

唯一できることは、作り直すことです。

いちから作り直す

そのプロジェクトがプロトタイプだったら幸運ですが、本番のプロジェクトだったら大変なことになります。
0から絡まってるスパゲティは0から茹で直さないとどうしようもありません。

いちから作り直すという英断ができれば、すべてのストレスから開放されるでしょう。

しかし、いちから作り直すという選択は中々選ぶことができません。
既存のプロジェクトをこねくり回したりしながら、なんとか延命を試みようとするわけです。
だけど、そんなことをやっても、やはり手遅れなものは手遅れです。

それだったら、もう思い切って最初から作り直したほうが良いわけです。

設計が破綻する前にできること

設計が破綻する前にできることはあります。
それは↓のようなことです。

  • アーキテクチャの実験

  • リファクタリング

アーキテクチャの実験を考えてみたいと思います。

アーキテクチャの実験

アーキテクチャの実験とは、あーでもないこーでもないと言いながら、アーキテクチャを選択し、ある程度コードを書いて、実験することです。
この実験が上手くいくと、設計における最初の課題は解決したようなものです。
逆に言うと、うまく言っていないプロジェクトというのは、このアーキテクチャが曖昧になっているんですね。

アーキテクチャというのはプロジェクトの土台です。土台さえしっかりしていれば、大抵のことはなんとかなります。
しかし、うまく言っていないプロジェクトは、このアーキテクチャの導入段階の実験が足りていないのです。

プロジェクトの初期において、アーキテクチャの選択は非常に重要です。
そして、プロジェクトの特性に合わせてアーキテクチャを変形させることもそうです。
アーキテクチャにうまく適合しないなら、アーキテクチャを発展させればいいんです。

発展させて、そして破綻すると

はい。しかし、アーキテクチャの実験段階において、プロジェクトの破綻というのはセットになっているようなものです。
なにせ実験なわけですから。むしろどんどん失敗したほうが良いわけです。
開発の初期に、そうしたアーキテクチャの実験を繰り返すことで、土台がだんだんと固まって行きます。
これはつまり、プロトタイプを作れということです。

プロトタイプを作って、たくさん失敗して、その中から使えそうなものを選ぶ。
こういうことです。

リファクタリング

プロジェクトの中期以降で重要になってくるのがこのリファクタリングです。
リファクタリングとは、プロジェクトの健康状態を管理する手法と言えます。
ふつう、開発を続けると、プロジェクトというのは健康状態が悪くなっていきます。

そのため、リファクタリングによって健康状態を維持する必要が出てきます。
このリファクタリングをやらないとどうなるのでしょうか?

プロジェクトは小さなところからほつれて行き、やがてそのほつれは大きな穴となってプロジェクトを破綻させるでしょう。
それを予防するのがリファクタリングです。

リファクタリングはいつやればいいのかというと、常に心がけるようにしましょう。
コメントが付いてなかったらコメントを付け、コピペのコードがあったら共通化して、テストを書いてなかったらテストを書く。
コミットするたびにリファクタリングも並行して行うのが理想的と言えます。

破綻する前に試行錯誤しよう

共通して言えるのは、破綻してから何かをするのは遅いということです。
ですので、破綻する前にできるだけ試行錯誤するようにしましょう。

小さなコードを書き、実験を行い、うまく言ったケースを転用する。
そしてリファクタリングを継続して行い、テストを書く。

破綻は急にやって来るときもあります。
しかし、我々はそれに抵抗することは出来ます。
問題は、その抵抗は破綻の前にしなければならないということです。

おわりに

いかがでしたでしょうか。
プログラミングの設計の壁は、プロジェクトを破綻させ、開発者にダメージを与えます。
しかし、アーキテクチャを吟味して、リファクタリングを継続すれば、抵抗することができます。
設計の壁に遭遇してプロジェクトが破綻することになってもそれは仕方ありません。人間なんですから、無理なものは無理です。
しかし、破綻した経験は無駄にせず、次に生かせるようにしないといけません。それが実験の重要性の担保です。

壁を乗り越えよう

おしまい

スポンサーリンク

スポンサーリンク

スポンサーリンク

スポンサーリンク