今、自分がいる場所は。。。

今、自分がいる場所は、ソフトウェア開発の本流から離れた

一地方なのだと気づいた。

本流に戻らなければいけない。

もしかしたら、ここのブログで自分が書いている気づきは、

もう本流のなかの誰かが既に気づいたことなのかもしれない。

ソースコードは、それ自体、知識の記述だと思う。

ソースコードは、それ自体、知識の記述だと思う。

問題は、ソースコードに埋め込まれた業務知識を

どうやって抽象的な定義にするかでは

ないだろうか？

そのヒントは、メソッド抽出だと思う。

どっちがマシ？

読めないけどバグはないプログラムと

バグはあるかもしれないけど、読みやすいプログラム。。。。

ソースコードは、コミュニケーションのツールだと思う。

ソースコードは、コミュニケーションのツールだと思う。

Excel で記述した設計書よりも ソースコードのほうが

より具体的だし、実行、検証もできる。

みんなソースコードで設計の話をするべきだ。

プログラムの品質。

プログラムの品質としてバグが無いことをまず最初に上げるべきなのかもしれないが、私は読みやすさ、変更のしやすさを上げたい。

プログラムが読みやすく、変更しやすければ、修正によってバグが入り込む可能性が下がるし、バグがあっても修正がしやすいからだ。

そのときにプログラムの読みやすさをセンスや個人の技量にゆだねては、いけないと思う。

読みやすいプログラムには、一定の規則がある、規約が正しく作られている会社であれば、誰もが読みやすいコードを記述できるはずだ。

プログラムの規約が正しく記述されているか、それを検証する仕事もそのうちに必要とされるのではないかと思う。

規約の検証項目には、アルゴリズムの一意性を私は、加えたい。

何かしらの振る舞いの記述がシステム内で一箇所で記述され、それがメソッドとして抽出されていて、その振る舞いを必要とするプログラムでは、そのメソッドを呼び出すことで処理を実現しているということである。

この変数何！？って言うのもやめてほしい。。。

この変数名何！？って言うのもやめてほしい。。。。

もっと分かりやすい名前を付けてくれ。。。。

プログラムは、愚直であることが必要だなぁ。。。と思う。

そうだ。。。今気づいた。

変数名が閉じているか開いているかの違いなんだろうな。

公に知られている名前を変数名にすれば、

はじめてそれを見る人にも理解できる可能性が高い。

そういうことだなぁ。。。。

ドメイン記述言語とセマンティクWebって関係あるの
かな。。？

コピペでソースを作るのは、やめてくれ。。。。

あるシステムのソースを読んでいて、ほとんど処理が同じだ
という二つのプログラムを DF で比較してみた。。。。

すると更新処理は、ほとんど一緒。

なんで一緒なのに一つのモジュールにまとめないんだ。。。。

そういうことをしていると、どんどん管理するソースが
増えていって、しまいには、管理しきれなくなる。。。。。

ほんとそういうのは、やめてほしい。。。。