新・日々録 by TRASH BOX@Eel このページをアンテナに追加 RSSフィード

2017-02-25

diruseの出力結果をCSV形式に加工する

HDDをあさったら、古いプロトタイプ・コードが見つかった。ちょっと晒してみる。

今は不明だが、かつてWindowsサーバの管理用にdiruseというコマンドがあった。Unixのduのように指定したフォルダのディスク使用量を表示するツールで、その昔はWindows Serverのリソースキットに付属していた。私がdiruseに遭遇した頃には、Microsoftのサイトからダウンロードして使用するようになっていた。

このツールが吐き出す出力をCSV形式に変換する必要が生じた。Windows Server 2003 R2上で変換したかったのだが、本番環境で使用可能なスクリプト環境がWSHしかなかった。そこでJScriptプロトタイプを実装してみた。

それがこのコードだ。

/*jslint continue: true, indent: 2, maxerr: 50, windows: true */
WScript.Quit((function () {
  'use strict';
  var print = function (s) { WScript.Echo(s); },
    stdin = WScript.StdIn,
    line,
    fields;

  print("Size,Files,Directory");
  while (!stdin.AtEndOfStream) {
    line = stdin.ReadLine();
    fields = line.split(/\s+/);

    if (fields.length < 4) {
      continue;
    }
    if (fields[2] === "SUB-TOTAL:") {
      print([
        '"' + fields[0] + '"',
        '"' + fields[1] + '"',
        line.slice(line.indexOf(fields[3]))
      ].join(","));
    }
  }

  return 0;
}()));

diruseからパイプ経由で出力を受け取る前提で、標準入力からの入力にのみ対応している。

フォルダ名を取得する所だけ少し変わったことをしている。というのもフォルダ名に空白文字が含まれているとその部分も「line.split(/\s+/)」で分割されてしまい、fields[3]には不完全なパス文字列しか格納されないのだ。

ところで、diruseはフォルダ名に日本語が含まれていると使い物にならなかったのだが*1サーバ上でで少しばかり特殊なアクセス権限を付加していたフォルダでも正常に使用量を取得できた唯一のツールだったため、捨てることができなくて困ったものだった。あれから、どうなったのだろうか?

*1Windows Server 2003 R2にて確認。

2017-02-11

プログラミング初心者向けに「環境構築の容易さ」をアピールしてはいけない

一言述べておかなければ。

「最初に学ぶべきプログラミング言語」 - mizchi's blog

プログラミング言語の「売り」として、プログラミング初心者向けに「環境構築の容易さ」をアピールするのは止めた方がよい。

だって、それをするなら、WindowsユーザにはPowerShellを、macOSユーザにはAWK/Perl 5/PHP 5.6/Python 2/Ruby 2.0.0/Tcl 8.5あたりを推奨すべき、という話になってしまう。どれも各システムにデフォルトで用意されている*1ので、環境構築など不要だ。究極の「環境構築の容易さ」ではないか。

百歩譲って、「macOSユーザ向けに挙げた言語って、どれも処理系だけで、IDEとかエディタとか無いじゃないか」という批判を甘んじて受けるとしよう。

では、予めREPL*2も簡易IDE*3も用意されているPowerShellはどうなるのだ――という話になる。

だが、だがしかし、しかしながら、PowerShellVBAと同じ枠で扱われていて、コマンドリファレンスや、やりたいことからの逆引きリファレンスは見つかるが、PowerShellを「立派なプログラミング言語」と見なしてプログラミング入門するような本に遭遇した記憶がないのである。少なくとも日本国内では*4

うん、だから「環境構築の容易さ」をアピールするのは止めようよ。PowerShellの境遇に涙が出らぁ。

追記:2017-02-13

AppleScriptを忘れてた! macOSには標準で「スクリプトエディタ.app(AppleScriptエディタ.app)」が付いてくる。「エディタ」という名前とは裏腹に、AppleScript用の簡易的な開発環境だ*5。だが、PowerShell以上に碌な和書が見つからない。

熱心に情報発信している人BOOTHで電書を出している人の情報が頼りだ。

*1PowerShellWindows 7以降の話。macOSユーザ向けに挙げた言語のバージョンは、macOS 10.12で確認したもの。

*2:スタートメニューから起動できる、PowerShellのコンソールのこと。

