ごみ捨て場
ソフトウェア・エンジニアリングに関して、これまで得てきた経験と知見を断続的に追記していく試みです。
プログラムとしての文法が成立する、ということと論理的に成立していることはトートロジーである。
世界は意思や意味、すべての現象的・言語的・超越的・再帰的な存在を持つ。
その構成要素のすべてを列挙することは不可能であり、認識による対象の発見は即座に世界に還元される。
それは排中律の存在有無など論理形式に関する大きな公理のみならない。
とんこつラーメンは絶対においしいという実存の小さな公理まで、その公理系の組み合わせによる自己言及を除く定理群の無矛盾性が保たれる限り、ただ純粋に存在する。
実存の思考が何かを対象とするとき、必ず対象に対する実存の認識を必要とする。
実存の認知しない存在は議論の対象になりえない。
ある対象が演繹的に算出された静的なものであったとしても、常により上位の論理的使役を伴う発見があることを絶対に否定できない。
「人は善と悪を併せ持つ存在であるか」という問いは、人・悪・善という対象を実存の循環から発見したことを元にする命題であり、決して先天的なものではない。
こういった問題は異なる論理空間上に並列に存在し、常に実存の発見によって採択される具体的な論理空間によって、認識としての真理値が常に変わる可能性を抱えている。
表す、ということはその対象に対して無矛盾に語るということであり、論理的な表現力のない形式はその責務を果たせない。
複数の論理空間の間の矛盾は常に許容されているが、プログラミングの成果物であるソフトウェアを実行した結果は常にただ一つの論理空間に属する。
矛盾した存在は論理空間上では存在できないので、常にそのソフトウェアは実存の意思とかけ離れたものとなりうる。
論理空間は目に見えない。
そこに実存の関心を寄せるものは意味のみである。
その対象が演繹的に算出されたものであるとき、異なる論理空間においては存在しない可能性は常につきまとう。
論理空間に存在しないものについて語るのは不可能であり、それに意味を持たせるということは新たな論理空間に身を投じるということである。
これは開発における諸問題の元凶であり、明確な意味を指示しなければ会話は成り立たないことを示し、怠るならばそれぞれが各々の論理空間に閉じこもる他なくなる。
感覚に過るのは世界のみであり、意思がなければ全ては同一化されたものと認識され、そこに新たな発見はない。
意味性は言語の性質と近接しており、異なる論理空間において形式としては正しいが意味としては成立しない、意味のない会話を繰り広げることになる。
実体のないものは実現不可能であると認識される。
そうしたものは端的に言って動作せず、役に立たない。
それは現実では異なる論理空間に晒され続けるからで、ただ形式によって記述された論理はそれに対する耐久性を持ち合わせていない。
逆説的に、役に立つソフトウェアとは社会認識における意味を持つものであり、価値の高いソフトウェアとは高い経済的価値を持つ意味を正確に指し示すものである。
そうでないあらゆるソフトウェアのビジネス上の価値はそれらに従属する。
実存の考えうる対象は、その能力的限界において異なる論理空間の要素の参照───論理的誤謬を引き起こす。
それはプログラマに限らずその仕事に関わる全てが対象であって、多くの関係者は異なる論理空間における意味について議論を勧め、結果成果物として場に置かれる矛盾した形式が主たる課題である。
誰もが自分の意志を持っており、次の瞬間の意味はお好きな論理空間からビュッフェスタイルで選ばれることになるからだ。
そういった深刻な状況において、些末なコーディングスタイルやパラダイムはこの問題を一切解決しない。
より上位の問題にとってはどうでもよく、記述する対象のない形式は不定にならざるを得ない。
間違えるべきでないのは、このことを忘れないことである。
すぐれた設計、コード、ソフトウェア品質、プロダクトとは明確な論理空間を発見していなければ決して生まれない。
小手先のテクニックや方法論は問題を蓋の中に隠すが、意味性に関わる問題を何も解決しない。
異なる論理空間を合成し、プログラムで表現可能なたったひとつの論理空間を記述するとき、必然的に損なわれる公理、連なる意味が存在する。
それを業界ではバグやデグレと呼んでいるが、仮説と検証を繰り返し新たな論理空間を発見しそれを実現する昨今のプロセスにおいては避けられない事象になる。
特にプロダクトの方向性が定まっていない成長時期であれば、そもそも記述する対象が定まらず、意味の存在が実存にとってあやふやなものとなり、やはり不可避である。
他人の意思は絶対に理解できず、あらゆる行動は無意味になりうる必然性を抱えている。
形式レベルでの唯一の低減策は、未来において採択されるであろう異なる論理空間と、現時点で採択されている論理空間の間の共通要素を見極めることである。
「ユーザー」という構成要素が存在するとき、異なる論理空間における「ユーザー」は言語的には同一であるが、意味としては別のものである。
また、その使役関係においても論理空間によって違うものを持つ。
これはいかなる対象についても言うことができるが、重要なのは所詮確率的にうまくいくかどうかの対処療法であることを理解しながらも、
粛々とその分析を行い独立しているだろうと蓋然的な判断をした構成要素に対して分離した記述をすることである。
ある論理空間の P, Q の存在理由について考える。
二者の存在理由が P<=>Q であるとき、記述の分離レベルにおいては同一と見做されるべきである。
ディレクトリレベルであれば、同一のディレクトリ配下にその要素を記述することになるし、システムレベルでは同一のサービス内に配置するべきである。
また、P=>Q の場合ではQはPを使役する親として明確に独立した定義をするべきである。
これは当然ながら型や関数に一致する。
「ユーザー」というのは適切な言葉でない場合は得てして存在する。
例えば企業情報の管理システムであるなら、システム利用者の権限によって異なる導線を持つことは自然である。
そのとき、当然ながら管理職とメンバーは論理的な使役関係において異なる繋がりを持つことは想像に容易だ。
であるなら単純なモデリングだとしても、
管理職=>利用者, メンバー => 利用者や、利用者検索 => 利用者の使役が成り立つので。
利用者検索 => 利用者 <= 管理職, メンバーという論理空間を成立させることができる。
記述を型、関数、クラス、ファイル、ディレクトリなどの
ソフトウェアレベルのみで行うか、サービスレベルにおいても行うか、
という分離レベルの問題が品質に対して本質的でないということである。
いかなるレベルの分離であれ、それが実存として認知可能なものであれば当初の問題は軽減される。
残る問題は実行時パフォーマンスやデプロイ容易性などのチーム事情、技術的な問題に終始する。
テストコードは本質的にはプロダクションコードの持つ意味と同一で二重定義の意味のみをもち、その存在は意思にとって無意味である。
なぜなら、Q=>Pはある論理空間において自明であって、それを記述するプロダクションコードは既にそれを表現しているからで、その論理空間の認識の誤りはテストコードであっても解消できない実存の問題であるからだ。
現実世界においてそれが重宝されている理由は人間の論理推論能力の限界によるものであり、
「Q=>Pが成り立つ」という意味性を蜘蛛の巣のように絡む諸事情によって認識を誤りうる現状に由来する。
しかしながら、コードがある論理空間を正確に記述できているか、その論理空間は意思に沿うものか、ということを論理的に推論することは自己言及と決定不能な問題に陥り不可能である。
公理そのもの──型の形式的な定義が正しいか、またそれらの関係が論理的に成立しているか、
という問題の真偽を判定することはできるが、ある論理空間上に存在する公理そのものの是非を問うことはできないからである。
よってテストコードは不完全な記述形式による計算結果とプログラムという論理空間のミスマッチを防止するものに留まる。
プログラムという形式は計算機科学に裏付けされた推論によって動作するソフトウェアという振る舞いをする。
通常のプログラミングにおいて、その記述対象は実存の認識内で計算機科学に連なる構成要素を必ずしも対象としない。
プログラミングにおいて、DBに存在するすべてのユーザーを取得する行為はAllApplicationUser <=> AllDBUserと表せるが、論理空間の記述という点においては不十分である。
異なる意思によって出現する論理空間ごとの意味性の全てには対応できない。
その動的な変化によって論理表現は矛盾と崩壊に向かう必然性がある。
論理空間上において、引数をP・推論をC<P>・実体をRと置く。
このとき、Pは記述上に存在しているものだけでなく、その推論の実行者を必ず含む。
思考は実存に根ざすものであるし、ソフトウェアの計算ではコンピュータが必要である。
ある推論が任意の実体を必ず導き出すかということを証明することはできない。
ある実体が期待する実体に等しいかと推論することもまた不定である。
これは論理が何故になりたつのかという問題と同質である。
世界では推論機能の変更が起こりうる。
宇宙空間に飛び出た人間は簡単な計算すら誤り、電力不足に陥ったコンピュータは即座に推論を停止する。
そしてこれらの障害となりうる要素すべてを列挙することはできない。
無時間に推論することは不可能である。
「あなたの前に100匹のカラスがいる」という情報が正しいかを検証する方法は目の前の鳥を数え上げることのみである。
ある対象を認識したとき、それは既に論理形式として表現されている。
P=>Qを認識した状態で1ならば自然数を認識したとき、暗黙的にP=>Qは発見されており、論理推論を伴って1ならば自然数という構成要素間の関係を認識する。
より上位の要素から演繹的に選択した記述から導かれる実体がソフトウェアであり、その最終的な要素は常にプリミティブなデータ型の集合となる。
これ以降未完成、改修中。。。
コード実行時の挙動を型として表せているか、もしくは表せるようなコードとなっているか
コード内の関数について、「~をする」ではなく「~である」と命名しても不自然な構造にならないか
DBや外部サービスとの連携など、その外部状態が型で表現しきれない不定なデータを扱うコードは人の認知的に分離された配置となっているか
処理のすべては関数内に記述されているか(WEBサーバーにおけるbootstrap処理など、プログラムのエントリーポイント実行処理は除く)
関数が扱う値は、引数、その関数内で計算された変更不可能な値、同階層もしくは子階層のファイルの関数・定数のみであるか
不定な外部状態の取り扱いを除く全ての関数の戻り値は引数に対して常に一意であるか