ものごとの学び方

ものごとは方法の習得よりも原理原則の理解が大事。
それの有無がよく言われる型破りと形無しの差となると考えています。

ただし、最初は形だけでも真似することが第一歩。
教える方はそれを身につけた過程を忘れ、初学者に対して最初から一番大事なことにこだわりがちです。
正しいやり方に思えなくとも、自分の時と同じように段階を踏むことが大切です。

僕の趣味の話になってしまいますが、車をハンドルだけで曲げたり、ゴルフの手打ちはいけないという話があります。
しかし、荷重移動や体の回転を使ったスイングはまずはハンドルをしっかりきる、クラブをしっかり振ることができるようになってからの話だと思います。

近道は遠回り、普通は手近な答えに満足して本質を疎かにすることを指しますが、最初から頭でっかちに本質を手に入れようとすることも遠回りの近道の1つではないかと思います。

WPFを業務で2年使ってみての感想

この2年ほど業務(新規開発・保守)でWPFを触ってみた感想をまとめてみたいと思います。

XAML習得のコストは必要となりますが、WindowsFormにはない表現の豊かさは大きなポイント。
WPFを経験した後、WindowsFormで作られたアプリを触ると旧世代のUIであることを痛感します。
業務システムといえどもこの印象の違いは大きいです。

Bindingも便利な仕組みですが、現時点(VS2013)では開発環境が貧弱(静的チェックなし、Bindingエラーも実行時のログ確認が必要)でバグの温床となりがち。
上手く動かない場合の原因追及も慣れを必要とします。

更にMVVMを取り入れた場合、よりXAMLWPFに対する理解が必要となり、旧来のWindowsFormよりも技術者の確保が難しいのではないかと。
MVVMでキレイに組むと技術者的には満足度が高いかもしれませんが、保守性に難があり、自己満足で終わりがちではないかと思います。

WPFの最大の売りは多彩なUIによるユーザー体験の豊かさであり、MVVMやBindingなどは必須の要素ではないと思います。
MVVMの原則に従って一生懸命、コードビハインドからコードを追い出したところでほとんどメリットが感じられません。
特にバリバリの業務アプリケーションはWebアプリのようなシンプルな画面制御ではなく、やれこのキーの組み合わせは短縮キーだ、Enter押したら入力チェックしつつ、次の項目へ飛べだの特殊な要件が発生しやすいので、ガチガチのMVVMはその度に標準が破壊されることになってしまいます。

現時点で僕が考えるベターな選択。
画面側のコードはWindowsFormライクなスタイルでイベントベースでコントロールを直接触っていく。
一見、泥臭く感じるかもしれませんが、面倒な挙動をMVVMやBindingで実現する方法を悩む必要もなく、コードビハインドはWindowsFormの技術者でも違和感はないので、保守担当者のアサインなどを視野に入れるとメリットが大きいと思います。
Bindingを使うのであれば外部に実装を晒さない共通部品などなら使ってもよいかもしれない・・・けれど現時点では使わないに越したことはないかと。
業務ロジックはサービス側で。
こうすれば画面側では制約なくコントロールを自由に扱えますし、業務ロジックからはコントロールを確実に排除できます。
画面コントロール⇒Binding用エンティティ⇒業務エンティティみたいなバケツリレーも要らなくなりますね。
自由度を考えるとMicrosoftのXMLWebサービスではなく、jsonを返すSOAPにしたいです。

とにかく出来るだけシンプルな作りが良いと思います。
DataAccessなどもEntityFrameWorkのような重厚長大で遅いものではなく、シンプルなDAクラスを共通部品として提供すればよいと思います。

結局のところ業務アプリの競争力の源泉は凝ったアーキテクチャではなく、操作性を中心としたユーザー体験の豊かさ、開発工数削減と保守性の高さからくる低コストだと考えています。

自分への戒めとして

今、個人的に以下の3点が特に仕事上で注意すべきことだと認識しています。

  • 人の悪口を言わない
  • 問題点ではなく改善案を挙げる
  • 口を開く時は目的を意識して


①人の悪口を言わない
どんな状況であってもこれだけはいけません。
仕事上で失敗があったとしても個人を攻撃して良い方向に向くことは絶対ありません。
当人とのコミュニケーションが断絶してしまうだけでなく、仮に仲間うちで陰口を叩いてその場だけの共感を得たとしても、必ず裏では自分の悪口も言っているのではないかという疑心暗鬼を生み出し、チームの雰囲気を悪くします。

②問題点ではなく改善案を挙げる
①とも微妙にリンクするのですが、個人の失敗や仕事上の問題点をあげつらったところで、単なる不平不満を口にしているだけに受け取られかねません。
必ず改善案・・・それは難しくとも最低限自分としてはどういう方向に持っていくのが理想かという事だけは添えるべきだと思います。
それでこそ議論すべき前向きなテーマとして取り上げる価値が生まれます。