*3Windows PowerShell ISEのこと。

*4:海外の反応は知らない。

*5:OS X 10.10 Yosemite以降ではJavaScript 1.1も使えるが、あくまでも「JavaScript 1.1仕様の言語でシステム自動化のコードが書ける」というだけなので注意(Webクライアントサイド開発に使える訳ではない)。WSH(Windows Script Host)でJScriptを使えるがWebクライアントサイドのコードは実行できない、というのと同じである。

2017-02-04

正しいフローチャートの書き方

1月以上経っているから、もう書いてもよいかな。

若手プログラマー保存版!フローチャート徹底解説と作成カンニングペーパー

これは、日本ではあまり知られていないことなのだが、普段私たちがプログラミング教育で目にするフローチャートや、または「フローチャート」と聞いて思い浮かべるもの――JIS X 0121-1986の「情報処理用流れ図・プログラム網図・システム資源図記号」とかを使って手続き型のアルゴリズムを表現したようなアレは、少なくとも実務向けのツールとしては、40年ほど前にdeprecatedになっている。

フローチャート業界(!)では1975年パラダイムシフトが起きており、それ以降に推奨される「近代的なフローチャート」は、私たちが思い浮かべるソレとは似ても似つかないものとなっている。

具体的には、例えば次のような図だ。

f:id:eel3:20170204205811p:image

石を投げないで! その前にお茶でも飲んで落ち着いて、『人月の神話【新装版】』を買うか借りるか本棚から取り出すかして「第15章 もう1つの顔」の「フローチャートの呪い」を読んで、それでも投げたければ私だけでなくフレデリック・フィリップスブルックス・ジュニア*1にもお投げなさい

私たちがプログラミング教育で目にするようなフローチャート――仮にこれをフローチャート 1.0と表記し、上図のような「近代的なフローチャート」をフローチャート 2.0と表記するとしよう。

フローチャート 1.0の表現力は、手続き型の高水準言語とほぼ同等だ。

H・H・ゴールドスタインとJ・フォン・ノイマンによって発表されたときには(文献1)、小さな箱やその中の内容があたかも高水準言語として機能し、不可解な機械語ステートメントを意味のあるまとまりにしたものだった。

フローチャート 1.0の起源は、1947年の非公開レポート "Planning and coding of problems for an electronic computing instrument" になる*2。レポートの作者はハーマンハイネ・ゴールドスタイン*3ジョン・フォン・ノイマン*4だ。

1947年といえば、高水準言語どころかアセンブラさえ影も形もなかった時代だ。世界初の高水準プログラミング言語となるFORTRANは、ドラフト仕様の作成が1954年、マニュアルのリリースが1956年コンパイラのリリースが1957年だ。で、おそらく世界初のアセンブラはEDSACのもので、1949年5月に稼働し始めたようだ(Wikipedia調べ)。フローチャート 1.0が歴史の表舞台に現れたのは、アセンブラ誕生の2年前だ。

このような歴史的経緯を考えると、高水準言語が無かった頃や、高水準言語がまだ普及していなかった時代には、高水準言語と同程度の表現力をもつフローチャート 1.0は有用ツールだったといえる。機械語アセンブラでは直接書き下すことができない、一段上の抽象度でシステムを表現した、いわば「システムの設計図」の役割を担っていたのだ。

――が、しかし、逆に言えば、高水準言語全盛期である現代に、同程度の表現力しかもたないフローチャート 1.0は不要だ。わざわざフローチャート 1.0を書いたうえで高水準言語で書き直すぐらいなら、最初から高水準言語で書いてしまえばよい。これは、フローチャート 1.0だけではなく構造化チャートの類でも同じだ。

この辺りの疑念は、早い人ではFORTRAN誕生前後にすでに抱いていた。『人月神話』の記述によれば、ケネス・ユージン・アイバーソン*5からの1957年私信にて、フローチャート 1.0と高水準言語の表現力についての指摘がなされていたようだ。

アイバーソンが早い時点で気づいたように(文献2)、系統立った高水準言語ではそうしたまとめがすでになされており、それぞれの箱にはステートメントが入る(図15・2)。そこでもう箱自体、下書き段階での退屈で場所ふさぎな用途以外の何ものでもなく、削除してしまった方がよい。

(中略)

