ユーニックス総合研究所

  • home
  • archives
  • programming-tetsugaku

個人開発者のプログラミング哲学

プログラミング哲学

プログラミングにも哲学はあります。
それは普遍的なものや、あるいは個人が考えるレベルのもの。
今回は個人開発者の筆者がプログラミングの哲学を考えてみたいと思います。

関連記事

魔法の壺、プログラミングのライブラリ(Library)とは
頭悪い人にプログラミングは可能か?可能です
開発を3倍速にするプログラミングの考え方4つ
英語できないけどプログラミングはしたい。そんな人はこの方法がおすすめです
意味のないプログラミングの特徴3つ

第一に、プログラミングとは?

プログラミングとは何か。
これは興味深い話です。

私が思うにプログラミングとは、コードを書くこと、それから問題解決をすること、設計などいろいろな複合的な要素が絡んでいるものです。

  • コードを書く
  • 問題解決をする
  • 設計を行う

最初にこれらの要素を定義しておきましょう。
そうしたほうが哲学も論じやすいですし。
ではまずは「コードを書くこと」から。

コードを書くこと

プログラミングはソースコードを書く仕事です。
コードはパソコンへの命令になります。
パソコンはコードに書かれている命令を解釈して計算を行い実行します。

コードを書くということは慣れてくると一種ののようです。
極度の集中状態(ゾーン)に入り一心不乱にコードを書く。
この経験は多くのプログラマーが日常的に持っているはずです。

  • プログラミングでゾーンを体験する

逆に言うとこういったゾーンがないとプログラミングはあまり楽しくありません。
ゾーンに入ってコードを書き気が付いたらもうこんな時間!
というのが理想で、その状態に自分を持っていたらしめたものです。

集中状態は心地いいものです。
そして精神衛生的にもすぐれています。
コードを書くことはそういった状態に自分を持っていくということになります。

  • ゾーンは気持ちが良い

しかし運動不足の問題は困ったものです。
年がら年中コードを書きまくっていたら運動不足で血管もボロボロ、なんてことになりかねません。
ですから適度な運動をして身体の状態にも気を使う必要があります。

問題解決をする

問題解決をすること。
これは例えばバグ解決やエラー解決、それからアルゴリズムを考えることなどになります。

プログラミングは思考の格闘技です。
バッチバチにパソコンや問題とやりあう総合格闘技、なんでもあり(バーリトゥード)です!

  • 問題解決は格闘技!
  • なんでもあり!

プログラミングではバグやエラーが出るのが普通です。
これはプログラミングをやるなら一生付き合っていくかもしれない問題です。
(AIが解決してくれる? いつになるのか? 10年以内でお願いしたいですね)

特にバグの解決はかなり脳みそを使います。
論理的思考が必要です。
どこがどうなってこうなった、という探偵的なロジカルな思考が必要。

バグが取れた時の爽快感はけっこう強いものがあります。
この爽快感、達成感を味わいたくてバグ解決をしてる人も多いでしょう。

  • バグ解決は達成感がある

またプログラムのアルゴリズムを考えるのも大変な仕事です。
問題をどのように解決するのか、ということを考えなくてはいけません。
これも論理的な思考が必要で、どこがどうなってこうなったという肌感覚が大事です。

問題を解決するためにコードを書く。
これはプログラミングの本質的な部分です。
私たちがコードを書くのは問題を解決するために他なりません。

では問題がなければコードを書く必要もないのか?
答えは「いいえ」、世の中を便利にするためにコードを書くこともあります。

設計を行う

ソフトウェアの設計を行うのもプログラミングの仕事です。
設計はプロの世界ではコーディングとわけて分業することもあります。
日本ではシステムエンジニアが設計、プログラマーがプログラミング、という分業も一般的です。

設計はソフトウェアがソフトウェアたるのに必要なものです。
設計がダメならソフトウェアもダメに。
設計が良いならソフトウェアも生き生きとしてきます。

  • ソフトウェアの健康は設計次第

どんなひどい設計でも形にするプログラマーはまさしくプロの技と言えます。
しかしできれば設計は良い設計にしておきたいところです。

設計をうまくやるコツ普遍的な実用性のあるパターンを使うことです。
無理に自分でパターンを考える必要もありません。
もちろん自分で考えてもいいですが、それは失敗することも多いいばらの道です。
独創的な設計を編み出したい場合はその道を行くといいでしょう。

  • 普遍的なパターンを使って設計する

しかし! 多くの場合は既存のパターンを使えば用は足ります。
ですので設計とは知識です。
どのようなパターンを適用するのが良いのかそれを考えるのも設計者の仕事になります。

たとえ設計がダメでも泣かないでください。
いい大人が泣いてもだれも同情してくれません。
社会は非情かそれとお温かいか?
最近の日本社会は自己責任論がはびこっていてあまり温かくありませんね。
チェンジ・ワールド! 私たちの手で変えていきましょう!

バグ解決の哲学

プログラミングの深淵を覗きましょう。
その1つがバグ解決の哲学。