③口を開く時は目的を意識して
僕は会話が乗ってくると、とにかく考えなくしゃべりまくる癖があります。
やはり仕事において時間を使って会話をする以上、目的や着地点は必ず意識する必要があります。
気ままなお喋りはプライベートや休憩時間に楽しめばよいです。

…といつも気をつけているつもりなのですが、性分から来るものなので、毎日失敗を繰り返してしまうんだなぁ。。

良いコードとは

今の時点の僕が考える良いコードとは。

前提はいわゆる業務システム的なもの。
業務ロジックにこそ価値があり、高いパフォーマンスや高度な技術を必要としないシステムとなります。

一言で言えば
『コード流れに沿ってメソッドの名前とコメントを追えば、どのような処理・業務を行っているかが、無理なく自然に頭に入ってくる簡潔なコード』

プログラム言語的な具体的な処理を意識させるさせることなく、文章を読むように理解できる。
その言語を知らなくとも理解できると良いですね。
具体的な処理についても適切な粒度(極力業務的な意味を持たない単位)で部品化されているのが理想。

全体を通して読まないと何を行っているか理解できないコードは保守の際の工数増を招くのでNG。
全体像については簡単なもので良いので、仕様書でおさえておけば問題ないと思います。
そういう意味では良い文章を書けないと、良いコードは書けないのかもしれないですね。

一部の天才エンジニアのスーパーロジックは別ですが、世の中で利用されている大半のプログラムは、僕をはじめ凡庸な能力のエンジニアが生み出し、保守されているので、上記の内容に当てはまるのではないかと思います。

…とスパゲッティコードをこねくりながら思いました。。

わかってきたこと

最近、いろいろな面で、本当に自分が望んでいることというものがわかってきた気がします。
これからはそれに沿わないことには極力時間を使わずに、望んでいるものに力を注いでいきたいと考えています。

ただそれは将来に渡って固定されたものではなくて、年齢や経験とともに移り変わっていきます。
昔はそれを早く固めて、確固としたブレない自分を持ちたいと考えていましたが、今はむしろ自分を固める必要はなく、むしろ変わっていって良い、変化が当たり前と思うようになりました。

闇雲に完成された自分を目指して小さくまとまるのではなく、自然体で流れに乗りながらも新しい自分に日々変わっていく。
もしかするとこれを理解することが僕が大人になるということだったのかもしれません。

ただ、これを理解するまでの日々が全てムダだったかと言えば、その経験があってこそ僕なりに現時点での答えを出すことができたので、それはそれで必要なものだったと思えます。

大事なのは常に変わることができるよう、自分や状況が変わらないことに前提を置いた選択はしないようにすること。
今は問題なくとも将来の自分を縛ることになってしまうかもしれません。
積極的に変わることのできる環境に自らの身を置いていきたいと思います。

旧世代の.NETのパフォーマンスチューニング

古い世代の.NET(Framework3.5)で開発されたシステムでパフォーマンスの問題が発生しました。
そのためチューニング用にプロファイラーが必要になりました。

新しい世代では専用のプロファイラーがVisualStudioに搭載されていますが、中途半端に古い世代かつ専用プロファイラーのないProfessionalで開発をしていると、フリーのプロファイラーの公開が終了していたりして困った感じです。

一応、slimtuneというプロファイラーが使えそうなので試してみています。
Framework4.0で開発は止まってる雰囲気ですが、4.5はラッパーだからフツーに使えるのかなぁ。。
とりあえずなんとなくボトルネックのあぶり出しには使えそうな雰囲気です。

まー、保守サイクルの終わりに近づいていて、最も完成度が高い状況になければならないシステムがいまだに性能問題を抱えているという点こそ問題にすべきだと思うわけですが。。。

やっぱり自動テストは必要

保守を担当しているシステムに機能追加を行おうとしたところ、標準を無視した作りになっており、思いもよらぬ機能がビジネスロジックを共用しており、そちら側を別件でたまたまテストしたところ実行例外となってしまいました。
今回は偶然によって救われましたが、そのまま本番環境にリリースされていたらと思うと冷や汗が止まりません。。
やはり入り組んだ構造、所謂スパゲッティ的なシステムに手を入れるための安心材料として、自動ビルドに加えて自動テストは必要だと思わされました。

完璧なテストコードでなくても少なくとも機能が動作するかどうかくらいはチェックできます。
それだけでも一定の品質は担保できると思います。

(例)データベースの登録に成功することを確認する。

理想はアサーションでカラムごとの登録内容まで確認したいのですが、そこまでは問わない。
とにかくまずは少しでも有益なテストコードを書くことから始めて、少しずつ理想に近づけていけば良いのだと思います。

単なるトラブル対応や機能追加だけではなくて、一歩ずつの地道な改善のサイクルを回すことが、システムを保守するということになるのでしょう。