だから、リストに矢印を書き込むことにして、フローチャートはすっかりやめてしまった方がよいだろう。

つまるところ、高水準言語が広まったことにより、フローチャート 1.0は(実務向けのツールとしては)役目を終えたといえる。*6

ただし、「フローチャート 1.0が役目を終えた」という事実は、「フローチャートそのものが役目を終えた」ということを意味しない。なぜならば、高水準言語で短く簡潔に書くことが難しい抽象度の事象を描いたフローチャート 2.0は依然として有用だからだ。

先に挙げた図のようなフローチャート 2.0について、『人月神話』にはこう書かれている。

現実のプログラムに関する1ページのフローチャートは、本質的にプログラム構造および局面または段階を示した図になる。その点に関しては非常に便利なものだ。図15・1は、そういうサブプログラム構造図を示している。

当然のことながら、このような構造図は苦労して作り上げられたANSIのフローチャート基準に従うことも、それを必要とすることもない。箱形、コネクタ、番号付けなどに関する規則はすべて、詳細なフローチャートを理解しやすくするためにだけ必要なのだ。

要するに、システム設計用の、抽象度の高い事象を記述するためのツールとしては、フローチャート 2.0の寿命はまだ尽きていない。また、フローチャート 2.0ではANSIやJISの記号を使う必要はない。

人月神話』で挙げられているプログラム構造図や、「UMLフローチャート」とも噂されるアクティビティ図は、いずれもシステムの一局面について、高水準言語では直接書き下すことのできない抽象度で表現するためのツールだ。自由度が高すぎるフローチャートに「明確な役割」と「役割に基づく制約」を設けたことで、より扱いやすいツールとなっている。それらを書く時に使用する記号はシンプルで、ANSIやJISのフローチャート用記号のような数が多くて複雑な代物ではない。

もちろん、システムのすべてをフローチャート 2.0のみで記述・設計することは難しい。しかし、それをいったらDFDや状態遷移図/状態遷移表などの他の記法だって同じだ。

構造化モデリングではイベントリスト・コンテキストダイアグラム・DFD・状態遷移図・構造図などの複数の記法を用いるし、オブジェクト指向分析・設計で用いるUMLは複数の表記法UML 2.0で13種類)をまとめたものだ。すなわち、たった一つでシステムの全ての側面を記述・表現できるような、便利な記法は存在しない。どの記法も一長一短があるので、用途に応じて記法を使い分けよう――というのが現実解だ。

だから、フローチャート 2.0で記述できない事象について、フローチャート 2.0を責めるのはお門違いというか、そこを責めるのなら「お前それアクティビティ図でも同じ事言えんの?」と茶化される覚悟はしておいたほうがよい。

アクティビティ図でアクターの操作を記述できなくても、誰もアクティビティ図を責めないどころか、むしろ「いやいや、そこはユースケース図でいきましょうよ」となるはずだ。これがフローチャート 2.0になると、途端に「フローチャートじゃ書けないものがあるし……」という態度をとる人がいる。

そう言ってしまう前に、冷静になって、フローチャートをアクティビティ図に入れ替えて考えてみるべきなのだ。「アクティビティ図じゃ書けないものがあるし……」って、どう考えても当たり前だ(アクティビティ図で全て表現できるというのなら、UMLの残りの記法は何なのか……)。フローチャート 2.0も同じだ。

だいたい、フローチャート 2.0とUML 2.0の戦力比は1対13なのだ、記法の数的に。だから、「フローチャート 2.0の表現力はUML 2.0の13分の1ぐらい」と考えておけばよろしい。で、フローチャート 2.0で苦手なものは、別の記法で書けばよい。

フローチャート 1.0は戦力外だが、フローチャート 2.0はまだ生きている。まあ、フローチャート 2.0は、フローチャートという名前よりも「プログラム構造図」とか「UMLのアクティビティ図」とか、それぞれの方向に特化した別名のほうがしっくりくるのだが。

ともかく、フローチャート 1.0とフローチャート 2.0の区別をつけた上で冷静に議論できる人が増えることを祈るばかりである。

さて、一通り書き終えたから、状態遷移図と状態遷移表とシーケンス図の教育用サンプルでも作るとするか。

*1:『人月神話』の作者。念のため。

