より簡単な手法にさせてもらえない ３

なぜ手法により、解くべき「問題」を変えるのか？

「より簡単な」手法を成立させるための秘訣とは、具体的には、

• 解きたい問題をある動かない物体に例えた時、
• ある手法をその物体に対する視座に例えると、
• 正面からの視座よりも、わざと横目ギリギリの視座の方が、
• 解きたい問題に例えた物体が単純に見える

という性質を利用しているのだと思います。歴史的に見て、最終的に妥当だろうとされたものとよりかけ離れた手法だと、自然と（所与の）問題が単純に見えるのです。

これによりダマす意志なしに、実質的にダマすことに成功しているのです。

なぜその様な破滅的な秘訣を許すのか？

プログラミングの手法とは、乱数のアリゴリズムと同じで、（少なくとも文脈内で）一貫していることが求められるからでは無いでしょうか？
（乱数のアルゴリズムをさらに、実行中にランダムに切り替えると乱数が良くなるかと思ったら、実際にはより悪くなるという話があるそうです。）

• 臨機応変に視座（手法）を変えるより、一貫性を求めた方が、問題を解くのに有利

というのは動かし様が無く、

• 大きなプロジェクトで、プロジェクトの成員に対して、一貫性を強要してしまう
  （原理原則を無理偏に拳骨よろしく強要してしまう）

事実に対して、PMなど、権力勾配的に上の人間が恒常的に引け目を感じており、そのPMなどが優位性を感じていないプロジェクトでガス抜きをさせたいと感じるからだと思います。

根本原因は

その様にガス抜きをさせないといけないとなる根本原因は、

• より簡単な手法に対し、大勢の非専門家が賛意を與える

ことだと思います。ほめられるのは嬉しいのは確かです。

根本解決は

現在はプログラミング的には末世で有るとし、例えば100年後位に、
よりプログラミングが普及し、普通のお母さんが普通に子供に教えられる程度になり、
泰斗により標準的な教科書が何冊も（誰々の何々分野の教科書だ、みたいな）発行される
様な、来世に期待するしか無いと思います。

皆が知れば、皆が妥当とされない手法に賛意を與えることも無くなります。

その頃には化石燃料は使い尽くされているのかも知れませんが。。。

結論

少なくとも現時点では、これからも「より簡単な手法にさせてもらえない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

より簡単な手法にさせてもらえない ２

簡単とは、複雑とは？

簡単とは、

• 機能さえ使えればヨシ
  →典型的には「コミュニケーションの介在」（広義では、データベース、ファイル共有、サインイン、証明など含む）
  で、

複雑とは、

• それ以外全てで、必要悪としてさまざまな「再発明」が必要で、それでも何とか未来永劫使える、共通の言葉を得たい
  →典型的には、DDDやReactなど
  →提唱される中には、かえって有害となり得る、共通となり得ない言葉も多数見られ、全てを疑ってかかる必要あり
  →それら歴史を経た、少数の「共通の言葉」は理解し、腹落ちするのが困難
  で、

「プログラミング」と言った場合は、第一には後者が関係し、前者は、

• 多彩なクラウドサービスが有り、自分で手組みするのは（練習の為を除けば）引き合わない

ので、対象外と思います。

ITバブルの崩壊

GAFA企業のレイオフが言われていますが、これは、

• 「コミュニケーションの介在」以外のクラウド出し出来る機能が、出資者の求める時間内に見つからなかった

為だと思います。

GAFA企業の先輩格であるマイクロソフトやサンマイクロは、

• 「イベントドリブン」や「オブジェクト指向」で名を残しましたが、それ以外を時間内に見つけることが叶わず、

古いとされたのと同じだと思います。

何が言いたいのか？

嫌われる「プログラミング」と言えば、後者だと言いたいのです。

• 前者の華々しい成功から敷衍して、「プログラミング」にもその様な道が有ると主張する人が居て、
• それを真に受けて「理解するのが困難な、複雑な、共通の言葉」を拒否し、「簡単な手法で無いと嫌だ」とする
• のはおかしい！

と言いたいのです。

結論

もちろんこれは個人の感想に過ぎず、なので、

これからも「より簡単な手法にさせてもらえない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

より簡単な手法にさせてもらえない １

どの様な話？

COBOL74、COBOL85、VB6、VB.NET、Java6、Java8と扱ってきましたが、

• 時代が進む（進歩する）度に、より複雑になっている
• しかしへたに複雑にすると将来とりのこされるので簡単には複雑に出来ない

という傾向にあると思います。複雑に向かう進歩はゆっくりで、ましてや「より簡単な」というのは有りえないと思います。

限度を超えた進歩した書き方だと、次の進歩の時に全部書き直し（前の進歩に対応したフレームワークが廃れて、簡単にバージョンアップ出来ないなど）となりかねません。
まだ（たとえば）jQuery＋残り全て手組みの方が、

