疑似コード(pseudocode)について
ふと思ったのでメモ。
疑似コードをプロジェクトで正式に採用したことはないんだけど、要求開発のツールとしてドメインモデリングを採用する際に、インタフェース設計の後に一段階入れても面白いかも。予想されるメリットは以下:
- インタフェース設計のみより多くのフィードバックが期待でき、コストもそれほど大きくない。*1
- リリース後の保守コストがゼロ。*2
- 工数の見積もりが高精度で立てられ、かつ、この活動によって、工数の読みづらい実装時の手戻りを削減できる。*3
- ソースコードのシンタックスエラーを気にして不必要に細かいところまで考えてしまうことが無くなる。
- 実装時にソースコード上のコメントを考えることや、実装後に後付けすることが無くなる。結果として、実装に準じるようにうまくコメントを書くという本来と逆の思考により不適切なコメントを書くことを避けられる。
- レビュー時に、実装技術の細かい話の話になったり、レビュー者が実装技術の細かい点につい意識を持って行かれるようなことが無い。*4
- ダメな案を抱えてしまうリスクの排除。*5
要検討な点:
- 疑似コードを利用するかどうかの判断が必要になる。*6
- 書式をある程度一般化する必要がある。*7
- 複雑だが本質的なロジックの場合、ソースコードを直接書いたほうが厳密かつ分かりやすいよね。そういう場合にどうするか。*8
- どこまで疑似コードで掘り下げるかの判断基準が必要。*9
*1:インタフェース設計フェーズを拡張するだけで行けると思われ。
*2:リリース時には疑似コードはすべて実際のコードに置き換わっているため。
*3:固定金利と変動金利のスワップのようなもので、リスク管理手法としてはかなりおいしいと思われる。
*4:設計レベルのレビュー時にインデントのスタイルとかスペースの入れ方とかfor/while/forEach等のどれを使うべきかとかを話しても意味がない
*5:コーディングまで完了させてしまうと、心理的にそのコードを捨てづらくなる。数行の疑似コードであれば捨てやすい。
*6:setter/getterなどに作っても意味が無いので。しかし、setterにバリデーションがあったらどうなの?とか考えだすと、かなり明確な判断基準がないと運用が難しそう。っていうか、全部疑似コードを書くと決めてしまったほうが早いかもですね。単純なgetterならお決まりの文を1行入れるだけなのでコストはかからんし、後でバリデーションロジックなどが入るかもしれんし。そもそも疑似コードを書くという行為によって『バリデーションいるんじゃね?』的な気付きを得られる可能性が増すという考えもあるよね。
*7:順次・選択・反復系をどう表すかなど。たぶん、いくつかのパターンの例を示しておく程度でもいい気がする。形式化しすぎると本末転倒だし。
*8:例えば、独自サービスのポイント付与ロジックとか、大半はプログラミング言語の syntax で記述したほうがわかりやすいと思われる。
*9:インタフェースからほぼ自明な処理は疑似コードは書かず、そうでないものはすべて機械的に実装に書き換えられるレベルの粒度まで掘り下げてもいいかも。しかし、ドメインモデルのインタフェース直下ではなく派生したルーチンとかクラスが必要になる場合は要検討だけど、直観的にはそこまではやらんほうがいいと思われる。そこまでやったらもう要求設計フェーズじゃないよねwww。ドメインモデル以外については、臨機応変にやるのがたぶん正解。作業者のレベルや経験値やコード資産の流用などによる影響が大きすぎるので。