MVCをメインに開発し始めて、早半年。WindowsFormメインだった自分にとって、本当に覚えきれないほどの新しい技術や考え方が次から次に襲ってくるイメージでした。そんな中、ふと目にとまったのがこの一冊。慎一著、日経BP社)チーム開発かぁ・・・。論点が違うんだよなぁ・・・。思いながらもパラパラとページをめくってみるとですね。「あれ?あんまりチーム開発に重きを置いていないぞ」という事に気づきました。いや、どちらかというとサブタイトルの「C#によるモダンな開発」という方が詳しく書かれているじゃないですか。「こういう本を探していたんだよ~!!」というわけで、即買い。一通り流し読みした感じでは、今まで自分が独学でヒーヒー言いながら身につけてきた知識はあらかた間違ってはいなかった事。本当に必要なの?オーバースペックじゃ無い?という気づきを与えてくれました。何よりも「静的コード分析」。これはかなり目からウロコでした。他にも読んでいていて気になった点があったのでまとめました。作者様のSlideShareです。Studioが警告としてアラートしてくれる」機能です。Dispose忘れや他にも隠れた不具合の温床を発見できるというものです。もの凄い数の警告が挙がってきます。何ならば新規作成したばかりのプロジェクトでさえ、アラートが挙がってくる始末。心の声は「面倒くさい」一色で染まってきました。それを見越しているのか、本には以下のような記載がありました。ここで一番やってはいけない例を挙げると、「警告がウザいのでとりあえず抑制した」という場当たり的な対応です。Studio標準のテンプレートから新規作成した空のプロジェクトが警告になるため、嫌になってしまうというものです。うぐっ、当たってる・・・。新規作成から警告になってしまうのは、最初にキチンと決めておかない事項がある為、いきなり警告が挙がってくるようです。この辺りの回避方法もキチンと載っていたので大変分かりやすいと思います。静的コード分析を実際に行ってみた結果、確かに自分では絶対に気付かないor気にしない箇所も指摘が入ります。「ここ書き方怪しいけど、いいの?」と助言されているかのようです。ペアプログラミングをしているかのような感覚です。自分で原因は対処しないといけないのでラクチンとはいきませんが。MVCを始めた直後に大いにハマったのが、Model-View-ControllerというMVCの概念でした。書籍では、Viewに表示させるのはDatabaseの値をそのまま取得したModelでした。業務要件ではそんな訳にもいかず、複数のテーブルの結果を表示させたりするケースがほとんどです。ここで「えっ?どうするの??」と詰まってしまった訳です。解決策はMVVM(Model-View-ViewModel)を利用します。様は表示する画面毎に項目にあったViewModelを定義して、Modelのデータをそこに入れてあげる形です。このModelの値をViewModelに入れるのが、冗長で面倒なのでAutoMapperというMapperを好んで使うようにしていました。ところがこの本ではそんなMapperに関して言及されています。スマートに見える方法ですが、スキルセットが揃っている3名程度のチームではよく機能すると思います。それ以上の人数になると、とたんに問題になります。勉強コストが高い、つまりルールを知らないと扱えないのです。確かにAutoMapperで書くとソースコードを単純に見た限りでは何をしているのか分からない記述になります。メリットは大いにありますが、この辺りもデメリットとしてキチンと考えておかないとダメという事ですね。SQLではクエリ式を使う大抵のWEB情報や書籍ではクエリ式より、メソッド式を使いましょうと紹介されています。理由は色々あるのですが、メソッド式の方が出来ることが多いというのもあると思います。そこを敢えて「クエリ式を使いましょう」というのは意外でした。こんな感じで書き方を変えるようです。Objectsなのか分かりにくいと思います。この書き方のメリットはそれだけではありません。下のLINQ式ですが、OrderDateの結果をToStringで整形して取得する簡単な例です。s.OrderDate.Value.ToString("yy/MM/dd"))上はエラーになり、下は正常に動作します。Objectsで変換している形になります。SQLはSQLサーバーで行える事しか実行出来ない為、ToStringの様な文字整形は行えないのです。ビルドは通ってしまうので、動かして初めて気付く不具合になります。僕自身も何度かこの現象にハマった事があります。根本から理解出来た気がしました。DI)という(舌を噛みそうだけど一度は言ってみたい)考え方があります。「C#実践開発手法」では当たり前のように使いなさいよ、と記載されていたので見よう見まねで実装してきました。Kindle版この商品を含むブログを見る実際に効果も分かったので便利だなと思う反面、小さい開発規模では果たしてここまでする必要があるのだろうか?とも感じてはいました。インターフェースを間に挟むとデバッグ先を探すのに一手間入るので面倒という事もありますし、そこまでモックを必要としない開発もある訳なんですよね。デメリットを理解して、得られるメリットの方が圧倒的に大きい場合のみに使用することを検討しましょう。なんとなくこの一文に救われた気がします。知らないことばかりの状態で覚え始めた身としては、あれも覚えなきゃいけない、これも覚えなきゃいけないと己の未熟さを痛感させられる思いでした。いや、最終的には覚えなきゃダメなんでしょうけど。そんな中、「大丈夫だよ、無理なら少しずつやればいいんだから。」という風に解釈出来たわけです。感想まとめC#の入門書ほど簡単ではなく、マイクロソフトの公式書ほどハードルも高くなく、自分にとっては本当に丁度良いレベルの本だったと思います。内容的には知っている事も多かったのですが、細やかな気づきなど改めて認識出来たんじゃ無いかなと思っています。静的コード分析に関しては、いかに今まで自分が怠惰な開発をしてきたかを突きつけられた思いです。馬鹿正直に挙がってくる警告を鵜呑みにするのではなく、警告の重要性を都度確認しきながら精度を上げていく事が必要なので、まだまだ勉強は続きそうです。Onlineの辺りは読み飛ばしたので、機会を見つけてTRYしなきゃな~とも思っています。»profileid:shin21sk日々学んだ事や感動した事などを日々綴っています。慎ましくいきたいアラフォー男子です。archivecontactAmazon.co.jpRakutenはてなブログをはじめよう!shin21skさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。