Scribble at 2023-01-24 17:11:45 Last modified: 2023-01-24 17:39:05

添付画像

Why developers should be force-fed state machines

"Why Developers Never Use State Machines" (https://skorks.com/2011/09/why-developers-never-use-state-machines/) というブログ記事も同時に読むといいようだ。なぜか記事で使われてる画像が 404 Error で何のこっちゃ分からなくなっているが、画像なんて主旨を理解するのにどうだっていい。

僕は日本のコーダやプログラマには数学やコンピュータ・サイエンスの素養が欠落しすぎていると言ってきた。それゆえ、何かアイデアを思いついても実現する手立てをシステム開発として形にすぐできないという弱点がある。とにかく最近の日本のエンジニアはインド人や中国人と比べても、やること為すことが全て遅い。でも、数学やコンピュータ・サイエンスの知見をアホみたいに習った数時間後に現場で使えなんて言ってない。それは、学校で作り方を教えられたまんま、レモネードを放課後に自宅の庭先で販売するアメリカのガキみたいなもんだ。まぁアメリカ人はそれを気軽にやるからこそ生産性が高いとも言えるんだけど(失敗したやつは、首を切ったりコミュニティから排斥して国や会社の「歴史」から抹消すればいいだけだからである)。ということで、state machine をアイデアとして参考にするのはいいとして、教科書に書いてあることをそのまま実行して成功するなんて状況に生きてる方が、おめでたいやつってわけだ。

とは言え、もちろん有効なところと限界とを理解しつつ使うのは何も問題ない。反論として紹介したブログ記事で「言ってることには賛同だが、実際には一度も使ってない」なんていう、つまんない「おま環」が何の反論にもなってないのは明白だ。それは、お前が状態遷移のアイデアを即座にメモ用紙にすら書いてものを考えられない無能だからにすぎないんだよ。というわけで、僕はもともと有言実行だし、他人にやれと言ったことは自分が既にやってる人間なので、当たり前だがウェブ・アプリケーション開発でも UML として状態遷移ダイアグラムくらい運用してきたし(一例として、画像にしたものを上に添付しておく。もう10年以上は前の案件だ。ガラケーのサイトで音楽を検索するシステムを作ったときの設計図の一つである。このとき、初めて仕事で Python を使った)、クライアントに資料として何度か納品物の体裁で提出して、それに見合った設計費もいただいている。実際、状態遷移ダイアグラムなんて難しくもなんともない。ものごとを「きっちり」やりたいという、誠実さみたいな偽善・欺瞞よりは、寧ろ自分勝手でもいいから欲求がありさえすればいいからだ。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook