ブックを開く/閉じる/保存する

Sub ブックを開く()

Dim mybook As Workbook
Set wb = Workbooks.Open(Filename:="C:\work\sample.xls")

Dim ws As Worksheet
Set ws = Worksheets("表紙")

MsgBox ws.Cells(9, 3)

End Sub

保存しないで閉じる

Workbook.Close SaveChanges:=True

保存して閉じる

Workbook.Close SaveChanges:=False

上書き保存

Workbook.Save

名前を付けて保存

Workbook.SaveAs "ファイル名"

RangeとCellsの使い分け

Rangeを使うのは、
・固定位置のセルの場合
・セル範囲（複数セル）の場合

1つのセルを指定する場合

　Cells(行, 列)

セル範囲の場合

Range(始点セル, 終点セル)
の始点セルと終点セルに、Cellsを指定して、
Range(Cells(行, 列), Cells(行, 列))

例

A1セルから、C5セルなら
Range(Cells(1, 1), Cells(5, 3))

複数行の場合、1行から5行なら
Range(Rows(1), Rows(5))

複数列の場合、１列（A列）から３列（C列）なら
Range(Columns(1), Columns(3))

変数を使う時は、Cells、Rows、Columnsを使用する

　固定位置で変化する必要がない場合のみ
Range("A1:C5")
Range("1:5")
Range("A:C")
とする

■

VBAメモ

■

熊とワルツを

熊とワルツを - リスクを愉しむプロジェクト管理

リスク管理とは

信じるに値する根拠のある事だけを信じること
楽観的なスケジュール、やるしかない、やらねばならない精神は信じるに値しない

成功の為に運に頼ることは、プロジェクト管理ではなく、子供のままごとと同じ。
リスクを管理し、プロジェクトをコントロールすることが大人。

リスク管理のプロセス

1.リスクを発見
2.エクスポージャ分析
　実現の確立と影響の数値化
3.リスクの対応計画
4.軽減対策
5.継続的な移行監視

これを継続的に行うことが大事で、（日々の振り返り、週1の進捗報告前などで）成功につながる

プロジェクト管理とは、リスクを管理すること。

共通のリスク

1.スケジュールの欠陥
　原因:見積もりが正しくない、やらねばならない状況
　対策:FP法など
2.要求の増大、変更
　原因:プロジェクト開始時に、全ての要求を出すことはできない。要求は変化する。
　対策:イテレーション開発
3.人員の離脱
　対策:情報の共有化
4.仕様の崩壊
5.生産性の低迷

■

最近読んだ本

ペアプログラミング―エンジニアとしての指南書

ペアプログラミングとは、コーディング作業だけで行うものではなく、設計作業でも行えるとのこと。設計からペアプログラミングを取り入れることで、設計の品質はかなり向上するのではないかと期待が持てた。ナビゲータにレビューの知識があるとさらに良い効果が得られそうなので、レビューについても勉強してみる。

■

最近読んだ本

Javaルールブック　?読みやすく効率的なコードの原則

スキルに自信がないので、せめてレビューで指摘できるように読む。

■

最近読んだ本

バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発 (Be agile!)

+TDD研究会

TDD研究会のハンズオンと書籍のサンプルプログラムでTDDを体験してみての感想。

TDDは、
○:品質保証の手法
×:開発者の為の設計手法
には納得。

テストケースを記述しながら、どんどん機能を作りこんでいくやり方。
ここでのテスケースの抽出の観点は、"バグをみつける"ではなく、"機能用件を満たす"こと。

テストケースがあるので、積極的にリファクタリングが行える。
リファクタリングとテストを繰り返すことにより設計とコードの品質がどんどん上がっていくのが良い。
ペアプログラミングで行った方がより効果的で、品質の高いものができる。

コードを記述しながら進めていくので、コードレベルまで落とし込んだ詳細設計書は不要。
詳細設計と並行して実装を行うので、設計者=プログラマであるか、設計者と密にコミニュケーションが取れる環境が必要。

実装を始める前のTODOリストの洗い出しの精度が大事。ここで異常系までしっかり洗い出しておければ、TDDのテストケースでも
ある程度品質を保証できるのでは無いか。

※上記の書籍でも、同値分割、境界値分析をすると良いと書かれてはいたが、サンプルコードのテストケースをみると特に境界値を意識しているとは思われないケースが挙げられていた。

+拡張型TDD

・テスト設計を行う(同値分割、境界値分析)
・テストコードのリファクタリング
・テストケースの作り込み(境界値を使うなど)
・テストスイートの作り込み
・冗長なテストを無くす

"機能を作り込む"観点に、"バグをみつける"観点を盛り込み、開発終了後にある程度の品質を保証することにより、
後工程の単体テストの工数を削減できるのではないか？

・実装前にテスト設計を行う必要があり、TDDのリズムが崩れる。(実装、テストで頭を切り替えないといけない)
・後工程の単体テストと重複する箇所がある。
・仕様変更により、テストコードとテスト仕様書のメンテナンスが発生する。
→
☆テストコードを書くのであれば、後工程のテスト仕様書にはそのテスト項目を書かないなどの割り切りが必要だと感じた。