*2:「プログラミング向けのフローチャート」という視点では、これが起源だといえる。フローチャート一般としては、それ以前に起源があるようだ。

*3:『復刊 計算機の歴史 ―パスカルからノイマンまで―』の作者。ENIACの開発プロジェクトのメンバーで、のちにIBMにてコンピュータ開発に関わった。

*4:「ノイマンコンピュータ」のあの人。

*5プログラミング言語APLの創案者。

*6プログラミングの初等教育用のツールとしては、まだ役目が残っている気がするが……コンピュテーショナル・シンキングの方面を含めて、教育方法やツールが現在進行形で進化しているので、もうそろそろオワコンになる気がしないでもない。

2017-01-29

シェルスクリプトを本気で学びたい人のための10冊

シェルスクリプトについて、プログラミング言語一種としてガッツリ学んだうえで、しかし得手不得手を見極めて、無理せずシェルスクリプトらしい使い方にとどめて日々を過ごしたい人のための10冊を選出すると、だいたいこんな感じとなる。

前提として「他の言語でのプログラミング経験あり」「コンソール/ターミナルに多少なりとも慣れている」人が対象。

あえてサンプル集的な側面の強い本は外している。『UNIXシェルスクリプト マスターピース132』とか、古いけど『UNIXシェルスクリプト逆引き大全333の極意』とか、便利なんだけどね。

便利なんだけど、いや、便利であるがために、他のプログラミング言語経験者がシェルスクリプトについて理解を深めずにサンプル集片手にスクリプトでっち上げて痛い目に遭い、後でシェルスクリプト固有の諸々について「落とし穴」的に語ったりまとめ資料を作ったりするのは、なんというか、気持ちは痛いほど分かるけど、でも少々非生産的ではないだろうか?

私は基本的にCプログラマで、Javaについては素人なのだけど、Javaについて深く学ぶことなく徒手空拳で突き進んでコードを書いたら地雷を踏み抜く自信がある。シェルスクリプトも同じだ。言語が違う≒在り方が違うのだから、そのあたりをしっかり学んでおかないと、自分で自分の足を打ち抜いてしまっても文句は言えない。

(まあ、最近のモダンプログラミング言語と比較すれば、色々とアレなのは確かだけど……でもね、大抵の環境の/bin/shのもとになったBourne Shell1977年生まれで、今年で40歳なのよ。それぐらい大昔の、まだ言語設計もシステム開発技法も未成熟だった時期に、プログラミング言語ではなく「プアな環境でも問題なく動作する、プログラマブル対話型コマンドインタプリタプログラミング言語とは「野球とソフトボール」ぐらいの違いはあると思う〕」の一種として開発された代物だってことを理解した上で批評してほしいなあ。言語設計の研究が進んだ2017年現在のプログラミング言語観点で批評されても、「なら後継のシェルとか、Perl以降のスクリプト言語とか、モダンツールを使えばよいのでは?」としか言えないっす)

『入門UNIXシェルプログラミング 改訂第2版』

「言語としてのシェルスクリプト」に四つに組んで取り組むなら、「最初の1冊」としてこれなんかがオススメ。定番書ですな。

/bin/shを使い、それなりに汎用性に気を配った、オーソドックスなシェルスクリプトの書き方を基礎から学ぶのに適した本だと思う。意外と長く付き合える1冊だ。

UNIXプログラミング環境』

若干の古臭ささえなければ(あと絶版じゃなかったら)真っ先に「最初の1冊」として挙げたかった本。

UNIXプログラミング環境 (海外ブックス)

UNIXプログラミング環境 (海外ブックス)

以下の3章は必見で、シェルスクリプトの書き方として非常に参考となる。21世紀の現在でもほぼそのまま通用してしまうあたりが凄いというか恐ろしいというか。

個人的には、恥かしながら数年前に本書でこんな書き方があることを知った。

#!/bin/sh

for i; do
    echo "$i"
done

シェル関数でも使える。実際に使用する機会は少ないものの、ちょっと興味深い。

シェルプログラミング実用テクニック

シェルシェルスクリプトを使って仕事・作業をこなす」とはどういうことなのか学ぶのに最適な1冊。

他書でシェルスクリプトの言語的側面を学んだ後で、「じゃあシェルシェルスクリプトで何をするべ?」となった時に読むと、非常に効果がある。

