2007/05/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 の解説文書の修正

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

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

情報提供: 杉山氏

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

以下は,

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

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

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

第 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 章 「統合」

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

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

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

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