公開算譜は機敏だ(An Open Source Project is Agile)GitHub with Docker。Youtube(2) 仮説・検証（51）
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
公開算譜(open source)は楽しいの (just want to have fun.)
公開算譜は機敏だ。前史。
の３つを整理した後書きです。
ソースコードは設計書
QiitaからGithubに活動を移しながら、
厳密なOpen Sourceだけでなく、
ソースコードの断片をコンパイルして動かしたり、
有償のソースコード付きのソフトの移植をしたり、
ソースコードが設計書であることを示そうとしてきた。
ソースコードを設計書として描くには、いくつかの視点がいるかもしれない。
機材、環境、著者を記述する
COBOLでは、環境部があり、利用する機材、環境を記述することにしていた。
C言語でも、CPUの種類、コンパイラの種類、版を描くことが設計書の原点。
どうすればコンパイルできるかが書いてないソースコードだと困ってしまう。
プログラミング言語のソースコードに書いてなくても、Makefileであるとか、
起動するスクリプトか、同梱する開発環境設定ファイルに書いてあればよい。
著者名と連絡先がかいてあるのも基本である。
大構造と小構造を分けて記述する
大小僧、中構造、小構造の３つに分けてもよい。
５段階以上になるときには、どれか２つづつを組みにして、大きく見れば３段階に分類できるとよいかも。
３段階のそれぞれが３段階になっている９段階を上限としてほしい。
そうはいうものの、天才プログラマが書けば、１０段階以上でも読みやすいかもしれない。
設計思想が分かる命名規則
設計対象が何かによって命名規則が違って良い。
必要なのは、設計対象の中で、命名規則で決めた名前が、その名前でわかりやすくなるかどうか。
一般的な規則の存在を確認した上で、一般的な規則に縛られない命名規則でよい場合があるような気がする。
保守のしやすさ
どういう場合には、何を変更するとよいかがわかっているとよい。
マジックナンバーであるかどうかが問題なのではない。
保守ができるかどうかで判断すればよい。
この値は数字でも分かると、最初に書く人が思うのは勘弁してほしい。
自分しか治せないようにしている工夫なら、それはそれで個人の自由かもしれない。
試験プログラム同梱
開発環境が貧弱だと、まず試験プログラムから書く。
あるいは、試験プログラムを自動生成するプログラムから書くかもしれない。
いずれの方法にしろ、試験プログラムは同梱しよう。
機敏
機敏（agile)な開発は、開発予算が少なく、納期が短いものが圧倒的に多数である。
ある有名なアジャイラに質問したら、３年つづいたプロジェクトは無かったとのこと。
ましてや、予算があれば、その予算を消化する無駄な文書を作成するため機敏ではなくなる。
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.