Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

Dan Abramovにビジネスロジックを開発させたらできそうなこと

Reactの共同開発者であるDan Abramovが「俺はなんでも知ってるわけじゃない」として書いたブログがある。

overreacted.io

「あれも知らない、これも知らない」という調子で書かれているのだが、じゃぁ(本人が専門分野だと言っているReactやJavaScript、忘れかけているけど昔やっていたC#は除くとして)どれくらいのことは「知っている」のだろう? ウォーターフォール型プロセスで開発するエンタープライズアプリケーションのビジネスロジック開発チームに所属していたとしたら、どういうことができるんだろうか?というのを想像してみた。

まぁJavaScriptやReactのそれこそエキスパートなので、他言語でも「平均的プログラマ以前」みたいなレベルになることはないと思うのだが、それにしてもこれだけのことができる人がビジネスロジックの開発者全体の中にどれくらいいるんだろう?

  • Unix commands and Bash: lscdはふつうに実行でき、実行したい処理の実現方法は調べられる(manは使えてるのか不明)。単純な内容であればシェルスクリプトを書ける。パイプも使えるので、コマンド間の連携のために都度テンポラリファイルを作るような変なスクリプトを書いてくることはないだろう。
  • Low-level languages: Cでポインタを使った簡単なプログラムが読み書きできる(これは任意サイズの多次元配列が扱えるるということなので結構大きい。)。mallocは使えない。入出力用のデータ領域が引数で渡されてくるような関数なら書けそう。
  • Networking stack: IPアドレスというものがあること、DNSでホスト名称とIPアドレスを対応させていることは分かっている。「ブラウザのアドレスバーにURLを入力したときに何が起こるか」の最初の部分は分かっているので、「なんか開発環境がインターネットに繋がらないんです」みたいなことは言ってこないだろう。
  • Containers: これについては特に知識はなさそう。
  • Serverless: これについては特に知識はなさそう。
  • Microservices: これについては特に知識はなさそうだが、むしろ「多数のAPI間の相互呼び出しなだけでしょ?」ということを理解しており、利点も欠点もあるだろうと考えている(過度な期待を持っていない)点に好感が持てる。
  • Python: 不明瞭な点が多いが「数年間使っていた」ということなので、パッケージ管理にはpipコマンドを使うというくらいは知っているのでは?
  • Node backends: DBMSへのアクセスはしたことがないが、Expressを使って単純なサーバを作ったことはある。開発環境の構築を一部お願いするくらいはできそう。
  • Native platforms: Objective Cを触ったことがあるということなのでMac上でのiOS向け開発環境について多少は知っていると思われる。JavaC#からの類推で行ける範囲なら大丈夫そうという程度なので、簡単なビジネスロジックの読み書きはできるだろうが、開発環境の構築とかは逆に難しいかも。
  • Algorithms: バブルソートクイックソート、グラフの走査(おそらく深さ優先とか幅優先とか)程度の複雑さの処理を手書きできるので、業務色のない共通的な処理も書けそう。「二重ループにすると計算量はO(n2)」ということが理解できているので、計算量が爆上がりするような処理を書いてくる心配もしなくてよさそう。
  • Functional languages: Clojure、Elm、OCamlのコードを何とかでも読むことはできる(これだけでもちょっとすごいのでは?)
  • Functional terminology: MapReduceの概念を分かっているので、MapReduceを使っている箇所で「何に困っていてどうしたいのか」は理解できる(MapReduce?何それ?という人、いっぱいいるのでは?)。
  • Modern CSS: FlexboxとかGridを使っていない、モダンでないCSSなら書ける。
  • CSS Methodologies: 上記と同様で、生のCSSなら書ける。
  • SCSS / Sass: 上記と同様で、生のCSSなら書ける。
  • CORS: 特に知識はなさそうだが、少なくともCORSという制約があること、HTTPヘッダに設定をする必要があるということは分かっている(つまり、何が原因でCORSのエラーが起こっているのか分からず、アプリケーションのコードに変に手を入れたりする心配はない)。
  • HTTPS / SSL: これについては「暗号化している」という以上の知識はなさそう。
  • GraphQL: クエリを読める!
  • Sockets: これについては特に知識はなさそうだが、(WebSocketかそれとも生のSocketsかは分からないが)リクエスト/レスポンスというモデル以外に通信の方法があるということは知っている。
  • Streams: Rx Observablesは分かる。
  • Electron: これについては特に知識はなさそう。
  • TypeScript: 読めるけど書けない。
  • Deployment and devops: FTPでのファイル送受信、OSのプロセスに関する理解や、プロセスをkillコマンドで強制終了させる方法は分かる。ps auxkillする対象のPIDを調べたりもできそう。
  • Graphics: これについては特に知識はなさそう。

システム開発に使用する言語の習得にかける時間の例

まったくの素人から平均的プログラマとなるまでの時間*1の他に、システム開発への採用可否を判断できるまでにはどれくらいの時間が必要か?というのもある。

全く見ず知らずの言語をシステム開発に採用するのはリスクが高い、一方で言語に完璧に精通してから開発を始めたのでは「達人にでもなるのを待ってから戦場に出るつもりか?」*2または「ベトナムに行く前に戦争が終わっちまうぞ」*3になってしまうので、じゃぁ世の中を見渡すとどれくらい学習した事例があるのか?というのを書いていく場所。

  • The Economistのコンテンツ配信技術をGoで刷新する際、「最初の数ヶ月はGoの習得に費やし」た。*4

*1:https://satob.hatenablog.com/entry/2023/12/11/014522

*2:三浦建太郎ベルセルク

*3:フルメタル・ジャケット

*4:日本語訳 https://www.infoq.com/jp/articles/golang-the-economist/ だと最初の数ヶ月を純粋にGoの習得だけに費やしたように読めるが、原文 https://www.infoq.com/articles/golang-the-economist/ だとGoの習得に加えて外部コンサルタントとの協業・チームへの再加入もやっているように読めるので注意が必要

アジャイル型ソフトウェア開発におけるmoving targetという語の初出

アジャイル型ソフトウェア開発はmoving targetを撃つためのプロセスだ」と大学で習った覚えがあるんだが、初出がパッと出てこなかったので調べた。

まず検索に引っかかったのが、Koppensteiner, S. & Udo, N. (2003). Will agile development change the way we manage software projects? Agile from a PMBOK® Guide perspective. Paper presented at PMI® Global Congress 2003—North America, Baltimore, MD. Newtown Square, PA: Project Management Institute. *1

で、そこで引用されているのが、Economist (2001, Sep 20), Agility Counts, The Economist*2で、今のところ調べた範囲ではこれが初出ではないだろうか。

情報システムにおける「排他処理」のバリエーション

一言で「排他処理」と言っても、Javaで実装したWebシステムで「排他」というキーワードに関連する処理を考えただけでもこれだけある。初学者はこれらがごっちゃになることも多いんじゃないかと思うのだけれど、こういう切り口でノウハウをまとめた書籍とかってないんだろうか?

DBMSの話

  • トランザクション分離レベル
    • READ COMMITTEDやREPEATABLE READなど、分離レベルごとのDirty ReadやNon-Repeatable Readの有無の指定。DBMSインスタンスやセッション等の単位で指定する。DBMSの製品ごとに、デフォルトの分離レベル、READ UNCOMMITTEDの指定可否、クエリ単位での指定可否などが異なる。
  • 行ロック
    • SELECT FOR UPDATEなど、DMLDDL実行時のロック指定。同じようなクエリを実行しても、DBMSの製品ごとに取得されるロックの強度が異なる。また製品によってはロックエスカレーションの仕組みがある。
  • テーブルロック
    • LOCK TABLEによるテーブルロック。主にバッチ処理中に処理対象となるテーブルを保護したり、DBAの叩くSQLから保護したりするときに使う。
  • 行ロックやテーブルロック以外のロック
    • 製品ごとにロックのかかる単位が異なる。SQL Serverはロックエスカレーションがあるし、行単位以外にもページ単位でロックがかかったりする*1
    • MySQLl*2PostgreSQL*3にはアドバイザリロックの仕組みがある。

アプリケーション実装方法の話

  • DBレコードの楽観排他・悲観排他の選択
    • 楽観排他・悲観排他それぞれの実装方法の検討も含む。
  • 業務処理の設計時に考慮する業務閉塞処理やバッチウィンドウの分離
    • 夜間バッチのバッチウィンドウ設計の際に、同じリソースを使うバッチを同時に走らせない設計をする場合などがこれ。

アプリケーションフレームワークの話

  • DBレコードの楽観排他
    • 楽観排他処理の実装にJPA@javax.persistence.Versionを使う場合など。
  • リソース分離

言語処理系の話

  • 処理系組込みの同期化機構
    • Javaだとsynchronized
  • プロセス内の並行処理用のライブラリ
    • Javaだとjava.util.concurrent.ConcurrentHashMapなど。
  • 言語処理系のライブラリにおける同期化有無
    • JavaだとHashMapVectorの違いなど。
  • 言語処理系がライブラリとして提供するプロセス内同期化機構
    • Javaだとjava.util.concurrent.Semaphoreなど。
  • 共有リソースの分離
    • 複数プロセスから参照可能なリソースの分離。一時ファイル名を一意にする際にFiles.createTempFile()を使用するなど。

ミドルウェアの話

  • リクエスト窓口制御による直列化
    • TomcatMaxThreadsを1にするなど。
  • トランザクションごとのリソース分離
    • OLTPモニタにおけるSYSOUTデータセットの書き込み先ファイルの分離など。
  • アプリケーションサーバによるセッション分離
    • HttpSessionによるセッション単位の分離、ThreadLocalによるスレッド単位の分離など。

OSの話

  • プロセス多重起動禁止
    • .NETではSystem.Threading.Mutexを使う例が多いけど、Javaだと何かあるかな。
  • OSによるプロセス間の排他制御
  • OSのファイルロック
  • 共有リソースの分離
    • 複数プロセスから参照可能なリソースの分離。出力ファイル名を一意にする際にユーザIDやUUIDを使用するなど。

ソフトウェア工学分野における知識体系

satob.hatenablog.com

私が大学の頃に授業で紹介されていたComputing Curricula 1991 (CC91)は、その後2005年にComputing Curricula 2005 (CC2005)*1、2020年にComputing Curricula 2020 (CC2020)*2として改訂が行われている。内容も年を経るごとに大幅に拡充されており、CC2020ではその下にいくつかの分野(Computer Engineering, Computer Science, Cybersecurity, Information Systems, Information Technology, Software Engineering)に分かれたカリキュラム(Volume)があり、それぞれの分野ごとにカリキュラムが検討されている*3。たとえば計算機科学分野(Computer Science)では、CS2020の下にはCS2013 (Computer Science Curricular Volume)があった。現在はComputer Science Curricula 2023*4がベータ版として検討されている。

さて我らがソフトウェア工学分野はというと、CC2020から参照されている学部生向けのSoftware Engineering 2014 (SE2014)*5からその後更新はされていないように見える。院生向けにはGSwE2009*6があるようだ。

またこれとは別に、ソフトウェア工学に関する知識体系というとSWEBOK*7が思いつく。SE2014を策定する際もSWEBOKを参照しているようだ。SWEBOKはV3が最新版で、現在V4がパブリックプレビューに入っている。なおV3は日本語訳も出版されているが、Amazonには翻訳の質を問題とするレビューが並んでいる*8

また、ソフトウェア工学を含む領域としてシステム工学(Systems Engineering)を考えることもできる。今回調査して知ったのだが、ACMIEEEがまとめているわけではないが、BKCASEという組織がシステム工学に関する知識体系であるSEBoKを作成しているようだ*9。もちろん「システム工学」が対象なので、情報システム以外のシステム工学分野、たとえば医療システム分野の内容なども含まれているようだ。

なお、CC91や2005の影響を受けて日本ではどのような検討がなされているか?という点についてだが、まず1999年に情報処理学会が「大学の理工系学部情報系学科のためのコンピュータサイエンス教育カリキュラムJ97」*10を作成した。これもCC同様に改訂がされており、カリキュラム標準J07*11、カリキュラム標準J17*12が公開されている。CCと同様に、こちらも分野ごとに分かれた検討がされている。シラバスには日本語で参照できる参考文献が記載されており、学習の際の参考にできる。上記を受けた動きとして、文部科学省も「超スマート社会における情報教育の在り方に関する調査研究」*13をまとめている。

これらのまとめについて、日本語だと以下のページが概観によいだろう。 zenn.dev