01 の dcmodel ネットミーティングのメモ書き

参加者

(順不同) 林祥介, 石渡正樹, 小高正嗣, 高橋芳幸, 佐々木洋平, 森川靖大, 土屋貴志, 山下達也, 徳永義哉

netCDF 3.6.2 の debian パッケージ作成

作業担当者: 小高, 森川

netcdf-ffc5, netcdf-ifc9, netcdf-g95 とも, これまで通り, static ライブラリのみを作成する.

spml の wa_module から rn, irm を参照する問題

作業担当者: 佐々木

wa_module.f90 に以下の行を足してコミット.

public :: rn, irm

マイナーバージョンを上げて, リリースする.

その他 2006 年度末に話し合った内容に関しては, 天文台モデルミーティングログ 2006/12/25-27 を参照のこと.

gt4f90io の dc_test の解説文書の修正

作業担当者: 森川
AssertEqual の解説文章に関して以下のように修正

Usage の「もしも answer と check の値, もしくは配列のサイズが異なる場合, テストプログラムはエラーを返して終了します.」の直前に「正答の場合は OK と表示する」などと記述する.

モデル開発してて面倒と感じることいろいろ

日頃のモデルの開発やその公開に関して, 何か面倒だなぁ, と思っていることいろいろ. ブレーンストーミング的に (だからどうする, はあまり深刻に考えずに).

情報提供: 杉山氏

cvs commit が面倒
- (面倒) コマンドをすっかり忘れているので, わざわざいちいち調べなければならない (コミットするのが億劫になる). 調べる情報も dcmodel プロジェクトの奥のほうにあったりして調べる作業も鬱陶しい.
  - 調べるものの例
    - cvs のタグの貼り方どうだっけ??
    - cvs のコミットどうするんだっけ?? なんかルールもあったような??
- (対応策) 杉山氏が, 自分で cvs コミットの際に必要な情報を dcmodel ページの上の方 (検索しやすい位置) に作ってみる.
ソースの公開版の更新が面倒
- 作業そのものはだいぶ簡素化されている (タグが書き込まれているファイルを書き換え, あるディレクトリで make するだけ).
- やり方が流布されれば OK ??
gt4f90io の開発についていけない
- (面倒) なんかいろいろ開発してるらしいが, ついてゆけん.
- (解決策??) 基本的には History 系 (もうそんなに仕様変更されないことが期待される) のみは追うけれども, 最近作っている目新しいツールは無理して追いかけない. (面白そうならその時に聞く).

単体テストについて他 - コードコンプリート第2版を読んで

解説:石渡, 書記:森川

以下は,

スティーブマコネル著, クイープ訳, 2005: Code Complete 第2版 (上). 日経BPソフトプレス, 664pp.
- ISBN 4-89100-455-X
スティーブマコネル著, クイープ訳, 2005: Code Complete 第2版 (下). 日経BPソフトプレス, 584pp.
- ISBN 4-89100-456-8

に関して, ざっと読んでみて面白かった, 役に立ちそうだったことなどを石渡氏にざっとレビューしていただいたもののメモ書きである.

下記のメモに関しては石渡氏, 森川の不理解により, 分かりづらい, 紛らわしい, 間違っている記述があることを了承されたい.

第 3 章「2 回測って、1 度で切る」

「2 回測って、1 度で切る」≒ ちゃんと設計してからコーディングを行うべし, ということらしい. 何も考えずにコーディングから開始するのと, ちゃんと設計してからコーディングを開始するのとでは, 後々のバグの数も異なってくるらしい. (前者の方がバグは多くなるらしい).
設計の際には UML を使用することがスタンダードらしい.
「良いクラスインターフェースは氷山の一角で無ければならない」 ≒ ちゃんと情報隠蔽を行っておくことが大事.

第 9 章「擬似コードによるプログラミング」

