Software Debuggingまとめ2

Ch2 Assertions

アサーションを使用することによって、エラーの検出が早くなりすぐ修正できる。

事前条件と事後条件

関数でアサーションを使用する場合は、その関数の事前条件と事後条件をチェックする。

ただし一般的に事後条件は書くのが難しい。

不変条件

不変条件とはあるオブジェクトが常に満たしていなければならない条件である。つまり、不変条件に反していればエラーとなる。

publicメソッドの最初と最後でチェックする。

まとめ

アサーションを使用する場合は

1. 不変条件を定義する。
2. 事前条件を設定し、不変条件のチェックも行う。
3. 事後条件を設定し、不変条件のチェックも行う。

アサーションとコンパイル

アサーションには時間がかかることがある。

その場合、時間がかかる関数のアサーションのみオフにする。

Software Debuggingまとめ

目的

UdacityのSoftwareDebuggingのコースを、ずっと受けていましたが全て終了したのでまとめを残しておきます。

まあ演習問題は面倒だし、使用言語がPythonなので実際に使わないためやってないんですが。

Ch1 How Debbugers Works

科学的手法

デバッグには以下の科学的手法を使うべし。

1. エラーを観察する。
2. 仮説を立てる。
3. 予測する。
4. 実験する。
5. 実験結果を観察する。
6. 仮説が正しいか、確かめる。
7. 仮説が正しい場合は、仮説を強化する実験を行う。
8. 仮説が正しくない場合は、仮説を却下し新たな仮説を構築する。
9. 上記のステップを、バグの原因が説明できるまで繰り返す。

チェック項目

バグの修正後は必ず以下をチェックするべし。

1. 同じバグが存在していないか。
2. エラーが再び起こらないか。

デバッグに5分以上かかる場合、系統的デバッグを行うべし。
系統的デバッグとは、デバッグの過程を記録するやり方。

これには下記の利点が存在する。

1. エラーをいつでも再現できる。
2. デバッグをいつでも再開できる。
3. 同じエラーが出現したとき、すぐに解決できる。

他の人と会話するのもよい方法である。

参考

Udacity

Why Programs Fail, Second Edition: A Guide to Systematic Debugging

PL/SQL, Shell

10月から立て込んでて更新できませんでした。

無理やり時間を作って書き込んでいます。

1月から新たな派遣先で仕事をしているのですが、いきなりPL/SQLとShellをいじくることになったので、やっていて感じたことを書いてみます。

まずPL/SQLですが、全く知らない状態で既存のプログラムを基にして作成することになりました。1日だけ勉強の時間を作って、以下の本を読みました。

プロとしてのOracle PL/SQL入門 【第3版】(Oracle 12c、11g、10g対応) (Oracle現場主義)

PL/SQL以外のプログラミング言語を知っていれば、1日で読める量です。

PL/SQLはカーソルを把握していれば何とかなりそうです。

ただ上記の本だと綺麗な書き方やコード規約について一切触れていないので、現場によっては苦労するかもしれません。

またオラクルのツールの使い方も知る必要があるだろうな、と思います。

ただPL/SQLよりも、仕事場の開発環境の方に不満があります。(コピペの強制など。)

Shellについてですが、こちらも既存プログラムを基にしてシェルを作成しています。

やってみて思ったのが、Windows端末だとなかなか気軽にLinuxコマンドの開発環境が構築できないということです。

おそらくGitをインストールし、Git Bashで実行するのが一番手軽だとは思いますが、Git自体インストールできない可能性もありますし。

またGit Bashはパスの指定がやや特殊です。おそらくCygwinと同じだと思いますが。

注意しないと一部のコマンドが、想定外の動きをします。

Linuxのコマンドの勉強は以下の本で行いました。

新しいLinuxの教科書

 こちらもさっと読める内容となっています。

ただ本来これだけだと、Shellプログラミングを行うのには知識不足だと思います。

Unix, Linuxの哲学や綺麗な書き方を勉強する必要がありますが、なかなか本を読んだり既存のShellを読んだりする時間がないです。