• ポン置き＋再コンパイルでのバージョンアップの余地がある

と言った様な話です。

いずれにしても、いままで通りか、複雑かの2択で、より簡単な手法が進歩というのは全く考えられません。

実際に「より簡単な」手法はあるじゃ無いか！

そういう記事は有ります。ただそれを成立させる秘訣も有ります。

• 進歩した方の解くべき「問題」をタチの良い、単純なものとし
• 旧態の方の解くべき「問題」をタチの悪い、どんな手法でやっても困難なものとし

「より簡単な」手法で、進歩した結果が得られる（様に見せている）のです。

過去の記事を見直してみると分かりますが、100％これです。例外は有りません。
問題の再定義というのは原理的には有り得るのかも知れませんが、デザインの分野であっても、結局はテプラを貼られてお終いｗというのが普通です。
ましてや意匠などのデザインよりずっとずっと多様性に乏しいプログラミングの分野で、「より簡単な」方向への問題の再定義というのは、破滅への道です。

是非とも過去のインターネット上の記事を見直して見る事をおすすめします。
例外無く、この秘訣を使っていると思います。

より簡単な手法にさせてもらえないのは

それなりにその人の事を考えての事だと思っては欲しいのですが、

結論

これからも「より簡単な手法にさせてもらえない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

自由裁量でリファクタリングをしないとならなくなる １

どの様な話？

「リファクタリング」とは、

リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。

リファクタリング (プログラミング)　Wikipedia 日本語版

というプログラミングの技法ですが、これをやると命の危機になります。
口の中が乾き、食べる気力も失せ、手指が震えます。

何が起きたのか？

画面のプログラムで、要件に従って修正をしていたのですが、

• 同じはずの、選択肢表示（コンボボックス）を担当するプログラムの部分で、
• 2箇所有る表示が、修正前は同じ動作をしていたが、
• 修正をすると、どちらかがダメになり、別の修正をすると、べつの側がダメになる。

という事態になりました。指示を出す方はテストはになってくれますが、何をやってもダメになる件については「何とかしろ」という励ましｗ以上の事は提供されませんでした。自分の自由裁量でリファクタリングをするしか無いと思いました。

どちらかのプログラミングの部分を切り取り、別の側のプログラミングの部分をすげ替えようという話です。

何が困難だったのか？

修正対象のシステムの原理原則として、

• 画面1つ事にプログラムファイル1つ
• 関数呼び出しは有るが引数が無く、情報のやり取りはグローバル変数（セッション変数）のみ
• 名前の命名規約皆無、ただし、名前の先頭には＄マークが必ず有り
• プログラムの部分の共通化完全不能（手立てが無い）

という物でした。

選択肢表示（コンボボックス）を担当するプログラムの部分2箇所に付いては容易に特定できましたが、

• どこから呼ばれていて、どこに影響があるのか？

全く分かりません。

何をしたのか？

そのプログラミング言語には「代入文」という文法が有り、

• 左辺　＝　右辺　と書き、
• 右辺（複数の名前がある）の計算結果を、
• 左辺（1つの名前がある）に代入する
• このシステムの原理原則では、他のやり方で計算結果を代入するやり方は無い

ものですが、全てのプログラムファイルの、全ての「代入文」について、

• プログラムファイル名
• 関数名
• 左辺の名前
• 右辺の名前の内、1つ

の4つ組を作成し*1、
左辺の名前をキーに、並べ替えをして、データの流れの概略を把握し、ー（１）

選択肢表示（コンボボックス）を担当するプログラムの部分付近の名前がどう影響しているかを調べ、ー（２）

「選択肢表示（コンボボックス）を担当するプログラムの部分」とはどこからどこまでを切り出せば良いのか範囲を推定しました。ー（３）

どうなったのか？

範囲が判れば、生かす方のプログラミングの部分をコピーして、無くす方のプログラミングの部分に貼り付けて終わりです。ここまで来れば簡単です。

一応のテスト（動作が変わっていないか）をして、所定の修正をして、指示を出す方に納品しました。

命の危機とは？

通常の単純な修正の日程（＋事情を汲んで2日程度）に差し込んで、（１）〜（３）の対応をしなければならず、

しかも、あやふやも良い所の作業でした。やってもやっても「前と違う」思いが出てきて、思考もキータッチも滑りまくりでした。

こんなにキツいリファクタリングを、進んでやりたいという人が居ると、はてぶなどで見ますが、本当に偉いと思います。

結論

これからも「自由裁量でリファクタリングをしないとならなくなる」事でプログラミングが嫌いになる人は存在し続けることでしょう。

*1:VBAでテキストファイルであるプログラムファイルを1つ1つ読み、Instr$で行の切れ目を見つけ、Mid$で行を切り取り、Print #で出力