本書や『フルスクラッチから1日でCMSを作る シェルスクリプト高速開発手法入門』などは、シェルスクリプトの「無理しない範囲での可能性」を学ぶのにちょうど良い。無理な使い方をしなくとも、意外に広い可能性をもつツールであることに気がつくはずだ。

『実践ユニケージ開発手法

Open usp Tukubaiアリアリなら、この3冊は欠かせない(ただし3冊全てとは言わない。レベルに応じて買うべし)。

コマンド学習編

ユニケージでよく使うコマンドの解説がメイン。

「よく使うコマンド」というグルーピングなので:

  • Unix環境の標準的なテキストフィルタも載っている。
  • Open usp Tukubaiには含まれていない(商用版にのみ存在する)コマンドも載っている。
  • 一方で、Open usp Tukubaiのコマンド全てが網羅されている訳ではない。

実行例が豊富なので、Open usp Tukubaiコマンドマニュアルよりも分かりやすいと思う。

あと第2章のAWKの解説は秀逸。ワンライナー(一行野郎)としてのAWKの魅力を引き出している。

シェルスクリプト学習編

「ユニケージらしさ満載のシェルスクリプトの書き方」を学ぶための本。

「制御構文の説明が後回しになっている」とか、「シェル関数説明が存在しない」とか、ユニケージの芳醇な香りが楽しめる。うん、徹底してるよね。

Webアプリケーション

シェルスクリプトCGIするための本。

古き良きCGI時代の手法HTMLのフォームによるPOSTを受け取り、HTTPレスポンスで返す「HTTPヘッダ+HTML文書」のテンプレート文字列に必要なパラメータを埋め込んで出力する方法)を、ユニケージのコマンドを使ってシェルスクリプトで実現する方法について書かれている。

あとは、JavaScriptを併用しての古典的なAjaxについても扱っている。といっても、クライアントサイドのHTTP POSTをJavaScriptXMLHttpRequestから行うようにしただけで、サーバサイドはCGI(もちろん実装はシェルスクリプトで!)のままだが。

クライアントサイドもサーバサイドも、昨今のWeb開発ではほぼ確実に利用されるだろうライブラリフレームワークの類を一切使用しないというスパルタぶりである。というかHTTPヘッダとかサーバサイドが吐き出すHTMLとか、そういう下回りのことをある程度知った上で開発する――という想定で書かれている。

あとサーバサイドのセッション管理の話も無かった(セッション管理自体は、シェルスクリプトによるCGIでも可能。シェルスクリプトによるCGIのセッション管理 - Qiitaを参照)。

結局のところ、開発対象として「社内LANイントラネット)からのみアクセスされる前提の、アクセス数がそれほど多くはない、長期運用前提の業務システム」を想定しているので:

  • 社内LANだから、別途ユーザ認証/アクセス制限されてるはず→セッション管理なし。
  • 社内システムだから、コンシューマ向けWebアプリほどのアクセス数はないだろう→CGI選択
  • 長期運用前提で、一度土台を作ったら、後は必要に応じて都度継ぎ足す感じに「保守・機能追加」で対応→まだ決定的なライブラリフレームワークが無いから、使わずに頑張る。

――みたいな感じなんだろう。

Windows/Mac/UNIXすべてで20年動くプログラムはどう書くべきか』

『実践ユニケージ開発手法』とは打って変わって、「POSIXに忠実に行こう」路線の本。

……この本はこの本で、ユニケージとは違う方向で突き抜けた感があるなあ。

すべてのUNIXで20年動くプログラムはどう書くべきか デプロイ・保守に苦しむエンジニア達へ贈る[シェルスクリプトレシピ集]』の改訂版みたいなので、旧書のほうでもよい(が、本書のほうがより先鋭化している)。私はどちらも持っている。

先に挙げた『入門UNIXシェルプログラミング 改訂第2版』も、そこそこポータブルなシェルスクリプトを志向しているのだが、今となっては本書のほうが「よりモダンな」ポータブルなシェルスクリプトを書くための参考書だと思う。

プログラミング言語AWK

シェルスクリプトで使われることの多いAWKは、アレはアレで1つの言語なこともあり、なにか1冊持っておくと重宝する。

プログラミング言語AWK

プログラミング言語AWK