プログラミングを始める時には, C, Fortran 等の機械言語で記述するより先に, 自然言語による擬似コードを記述すべき. 機械言語は, その擬似コードをコメントアウトしつつ, そのすぐ下に追記する形で記述していくべき. 結果的にその擬似コードがドキュメントになる.

考察 (?): サブルーチンなどの言語単位の要約としての擬似コードは良いが, 各一行一行のコメントは後で変更するとき余計では??? (書き換えコストが 2 倍になる恐れがある).

第 10 章

10.4 スコープ

個々の変数の「寿命」は短くする. 変数の定義された部分から変数の使用終了するまでを短くする.

第 11 章「変数名の力」

あまりに短い名前はつけない. 記述的な名前をつける. ただ, その手法でやり続けると, 長くなりすぎるため, ある程度長くなったら適度なところで短縮することも大事.

第 12 章「基本的なデータ型」

12.4 文字と文字列

マジックナンバー (12 月の '12' なども含む) をそのままコードに埋め込むことはせず, 名前付き変数に置き換える.

第 21 章「コラボレーションコンストラクション」

21.2 ペアプログラミング

一方のプログラマがキーボードでコードを入力し, もう一方のプログラマがミスに目を光らせ, コードをチェックする.

ある程度のマンパワー (少なくとも, 1つのプロジェクトに 2 人以上のプログラマ) が必要となるが, コードへ埋め込まれるバグが減る, お互いのプログラマが鍛えられるなど, 良い点が多い.

第 22 章「デベロッパーテスト」

22.3.3 データフローテスト

if などの条件分岐がプログラム内にある場合, テストプログラムは全ての分岐に関してチェックしなければならない.

リスト22-3 を例にとると, Condition 1 と Condition2 の両方に関して真偽の場合のテストを行わなければならない.

22.3.6 境界分析

「1つ違いエラー」のチェックを行うテスト. ある境界があったら, その境界の一つ前, 境界自体, 境界の1つあとの値を与え, チェックを行う.

22.6 テストの改善

22.6.2 自動テスト

テスト自体は自動化して行えるようになっていなければならない.

自動化できないのであれば手間がかかるだけなのでやらない方が良い.

第 24 章「リファクタリング」

ソースコードを組みなおす際には, 組み換えのコストが組み替えた結果得られる利益よりも小さいことをちゃんと考慮する.

第 25 章「コードチューニング戦略」

パフォーマンスを気にするのは最後の最後でよい.

考察 (?): 我々 Fortran ユーザの場合, これは真なのか疑問.

第 27 章「プログラムサイズの影響」

プログラムサイズが大きくなるとプログラマの参加人数が多くなるため, コミュニケーションが大変になる. ちゃんとルールを決める必要が出てくる.

プロジェクトになると, 結局大事なのは人と人とのコミュニケーション.

第 28 章「コンストラクションの管理」

「コンストラクション」= プログラムを作ること (= コードを書くこと, 仕様を考えること, リファクタリングすること)

第 29 章「統合」

「トップダウン統合」
- まずはメインプログラムを作成, 次にそのメインプログラムで呼び出されるサブルーチン, すなわちインターフェースを作成し, 最後にサブルーチンの中身を作成する.
「ボトムアップ統合」
- まずは個別の細かいサブルーチンを作成し, 次にそのサブルーチンのインターフェースを作成し, 最後にメインプログラムを書く.
「T 字型結合」
- 両方の折衷案 (基本的にトップダウンなのだが, インターフェースを一通りそろえて次へ, ではなく, あるインターフェースを作成したら, その下部のサブルーチン等を一気に作ってしまう).

29.4 デイリービルドとスモークテスト

デイリービルド: 毎日ビルドする = ビルドのテストを行うこと.
スモークテスト: 煙が出ないか = とりあえずまともに動作することをチェックすること.

第 32 章「読めば分かるコード」

コメントを書かねば分からない部分は, まずコードがもっと読みやすくならないか考えてみる.