バグ解決とは大きな関心ごと、問題です。
プログラミングのほとんどの時間はバグ解決に使われます。
解決するのに1時間、1日、1週間かかるなんてよくあることです。

プログラミングはクリエイティブな仕事と思われがちですが、以外にバグ解決も必要です。
バグ解決がクリエイティブな仕事かどうかは議論があるところです。
バグの解決方法についてなにか哲学を持っておかないと、あなたはバグの前で苦しむでしょう。

私が考えるバグ解決の哲学は↓です。

  • 分岐点を記録する
  • 現状を把握する
  • バグの解決を試みる

分岐点を記録する

バグの解決では複数の手段を試す必要も出てきます。
そして1つずつ手段を試して解決できる手段を見つけます。

この複数の手段を試すときに必要なのが「解決の分岐点」を記録することです。
つまり作業をしていて、複数の手段が見つかったら、その時点での状態を記録するわけです。

  • 複数の手段が見つかったら状態を記録する

これをやっておかないと、間違った手段から復帰して別の手段を試すのが難しくなります。
バグ解決の初心者と上級者の違いはこの分岐点に戻れるかどうかです。

上級者は分岐点に戻って他の手段を試すことができます。
初心者は間違った手段に進んだらそのままそこに囚われてしまいます。
まるで落とし穴に落ちたカンガルーのように。

バグ解決では分岐点を記録する。
これも大事な哲学です。

現状を把握する

バグ解決では現在のプログラムの状態を把握するのが大事です。
これはprintf()などを使って変数の状態などを画面に出力して見えるようにします。

現状の把握でも論理的な思考は必要です。
つまり意味のある変数を出力しないといけません。
最初にバグの目星を立てて、それらを確認するように変数を画面に出力します。

  • 意味のある変数をあぶり出そう

そうして画面に関連する変数が見えるようになったらバグの解決を試みます。
この現状の把握は非常に大事なフェーズです。
ここではあまり脳みそを活用しなくてもいいです。

多くは手を動かすことが大事です。
手を動かし、変数の状態を明らかにしてこの後のフェーズの負担を減らします。

バグの解決を試みる

バグ解決の最後のフェーズはバグの解決を試みることです。
つまり現状からバグを推理し、仮説を立てます。

そしてその仮説が正しいかどうか試すということです。
仮説が正しくない時もありますが、その場合は別の仮説を立てます。

  • 仮説を立てて実験する

ここの仮説が正しかった時の達成感は格別なものです。
思わず「私、天才!」と言ってしまうのも仕方のないことです。

しかしそれは大いに結構なことです。
そういった達成感と自己肯定がプログラミングのスキルを高めるのです。

設計の哲学

設計の哲学と言うのも大事です!

設計はプログラムの心臓部。
心臓を設計してプログラムという身体を活動させます。
ドクン、ドクン。うん、健康! と言えるようなプログラムを作りたいところです。

重要なのは以下の5つ。

  • アーキテクチャーを採用する
  • デザインパターンを採用する
  • プロトタイプを作る
  • 分割統治を活用する
  • 抽象化する

アーキテクチャーを採用する

アーキテクチャーとはソフトウェアの土台となるものです。
これはMVCとかMVTなどがあります。
もっともMVCなどはデザインパターンだという人もいます。

ですのでこれは「アーキテクチャー(デザインパターン)」と言っても良いかもしれません。
いやしかしこれは少し強引でしょうか。
アーキテクチャーとデザインパターンは似ていますが、同じものではありません。
ここら辺は難しいところです。

要はソフトウェアを安定させたいなら土台を安定させる。
そして土台の設計はアーキテクチャーのパターンで行う。
ということです。

プロトタイプを作る

設計は設計書だけで作るとうまくいかないことが多いです。
なぜなら設計書はコンパイルできないからです。
機械的に検証することができないわけですね、設計書は。

だから設計を検討するには試作品(プロトタイプ)を作るのが大事です。
プロトタイプを作り、設計が正しいか検証し、そして修正します。

  • 設計をプロトタイプで検討する

プロトタイプを作ってない設計はぶっつけ本番です。
これはなかなかうまくいきません。大変です。

ちなみにプロトタイプを活用する開発手法をプロトタイピングと言ったりもします。

分割統治を活用する

関数などは処理ごとに分割しましょう。
間違ってもmain関数にダーっと書くようなことはしてはいけません!
後悔しますよ!

大きな問題を小さな問題に分割し、小さな問題を解決していくことを分割統治と言ったりもします。
設計は分割統治の塊です。

  • 設計は分割統治で行おう

適当な大きさに機能を区切って分割しないと大変です。
「神機能でなんでもできます」だとやばいです。おもにコードが。

分割統治を活用して機能は適当な大きさに分割しましょう。

おわりに

プログラミングの哲学はこれから需要が高まるでしょう。
なぜなら世はまさにプログラミング時代(ドン!)だからです!
プログラミングについて考え実践しそして活用していくのがこれからのトレンド(流行)と言えます。

🦝 < プログラマーは哲学者である

🐭 < プログラムを哲学しよう