なぜ順次処理は複雑になるのか

現在の派遣先で順次処理のプログラムを扱っている

上から順番に処理が流れていく「ALFER言語」と呼ばれるもの

この仕様書を作っていて、プログラムが非常に読みにくいと感じた

順次処理だから読みにくい

AがBであれば、処理Aに行く

というような分岐があった

これだと、処理Aに飛ばないといけない

内部関数

func(1, 3, 4)のような内部の関数があった

これは、Excelに仕様がまとまっているが、理解しにくかった

なんとか理解できている

ネストが深い

一つの処理を書くのに深いネストが書かれていた

elseの中にさらにif文がネストされていて、最大3階層まで広がっていた

変数の中身がイメージしにくい

代入の演算で、x10 = x10 + x11 というのがあったが、x11に値が入っているのかどうか分からなかった

プログラムというのはそういうものなのかもしれない

デバッグツールで変数の中身を確認しないとなかなか変数の中身はイメージしづらい

チャッピー相談

これまでの内容をチャッピーに相談してみて、この記事を締めたいと思う

チャッピーに相談してみると、まず最初に言われたのはこういうことだった。

順次処理は、人間の思考にとっては必ずしも読みやすい構造ではない。

コンピュータにとっては、上から順番に処理するのが最もシンプルで効率的だ。
しかし、人間の理解という観点では、順番にすべて読まないと全体像が見えないという欠点がある。

例えば、

if A then
    if B then
        if C then
            処理1
        else
            処理2

のような構造があった場合、
人間は「A」「B」「C」の3つの条件を同時に頭の中で保持しながら読まないといけない。

これは心理学でいうワーキングメモリの限界に近い問題で、人間は同時に多くの条件を保持するのが苦手だ。

そのため、ネストが深くなるほど理解が難しくなる。

最近のプログラミングのベストプラクティスでは、次のような考え方がよく使われている。

まず一つ目は、条件を早めに切り出すこと。

例えば次のようなコード。

if A:
    if B:
        処理

これを、

if not A:
    return
if not B:
    return
処理

のように書く。

これを ガード節（Guard Clause） と呼ぶ。

ネストを減らすことで、コードの読みやすさが大きく改善する。

二つ目は、変数の意味を明確にすること。

例えば、

x10 = x10 + x11

のようなコードは、機械には分かりやすいが、人間には分かりにくい。

最近のコードでは、

total_work_time += overtime_minutes

のように、意味のある名前をつけることが重要視されている。

仕様書を書くときも同じだ。

例えば、

x10 = x10 + x11

という処理を仕様書に書く場合、

「x10にx11を加算する」

と書くよりも、

「累計勤務時間に、今回の勤務時間を加算する」

と書いたほうが理解しやすい。

つまり仕様書は、

変数の操作を書くのではなく、意味を書く

というのが重要になる。

三つ目は、処理の単位を分割すること。

最近のソフトウェア設計では、

• 1つの関数は1つの責務
• 処理は小さく分割する

という考え方が基本になっている。

しかし、古いシステムや業務システムでは、

• 一つの処理にすべての条件が詰め込まれている
• 分岐が複雑
• 変数が使い回されている

というケースが多い。

そのため仕様書を書くときは、コードの順番通りに書く必要はない。

むしろ次の順番で整理すると理解しやすい。

① 処理の目的を書く

例えば

「勤務時間を計算する処理」

② 入力データを書く

例

• 出勤時刻
• 退勤時刻
• 休憩時間
• 休日区分

③ 条件を書く

例えば

• 出勤が9:00より前の場合
• 休憩時間が60分以上の場合
• 深夜時間帯の場合

④ 最後に演算を書く

例

• 勤務時間を算出
• 残業時間を算出
• 深夜時間を算出

このように書くと、業務ロジックとして理解しやすい仕様書になる。

そして最後に重要なのは、

仕様書を書くことは、コードを翻訳することではない

ということだ。

仕様書は、

• プログラムを書く人のため
• 将来保守する人のため

に存在している。

だから、

• 変数
• if文
• 代入

ではなく、

業務の意味

を書くことが重要になる。

今回、順次処理のプログラムを読みながら仕様書を書いているということは、
かなり高度な作業をしている。

なぜならそれは、

プログラム → 業務ロジック

への変換作業だからだ。

これは実は、ソフトウェアエンジニアの中でもかなり価値のある能力だ。

コードを書ける人は多い。
しかし、

コードの意味を構造化できる人

は少ない。

もし今回の経験を続けていけば、

• レガシーシステムの解析
• 業務ロジックの再設計
• システムリプレース

といった、より上流の仕事に繋がっていく可能性がある。

順次処理が読みにくいと感じたその感覚は、
実はプログラマーとしての視点が一段上がった証拠なのかもしれない。