不幸にも現在の仕事場ではコピペ強制なので、そこまで知識はいりませんが。(それってプロでは無いよな...。)

まあPL/SQLはともかくShell自体は今後も触ると思うのでぼちぼち勉強しようと思っています。

Google Technical Development Guideの実践(1)

前置き

今年の9月頃からStudents - Guide to Technical Development - Google Careersを実践しています。

ちなみに私の技術レベルは以下の通りです。

1. SIer4年目で、仕事で使っているのはVB.NET。
2. 大学、大学院とも文系。
3. 入社するまでのプログラミング経験は、高橋麻奈『やさしいC』をやっただけ。
4. Java SE8のSilver資格は取得済み。
5. .NETの内容でLINQはほとんど知らず。Generic、Lambdaは一応使っている程度。
6. ReadableCode等でコードの書き方は、一応知っているつもり。

実践しようと思ったきっかけは、今のまま仕事をしているだけではいつまでたっても技術者としてレベルアップしないと思ったからです。

現段階で以下が完了済みです。

• Introduction to Computer Science
• Software Testing(最後の演習はまだやっていません。)

とりあえず現段階で完了しているコースについて感想を書いてみようかと思います。

Introduction to Computer Scienceの感想

解説が非常に解りやすかったです。ただこのコースはプロミングを知らない人用に作成しているみたいです。

既に4年間触れているため、どうしても退屈するところがありました。

プログラミングをほとんどしたことがない人にはお勧めです。(少し難しいかもしれませんが。)

Software Testingの感想

よかったところ

• 内容が実践的
• Random Testingのやりかたなど、全く知らない知識が増えた。
• 演習で実際にコードを触るため、プログラマにとっては頭に残る。

悪かったところ

• 話すのが早い上に、だらだらと続けるため何を言っているかわかりにくい。
• 演習の参考にするソースを、動画でしか示さないのはどうかと思う。
• 演習で使用するコードが汚い。

失敗した点

ノートをとっていなかったため、詳しい内容が頭に残りませんでした。

edXのコースだと演習で講義のまとめが問題に出されるので、頭に残りやすいのですが、Software Testingでは演習の内容はテストコードの作成のためあまり頭に残らなかったです。

頭に残ったこと

ランダムテストって凄い！。ランダムテストをするべし。

このコースはソフトウェアをどう壊すか、について興味がないとつらいと思います。

これからすること

この講義の内容だとUnit TestやTDDについての知識が不足するので、以下の本で補っています。

Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))

 時間があるときに、テスト全体についての本を読んでみようかと思っています。

VB6からVB.NETへのマイグレーションは成功するか。

2015年から仕事でVB6からVB.NETへのマイグレーションを行っていました。

自分用のメモおよび、無いとは思いますがVB6からVB.NETへのマイグレーションを行う方の参考になればと思い、情報を残すことにしました。(半分愚痴です。)

結論

　タイトルの「VB6からVB.NETへのマイグレーションは成功するか。」ですが、結論から言うと無理じゃないかなと思います。

必要なスキル

VB6からVB.NETへのマイグレーションを行うには以下のスキルが必要と考えています。

1. VB6の言語仕様の把握。
2. VB.NETの言語仕様の把握。
3. Win32 APIでプログラムを作成した経験があり、Win32APIを把握していること。
4. サードパーティーを使用している場合、サードパーティの製品に対する深い知識。

1.VB6の言語仕様の把握, 2.VB.NETの言語仕様の把握。

1と2が必要な理由は、そもそもVB6とVB.NETは全く異なるプログラミング言語だからです。(後述)

3.Win32 APIでプログラムを作成した経験があり、Win32APIを把握していること。

3についてはVB6でWin32APIを使用しているため、全く知らないとそもそも意味が分からないので苦労します。(できないとは言わない。)

4.サードパーティーを使用している場合、サードパーティの製品に対する深い知識。

4についてですがサードパーティの製品によってはメーカーが、VB6用製品からVB.NET用製品についての移行の仕方を書いた資料を用意しています。

ですが当然それの通りやっていればよい、という訳にはいきません。