何度か絶版しているAWKの名著。私は新紀元社版を持っている。

AWKの本は色々あるものの、簡易なRDB(関係データベース)を作ったり、ミニ言語を実装したり、再帰下降パーサでAWKのサブセットを書いたり、深さ優先探索でmake(1)もどきをこしらえたりするトンデモ本誤用)は本書だけだ。

本書か、あとは『AWK実践入門 (Software Design plus)』あたりがオススメ。こちらもAWKでパズルを解いたり後置記法の数式電卓を作ったりしている。AWK本はどいつもこいつもこんな調子なような気がする*1

sed & awkプログラミング 改訂版』

sed(1)はとっつきにくいツールなので、手元にドキュメントがあると助かるのだが……。

sed(1)についてガッツリ解説している日本語の本は、これ1冊しか知らない。

sed(1)はこれでもチューリング完全な言語だ。sやdだけでも便利だが、aやiも(例えばフィルタの出力に後からヘッダー行やフッター行を付けたい時などに)役に立つし、グループ化・ホールドスペース・フロー制御などの禁断の果実も用意されている。

まあ、sed(1)でちょっと複雑なことを実現しようとすると、途端にスクリプトの中身が呪文と化してしまうので、健康のためにも深入りは避けたほうがよいのだが――しかし禁断の果実に魅了されて木乃伊になる木乃伊取りは後を絶たない。m4(1)と同じくらいに好事家を惹きつけてやまないツールだ。

sed & awkデスクトップリファレンス

この本は隠れた名著。『sed & awkプログラミング 改訂版』とは別に揃えておくべき本だ。

なにが良いかっていえば、「1.3 Unixプログラム別メタキャラクタサポート状況」。よくある正規表現メタキャラクタについて、ed・vi/ex・sed/grepawk/egrepそれぞれで使えるか否か一覧表になっている。

私は、どちらかといえばvimを使う派なので、vimgrep/sedawk・その他(Perl風の正規表現が使えるツール)でメタキャラクタを取り違えることがある(例:「しまった、『?』はsed(1)では使えなかった……」)。そういう時に本書を参照している。

シェルスクリプトでは正規表現を用いることも多い。正規表現自体は『詳説 正規表現 第3版』や『正規表現クックブック』などの良書があるが、伝統的なUnixテキストフィルタ正規表現方言をカバーしているのは本書か『Windows/Mac/UNIXすべてで20年動くプログラムはどう書くべきか』あたりぐらいだろう。

まとめ

陰に陽にユニケージ勢の影響を受けたリストですな。まあ、ここ数年のシェルスクリプト界隈の盛り上がりの立役者だからなあ。

*1:『AWKを256倍使うための本 (Ascii 256倍)』でもパズルゲームを作っているし、『sed & awkプログラミング 改訂版 (A nutshell handbook)』もm4(1)もどきの簡易なマクロプロセッサがあるし……。

2017-01-21

量産型プログラマとそれ以外のプログラマの違いはどこにあるか?

ふむ。

量産型プログラマを撲滅したい ? kuranuki ? Medium

最近、量産型プログラマに遭遇したのだが、彼らを観察しているうちに、量産型プログラマとそれ以外のプログラマとでは、次の点に違いが見られることに気づいた。

  1. ソースコード・ドキュメント・「『デバッガ上でのプログラムのふるまいや、テストデータを食わせた時の挙動』の観察から得られた知見」などから、対象システムについての一貫性のあるメンタルモデル/概念モデルを、頭の中に構築することができるか否か?
  2. 頭の中に構築したメンタルモデル/概念モデルが、実際のシステムと比較して、妥当なものであるか否か?
  3. 頭の中に構築したメンタルモデル/概念モデルが、実際のシステムのそれなりの範囲をカバーしているか否か?
  4. 頭の中に構築したメンタルモデル/概念モデルに基づいて、理路整然と議論や推測を行うことができるか否か?
  5. 頭の中に構築したメンタルモデル/概念モデルを、ソースコードやドキュメントという形態に変換出力できるか否か?

量産型プログラマ」と言われる人は、上記5項目の多く(時には全て)において、何かしらの問題を抱えているように見える。

例えば、先の記事のこのあたり:

ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。

