過去の遺産として動作している，古き悪き保守性の悪いプログラムはレガシーコードを言われていますが，何もVB6などで実装されているコードがレガシーコードというわけではありません。
レガシーコード改善ガイド
「レガシーコード改善ガイド」という悪いコードをリファクタリングする技術が書かれている本によれば，「テストコードのないコード」はすべてレガシーコードと呼んでいる。
現代のプログラミング文化では，テストコードのないプログラムは認められていないダメなコードということになる。
すべてのプログラミングをコードはテストコードでカバーし，保守性の高いコードを書かなければなりません。
テストを意識することで，プログラム同士が疎結合になり，保守性が高まります。
例えば
例えばデータベースに接続するようなプログラムを書くとしましょう。そのままデータベースにアクセスしてしまうと，テストコードが書き辛くなります。
なぜ書きづらいのかというと，テストコードというのは基本的にはメモリ上で完結するものをテストするほうが書きやすいものです。「a+b=c」などというコードをテストするのはたやすいですが，指定されたフォルダーの中のファイルを読み込んで処理するとなると，そのファイルを指定したフォルダーに置いておかないといけないし，それがないとテストが通らなくなってしまいます。
だからできるだけメモリ上で完結するようにテストを書くようにする必要があります。
メモリ上でテストを完結するとなると、データベースへのアクセスは非常に厄介なものになります。そういう場合はデータベースと接触する部分にインタフェースを作成し，データベースと接触しないダミーのクラスを別途作成します。これをMock（モック）と呼んでいますが，そういった感じでテストコードを書いていくことで，アプリケーションの内側と外側が意識され，非常に疎結合な保守性の高いプログラミングができるようになります。というわけで，現代社会ではテストコードの技術は必須ということです。
基本的にはリファクタリング
職場にある過去のひどいコード（それは先輩が書いたものかもしれないし，過去のあなたが書いたものかもしれない）の多くはレガシーコードの可能性がありますが，リファクタリングすることでレガシーコードではなくなります。
レガシーコードをなくすためにはテストコードが必要ですが，リファクタリングの作業手順としては，テストコードを先に書いて，現状のダメコードに対して，テストでカバーします。その後リファクタリングでコードを改造していくのですが，最初にこのテストコードがないとバグの混入に気づけないので，最初にテストが必要ということです。
しかし，そもそもダメダメコードなので，ユーザインタフェースにデータベースへのアクセスコードがかかれていたりするため，純粋にテストコードでカバーするというファーストステップから夢が絶たれます。
ダメダメコードにテストコードで事前にカバーするなど到底無理な話だと私は思います。
とはいえ既存のダメコードに触れるときはある程度のリファクタリングが必要です。
ダメコードのリファクタリングの仕方
ダメコードをリファクタリングするにはある程度やり方があります。たいていのダメコードは特性が決まっています。結局VB6や初期VB.NET，C#で書かれたコードはオブジェクト指向の知識がほぼない状態で書かれているコードが多々あるため，画面にゴリゴリとプログラムが書かれていると思います。
ボタンクリックの中、もしくは，ボタンクリックから呼ばれる関数（いずれも画面クラスに書かれているはず）にだらだらと処理が書かれていて，データベースにアクセスして，画面にデータをセットしているか，画面のデータをデータベースに登録しているでしょう。
その中で，データベースにアクセスしているところを見つけましょう。
データベースにアクセスしている箇所にSQLが書かれているのであれば，それらをトランザクション単位で分けていきましょう。
マスター系のデータで1テーブル検索，1テーブル更新の場合はそのマスターテーブル1つが1つのトランザクションとなるので，１つのマスタテーブルを１つのクラスとします。受注と受注明細など，同時に扱うのが当然と思われるものは，それらのトランザクションで１つに扱うので，まとめて１つのクラスにデータベースアクセスクラスとして分けましょう。
SQLを実行する際は，そのトランザクション単位のクラス経由でしかアクセスできないように実装しましょう。
それだけでもだいぶすっきりするはずです。それができたら，画面のロジックをViewとViewModelに分けて，データバインディングで連結しましょう。
テストコードのないプログラムのリファクタリングは怖い
テストコードのないプログラムをリファクタリングをするのは大変に怖いことです。慣れてくれば慣れてくるほど，テストコードのないプログラムを改造することの怖さを感じます。それでも古いダメダメコードは少々テストコードが書けなくても，勇気を出して改造しないといけない場合があります。つらいですが仕方ありません。
我々は，後輩に同じ思いをさせないように，保守性の高いプログラミングをしないといけません。
出来ればすべてゼロから作りたい
古いプログラムを改造する度に，ゼロから新しく作りたいという感情に襲われます。ダメプログラムが過去の自分か書いたもの場合は落ち込みはさらに増します。
その分，今の自分が成長したのだということで，良しとしていますが，そのコードを永遠に後輩にみられるかと思うとヒドイ仕事だと思いますね。ふつうは，過去のダメな時代の仕事ぶりを後輩にみられることはありませんが，プログラミングの仕事は，証拠として残ってしまうので，恥ずかしい思いにされられることがありますね。
今後はそんなことにならないように毎日少しでも勉強していかないといけません。
勉強が乗らないときは？
勉強が乗らないときはありますが，できるだけ毎日勉強したほうがいいと思っています。分厚い500ページくらいの技術書も，一気に読むことはできませんが，一日30ページでも読むことができれば，1か月もあれば読み切ることができます。
私は，1日のうちの9時半から10時半までは技術書を読む時間と決めて，毎日読むようにしました。気分が乗らないときは，1ページでも読もうなどと最初は思っていましたが，それはやめて，気分が乗らないときは「1文字読もう！」と思うようにしています。1文字なら，どんなに疲れていても読めます。そして1文字読むと，10文字くらいは読んでしまいますし，結局は1ページ読んだり，もっと読んだりします。
結局，最初の本を開くまでがエネルギーいるんですよね。
最近はKindle本をお勧めしています。でかい技術書を机に置いて読むのは結構重くて疲れますし，分厚いと読みづらいことが結構あります。
Kindleならブログを読むように読めますし，Kindle本とVisualStudioを画面に並べてサンプルプログラムを打ち込んだりすることもできます。その場合，手はキーボードとマウスのためにふさがるので，腕の下に分厚い参考書を置くのは，少しやりづらいですね。
Kindle本で技術書を買いだしてからは，可能な限りKindleにしています。一部の技術書は紙の本しかないものもあり，そういう時は仕方なく紙の本にしています。
C#を勉強する順番
というわけでいろいろ言ってきましたが，最初の結論を言っていた通り，C#を勉強する順番は次の通りがよいと思います。
- 基礎文法
- コーディングルール，各種作法
- オブジェクト指向
- デザインパターン
- テスト駆動開発
- リファクタリング
- ドメイン駆動開発
何度も言っていますが，こんな感じです。
以上で第２部終了とします。第1部ではリーダブルコードを読めばよいコードになると思っていたけど，世の中はそんな単純じゃないらしい…ということがわかる第2部でした。
第3部では実際に職場のコードにドメイン駆動を適応していくまでの奮闘をお伝えしたいと思います。が，あくまで予定です。