サードパーティの製品でも大抵、VB6用とVB.NET用の製品はベースとなる考え方が異なりますし、微妙なレイアウトの調整などはどうしても必要です。

最悪なケースがVB6用の製品しかメーカーが作っておらず、そのメーカーも今は倒産している場合です。

その場合はVB6用のヘルプファイルをひっくり返すしか無いので、どうしても時間が必要です。

以上必要なスキルを上げましたが、そもそもこのスキルを持っている人がこの業界にそんなに存在するでしょうか？

 VB6とVB.NETの差

 VB6とVB.NETの違いで特に頭に残っていることを書きます。

1. PictureBoxの非互換性。
2. 配列のインデックスの違い。
3. ByRef、ByValの違い。
4. 描画単位の違い。
5. Nothingの動作。
6. 印刷の違い。
7. DoEventの罠。
8. ファイルアクセスの罠。

1.PictureBoxの非互換性。

1についてですが、PictureBoxは全く異なります。違いすぎて何が同じなのか分からないぐらいです。なので基本的にコンバート用のクラスを作成しないとだめです。

2.配列のインデックスの違い。

2についてですが、VB6の配列は1始まり(他も可能。)ですが、VB.NETは0始まりです。

それだけといえばそれだけですが、変換するのはなかなか大変です。

例えば一律に配列を参照、代入する際インデックスを-1したとしましょう。

ところがグローバル変数に配列のインデックスを代入しているケースは対応できません。また当然1始まりでないケースも存在するので、ある程度は目で確認しないといけません。

3.ByRef、ByValの違い。

3についてですが、VB.NETはByRef、ByVal指定を省略したときはByValですが、VB6はByRef指定になっています。これがプロパティのアクセス方法の違いによって、エラーとなります。(ReadOnlyとか)

4.描画単位の違い。

4ですが、VB6は主にTwipsです。VB.NETはPixelです。これも簡単に変更できそうですが配列と同じで、変数に値を格納したりするので、目でチェックする羽目になります。

5.Nothingの動作。

5ですが、VB6では例えばフォームにNothingを代入した後、.Showしてもエラーにはなりません。自動的にインスタンスを生成してくれます。

VB.NETではもちろんエラーになります。

6.印刷の違い。

6ですが、こちらも全く異なります。一応VB6との互換性を保ったクラスが用意されているので、VB6の印刷関連のラッパークラスを作成することになります

7.DoEventの罠。

7ですが、VB6はDoEventで非同期処理を行えました。.NETでもDoEventが存在しますが、非推奨でおまけに遅いです。置換してくれ、と言われた際には泣くことになります。

8.ファイルアクセスの罠。

8ですが、VB.NETでもVB6と互換性を保ったファイル書き込み、読み込みの機能は存在します。(WriteLineとか)

存在しますが、ネットワーク上にファイルを置いた場合極端に遅くなります。

結局ファイル書き込み、読み込みはすべて.NETのクラスで置き換えることになります。

他にもいろいろ存在しますが、とりあえずこのくらいで。

そもそもなぜ成功しないのか

いろいろ書きましたが、そもそもこれらは成功しない要因ではないと思っています。

成功しないのは、以下が原因だと思っています。

システムのメンテナンス性がないこと。

VB6からVB.NETへコンバートするのは、ある程度はMicrosoftのツールが自動的にやってくれます。しかしできたソリューションファイルを開くと大抵1000個ぐらいエラーとなっています。(表示されるのは100個程度です。)

コンパイルエラーを排除しなければ、当然コンパイルできません。

しかし1000個もあれば当然、コンパイルエラーの修正時にミスが発生します。

コンパイルエラーを排除してから、動作確認に移りますがこのときにコンパイルエラーのミスに気付ければよいのですが、なかなかそうはいきません。

気付けた場合そこから解析作業に移りますが、ソースコードが読みやすくない場合や仕様書などのドキュメントが存在しない場合、どうしても時間がかかります。

そんな感じでマイグレーションはなかなか成功しません。まあマイグレーション自体もうそんなにないと思うので、あまり参考にはならないかも。