まず、エラーメッセージを見ない。動かないってことは、どこがおかしいかわからない。パラメータを変えてみたり、手をいっぱい動かす。なんとなく勘で直そうとする。動いたから良いじゃないか、と考える。

量産型プログラマは、対象システムについてのメンタルモデル/概念モデルを構築しようとしないか、もしくは構築することができない。つまり、デバッグの時、先にメンタルモデル/概念モデルという明かりを灯すことなく、暗闇を手探りで突き進もうとする。だから、作業の進め方が行き当たりばったりで、見当違いの方向にフラフラと迷走していってしまうことが多い。

一方、量産型じゃないプログラマは、メンタルモデル/概念モデルを構築した上で、モデルに基づいて理路整然とデバッグしようとする。

例えば通信プログラムで、送信側が送ったデータと受信側で受け取ったデータとで一部が一致しない問題が起きたとする。量産型じゃないプログラマは、例えば:

――といったあたりにモニター(ログ出力やパケットキャプチャ)を仕込んで、問題を再現させて、ログやパケットキャプチャを解析して、どの時点でデータが変化しているか調べることで、バグがあると思われる箇所を絞り込もうとするかもしれない。

(仮に「送信側で、send処理を実行する直前の送信予定データ」の時点で意図せぬ値となっているなら、送信側にバグがある可能性が高いだろう。しかし「受信側で、recv処理を実行した直後の受信済みデータ」まで正しいなら、それ以降に受信側プログラムで行う処理のどこかでデータを壊している可能性が高いだろう。パケットキャプチャの段階で初めて値が壊れているなら、send/recv用のAPIの叩き方を間違えているとか、send/recv用のAPIを提供しているライブラリフレームワークバグがあるとか、いくつかの可能性が考えられるだろう)

すなわち、量産型じゃないプログラマは、その通信プログラムにおける大雑把なデータの流れを把握していて、そのデータフローに基づいて、理路整然と、チェックポイントとして適切な箇所を判断してモニターを仕込もうとするだろう。

これが量産型プログラマとなると、こういった切り分けを一切せずに「送信データと受信データとで、データの一部が一致しないです。どう頑張っても不一致となるんです」という報告を上げる。「いや、そこは問題の切り分けをしようよ……(『どう頑張っても』って、念力じゃバグは直らないよ)」と、量産型じゃないプログラマはため息をつくことになる。

量産型プログラマは、対象システムについて「メンタルモデル/概念モデルを構築し、活用する能力」に欠けている。量産型じゃないプログラマは、メンタルモデル/概念モデルを構築し、活用することで、システムの設計・実装・デバッグなどを進めていく。

(この点は、諸刃の剣でもある。要するに、思い込みに起因する失敗を起こす可能性があるのだ)

私が個人的に興味を抱いているのは、メンタルモデル/概念モデルをめぐる量産型プログラマとそれ以外のプログラマの差異が、どこまで教育で補完できるか、という点だ。

ベテランでも、未経験のプログラミング言語フレームワークで書かれたソースコードに直面した場合には、対象システムについてのメンタルモデル/概念モデルを構築するのに苦労するし、頭の中で構築したイメージをソースコード化するのに難儀するものだ。技術面の知識の有無がモデル構築絡みの作業パフォーマンスに影響を与えるわけだが、この辺は教育でカバーできる余地があるだろう。

では「メンタルモデル/概念モデルを構築し、活用する能力」そのものについてはどうだろうか? この方面の教育や訓練については、まだまだ手探り状態というか、未開の大地であるような気がする。コンピュテーショナルシンキングの一部とかが関係してくるような、そうでもないような……?

現状では、私の周囲の量産型じゃないプログラマは、経験を通じて自然とこの辺の能力を獲得してきた人ばかりだ。なので、少なくとも今までのやり方は、「メンタルモデル/概念モデルを構築し、活用する能力」そのものを育てるという観点では、量産型プログラマが存在するという事実より、あまり成功しているとはいえないだろう。

だから、おそらく、今までとは違うアプローチが必要だと思われるが、まだエビデンスが見当たらないので、効果のほどは定かではない。

たぶん、究極的には、向き不向きがあるのだろうけど――教育でどこまで補完できるのか、仮に補完できるとしたらコストはどの程度なのか(従来のいわゆる「文系プログラマ」が生み出される採用・教育システムにて負担できるコストなのか)。非常に興味深い。