C#でモダンなプログラム開発を学ぶ！【書評】チーム開発の教科書

2017.01.26：更新しました！

f:id:shin21sk:20160512005713j:plain
転載：SHIN-ICHI の技術ブログ | Programming tips and tutorials blog

ASP.NET MVCをメインに開発し始めて、早半年。WindowsFormメインだった自分にとって、本当に覚えきれないほどの新しい技術や考え方が次から次に襲ってくるイメージでした。

そんな中、ふと目にとまったのがこの一冊。

チーム開発の教科書 C#によるモダンな開発を実践しよう!

作者: 古賀慎一
出版社/メーカー: 日経BP社
発売日: 2015/10/08
メディア: 単行本
この商品を含むブログ (2件) を見る

チーム開発の教科書 C#によるモダンな開発を実践しよう！　（古賀慎一著、日経BP社）

チーム開発かぁ・・・。少し論点が違うんだよなぁ・・・。と思いながらもパラパラとページをめくってみるとですね。

「あれ？あんまりチーム開発に重きを置いていないぞ」という事に気づきました。

いや、どちらかというとサブタイトルの「C#によるモダンな開発」という方が詳しく書かれているじゃないですか。

「こういう本を探していたんだよ～！！」というわけで、即買い。即読みした次第です。

ざっと一通り流し読みした感じでは、今まで自分が独学でヒーヒー言いながら身につけてきた知識はあらかた間違ってはいなかった事。

でも本当に必要なの？オーバースペックじゃ無い？という気づきを与えてくれました。

そして何よりも「静的コード分析」。これはかなり目からウロコでした。他にも読んでいていて気になった点があったのでまとめました。

静的コード分析
MVVMとMVC
LINQ to SQLではクエリ式を使う
DIコンテナーも無理して使わなくてOK
感想まとめ

静的コード分析

作者様のSlideShareです。

ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った高品質・低コスト・保守性の高い開発 from 慎一古賀

www.slideshare.net

簡単にまとめると、「バグになりやすい箇所をVisual Studioが警告としてアラートしてくれる」機能です。Dispose忘れや他にも隠れた不具合の温床を発見できるというものです。ただ、もの凄い数の警告が挙がってきます。何ならば新規作成したばかりのプロジェクトでさえ、アラートが挙がってくる始末。

・・・めんどくせぇ。。。

正直、心の声は「面倒くさい」一色で染まってきました。それを見越しているのか、本には以下のような記載がありました。

ここで一番やってはいけない例を挙げると、「警告がウザいのでとりあえず抑制した」という場当たり的な対応です。

Visual Studio標準のテンプレートから新規作成した空のプロジェクトが警告になるため、嫌になってしまうというものです。

うぐっ、当たってる・・・。

新規作成から警告になってしまうのは、最初にキチンと決めておかない事項がある為、いきなり警告が挙がってくるようです。この辺りの回避方法もキチンと載っていたので大変分かりやすいと思います。

静的コード分析を実際に行ってみた結果、確かに自分では絶対に気付かないor気にしない箇所も指摘が入ります。「ここ書き方怪しいけど、いいの？」と助言されているかのようです。まさにペアプログラミングをしているかのような感覚です。但し、自分で原因は対処しないといけないのでラクチンとはいきませんが。

MVVMとMVC

ASP.NET MVCを始めた直後に大いにハマったのが、Model-View-ControllerというMVCの概念でした。大抵の書籍では、Viewに表示させるのはDatabaseの値をそのまま取得したModelでした。でも業務要件ではそんな訳にもいかず、複数のテーブルの結果を表示させたりするケースがほとんどです。ここで「えっ？どうするの？？」と詰まってしまった訳です。

解決策はMVVM（Model-View-ViewModel）を利用します。様は表示する画面毎に項目にあったViewModelを定義して、Modelのデータをそこに入れてあげる形です。

このModelの値をViewModelに入れるのが、冗長で面倒なのでAutoMapperというMapperを好んで使うようにしていました。ところがこの本ではそんなMapperに関して言及されています。

一見スマートに見える方法ですが、スキルセットが揃っている３名程度のチームではよく機能すると思います。しかし、それ以上の人数になると、とたんに問題になります。勉強コストが高い、つまりルールを知らないと扱えないのです。

確かにAutoMapperで書くとソースコードを単純に見た限りでは何をしているのか分からない記述になります。メリットは大いにありますが、この辺りもデメリットとしてキチンと考えておかないとダメという事ですね。

LINQ to SQLではクエリ式を使う

大抵のWEB情報や書籍ではクエリ式より、メソッド式を使いましょうと紹介されています。理由は色々あるのですが、メソッド式の方が出来ることが多いというのもあると思います。そこを敢えて「クエリ式を使いましょう」というのは意外でした。

f:id:shin21sk:20160511183301j:plain

こんな感じで書き方を変えるようです。確かに全てメソッド式で書くと、どこからどこまでがLINQ to SQLでどこからどこまでがLINQ to Objectsなのか分かりにくいと思います。でもこの書き方のメリットはそれだけではありません。

下のLINQ式ですが、OrderDateの結果をToStringで整形して取得する簡単な例です。結果は一緒でしょうか？？

from c in Orders
 select c.OrderDate.Value.ToString("yy/MM/dd")

(from c in Orders
 select c)
 .ToList()
 .Select(s => s.OrderDate.Value.ToString("yy/MM/dd"))

上はエラーになり、下は正常に動作します。上はLINQ to SQLで動きますが、下はLINQ to SQLで値を取得した物をLINQ to Objectsで変換している形になります。LINQ to SQLはSQLサーバーで行える事しか実行出来ない為、ToStringの様な文字整形は行えないのです。しかもビルドは通ってしまうので、動かして初めて気付く不具合になります。正直、僕自身も何度かこの現象にハマった事があります。ようやく根本から理解出来た気がしました。

DIコンテナーも無理して使わなくてOK

依存性の注入（Dependency Injection : DI）という（舌を噛みそうだけど一度は言ってみたい）考え方があります。「C#実践開発手法」では当たり前のように使いなさいよ、と記載されていたので見よう見まねで実装してきました。

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

作者: ゲイリーマクリーンホール
出版社/メーカー: 日経BP社
発売日: 2015/06/25
メディア: Kindle版
この商品を含むブログを見る

実際に効果も分かったので便利だなと思う反面、小さい開発規模では果たしてここまでする必要があるのだろうか？とも感じてはいました。

インターフェースを間に挟むとデバッグ先を探すのに一手間入るので面倒という事もありますし、そこまでモックを必要としない開発もある訳なんですよね。

デメリットを理解して、得られるメリットの方が圧倒的に大きい場合のみに使用することを検討しましょう。

なんとなくこの一文に救われた気がします。知らないことばかりの状態で覚え始めた身としては、あれも覚えなきゃいけない、これも覚えなきゃいけないと己の未熟さを痛感させられる思いでした。いや、最終的には覚えなきゃダメなんでしょうけど。そんな中、「大丈夫だよ、無理なら少しずつやればいいんだから。」という風に解釈出来たわけです。