SmartUI。

たまに始まるプログラマ向け読書タイム。Smart UIというキーワードから初めて見た。
ドメイン駆動設計に出てくるアンチパターン(反面教師)。
またの名を画面駆動開発。動く画面は大量に素早く作れるが、統合するときに大体破たんするデスマの温床。

この約2年いじってるコードがまさにコレ。(何度も愚痴ってるけどな)
読んでた記事にそういった状況から抜け出そうと奮闘した記録を見つけ、それを読んでると結構、自分がやってる事と被るポイントが。
その中でも自分がこれはよかったと思ってるのは、Data Access Objectを作ること。
正直自分では、毎回SQLをコードに書いて、DataReaderから適切な値に変換することが嫌いで嫌いで、というか

var a = dr["FiledsName"]:

ってフィールド名打つときに絶対面倒くさいから、EDIの機能でコードコンプリートさせるために専用クラスを作るってところから始めており、正直ドメイン駆動開発のための技というわけではない。
が、やっぱり楽ですね。下準備すると。

あとはただ、ひたすらに記述量を減らそうと奮闘中。
同じような挙動をする部分があったら、イベントを共通化したりしてコードを減らしたり。
前は同じオブジェクトが30近く並んでて、そこにデータを「同じように」表示するのに、30回コピペされたコードを見て殺意を覚えたこともあったな。

とはいえ、自分も結局Smart UIで育ってきて、画面駆動開発アタマなのは自覚済みで、面倒くさいと途端にいつものコードかいているので注意が必要ですなー。というかね、だれかと確認しながら進めていきたいよ。自分のやってることが正しいのかわからない。

しかし、ただひたすらにコードを書いているおかげでいろいろ勉強はできてます。
コードを減らすために、せっかくC#を使っているんだからとC#の機能をいろいろ学んで、できる限り活用するようにしていく上で、Linqの概念がしっかり理解できたのはよかった。その感覚を足掛かりに関数型ライクな概念の勉強がそれなりにスムーズに理解できたりできて、その辺からテスト作りやすい作り方が見えてきたりと、そうね、もっと10年位前にこういう意識持ってたら、出遅れ感なんてなかったし、今まで作り続けてきたクソコードも、もう少しうまく動いたかもね…

で、最近になってpaizaで遊んでるけど(Dランクをサクサククリアして快感を得ている段階)
C#を選択してもLinqとCollection.GenericがデフォでUsingされてないのね…確かにDランクの課題なんぞLinqで一発で書けたりするから正直「そこをみたいんじゃねぇwww」って思われてるかもしれないけどねwwww
スポンサーサイト

書きなぐり

今更勉強中。Scala で書く tetrix

やっとコードが読めるようになった気がするぜ…

なお、specs2がコンパイルで通らないってか、importが効かないって丸一日悩んでたけど、sbtのフォルダ構成を理解してなかっただけでした。
spece2のコードは/src/test/scalaに置かないと行けないのね…常識すぎてガイドにもかいてなかったね。

記憶のためにメモ。

あと仕事の愚痴。
課題管理の場所が何故か3種類に。
Excelファイル(自社作成)
Excelファイル(客先作成)
Bug Tracking Ssystem(自分と客先担当者利用中)
…たのむからBTSで統一させてよ!!

なお現在仕様書もBTS内のWIKIに書いてます。

印刷できるようにしてくれと社内に言われてます。PDFは吐けるよ!!!
(口語的表現が多数あるのが問題ですが、それは見直してる)
なお、客先担当者は、redmineのサイトが残ってればいいです。仕様書もそれで問題無いです。ってか紙とか邪魔ってスタンスです。物分りが良くて嬉しい。

というわけで、メンテしてないExcelファイルをメンテしますよー(^o^)

頭の整理のために吐き出す。

あと眠気覚まし。

■ソースコードを整理するの気持ちいい。
引き継いだプログラムのうち、最も重要な機能のプログラムがもうコード追っかけるのがあまりにも苦痛なためいろいろと整理をしている。C#でのWindowsフォームプログラムなんだが、メインのフォームにすべてが記述されていて、フォームのコードが17000行に登っていた。客先に言われてあとからあとから追加機能を実装していったのはわかるが、せめてコードの分離をして欲しかった。

フォーム変数で扱われる各種値。
何千行に渡るF10_Clickイベント
その中で幾度と無く繰り返される「同じような」コード。
何階層目かもわからないネスト。
何重にも囲われている。#region。

実際に処理を追っかけるとすげーイライラしてくる。いまのコードの位置が何をしているかわからない。だいたい、F10_Ckickか、txtCode_Validationのどこか。保存処理をしているんだろうけど、追加(Insert)なのか更新(Update)なのかで処理が分かれるが、単純にIf分岐してるだけで、どっちも同じ関数内。しかもそれぞれ処理が長大なので、結局いまなんの処理をしているかわからない。その上、同じような処理が繰り返し(微妙に違っているけど)書かれているため、更にどの処理をしてるか把握できない。

んー…自分の状況把握能力が良くないのかな?

一応、それぞれの処理ブロックを#regionで囲んでるけど、それを関数にしろよ。region展開しても、いまのコードの位置はF10_Clickなんだよ。ラベルは一番上にスクロールしないと見えないのに1000行近いコードがregionされてんだよ。わかんねーよ。

▼よくわかったこと。関数名って超重要。いや「名前」ってホント重要。

■ユニットテストを使うようになって。
テストし易いように設計するようになる。機能がいい具合に分割できるように考えられる。関数FにAを入力したら、Bが返されるって動きを基本に考えるようなった。副作用とかマジで邪魔と感じるようになってきた。やっと、関数型プログラミングが魅力的に見えるようになった気がする。あとは、動作確認が簡単。デバッグ開始→フォーム起動→(事前に必要なデータ登録)→ボタン押す→結果確認とかマウス触るのめんどくさい、メニューたどるのすら嫌じゃんとか思ってたけど、Ctrl+R , Ctrl+T→結果確認に。

しかし、え?今更?恥ずかしいッて言われても仕方ないこと書いてるな。
恥ずかしいね。ちゃんと手法を勉強しなかった自分が。

■C#のイベントをひたすらまとめる。
既存コードに多いのがこれ。同じような処理やチェックが入るけど、コントロールごとに処理を書いている。数量チェックを行う場所が5こあったらその分、Validationイベント関数とチェック関数をかいてるし。C#のイベントには同じイベント関数を使えること知らない人が書いてたのか、そういう社内規約か知らんが。実際に10個のチェック関数が一つに、Validationも10個が一つに。20個の関数が一つにまとまったわけで。登録前の全体チェックもforeach使ってさっくりかけるわけで。コントロールを特別視しないようになった気がする。あるプログラムなんか20個の同じオブジェクトにそれぞれイベント割り振ってたからな。今なら

foreach(var ctl in TargetCtrools){
ctl += new EbentHandler(EventFunction);
}

でいい訳で。

■社内規則vs言語機能
既存コードみると結構あー規約でこう書けってなってんだなーというところが見受けられて。完全に言語機能を活用出来てないよねって思った。それなりに歴史ある会社っぽいから、いままで積み上げられた経験と技術の結晶なんだろうなと思うけど。もっと楽になる方法はあるよねーと思うわけで。今回の仕事で本格的にC#の言語仕様を勉強したけど、こいつは本当に「コードの量を少しでも減らすために」「コードが少ない=バグの入る余地がヘる」というああ、当然のことだよねってことがいかに重要でそのために如何なる工夫をしてきたか思い知ったわけでございます。前回のプロジェクトでLinqってほんとに有用なの?とか思ってたけどごめんなさい。今となってはLinqサイコーです。なんでおまえらIEnumerable実装してないの?Collectionなの?って気分です。
(そりゃその頃なかったからよ。)
とはいえ、今のところ一人プロジェクト(でも規模は最大級w)でコードも実装も設計も好き勝手し放題にやってるからこそ、そうやって気楽に言えるわけで、実際に他のメンバーに依頼したところなんかもう気持ち悪くて仕方ないから書き換えちゃってるからねー。またお願いって言ったら嫌がるだろうなー。

■とはいえ
こうやってガリガリとコード修正してますが、もちろんその新しいコードが正しいかはわかりません。
綺麗なコードになっているかもわかりません。あ、自分にはわかりやすい。
とはいえ、既に1年前のコードと今書くコードを比べるともう1年前が汚くってww

でもまぁ規模とやりたいこととやってることがわかってるからこそ、こうしたら、ああしたら、こうあるべきってのがわかるんですよね。
幾つか本を読んでると、「最初は捨てるつもりで作れ」って言うのがよく分かる。
2回作れるくらいの余裕を持つべきなんでしょうなー。宇宙兄弟でも月面ムーバー作るときにムッタがそんなこと言ってたね。

CausesValidationについて

自分向け開発メモ:.Net Framework
CausesValidationプロパティについて。
大雑把にいうと、「これがFalseのコントロールにフォーカスが移っても、元のコントロールのValidationイベントが発生しない」というプロパティ。

でも、FalseでもValidationイベントが発生していた。なぜだ。

http://d.hatena.ne.jp/dotnetmemo/20060702/1151839515

あと、PanelなどのコンテナのCausesValidationも影響するので注意が必要。要はPanelのCausesValidationがtrueになっているとその中のButtonのCausesValidationがfalseでもValidatingイベントが発生するということ。



それかー。確かにパネルの同プロパティいじったら想定通りの動きになった。
9年も前の記事に助けられた。.NETのドキュメントにそんなこと書いてあったか?

なお、改修前のプログラムでは、コードに直接検証が不要なコントロールをifの条件分に直接記入したメソッドを作成し、Validationイベント毎にそのメソッドを呼び出していた。せっかく同様の動きができるプロパティがあるなら使うほうがいいだろ。コード量削減的に。

しかし、マスタ1画面のコードを改修…というか書き直しするのにこの時間かかるとは…さすがに全画面でリニューアルは時間がかかりすぎるか?

お勉強:アジャイル プラクティス


アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
(2007/12/22)
Venkat Subramaniam、Andy Hunt 他

商品詳細を見る


よんだ。
1.自分の知識が間違ってないか確認。
2.まだ知らないことを勉強。
3.やるといいことを確認。

結果。
1.概ね間違ってなかったと思いたい。
2.大体どっかで読んだ気がした。
3.テストしろ、絶対テストしろ。

あと、現状の自分のふりかえりをしてみる。
重要な事はやっぱりコミュニケートです。顧客やチームとの。
まぁ、現在のお仕事のプロジェクトチームはお一人さま状態なので、基本は顧客とのコミュニケーションということですが、幸いな事に、毎週2日は客先作業となっており、アジャイルっぽくいうところの、イテレーションが1Weekでゴリゴリやれてます。お陰で双方、仕事が進んでいる感触は持てているので、かなり良好だとは思います。まだ速度が足りてないけどね!

一番ディスコミュニケーションなのは上司陣とユーザです。
お願いですから、お互いリスペクトの心を持つようにお願いしたく思います。
あと、「今まではこうしてました」って言っても通用する相手じゃないことを早く気づいてください。
あなたの進め方とユーザの進め方には根本的に意識のズレがあります。
いつまでも「最初の設計にはない」「言い分を聞いてたらきりが無い」「言うことがコロコロ変わる相手が悪い」と言ってますが、それこそこの本読んでくれ。マジで。
ユーザは最初から(数年前の別システムの構築の時も)アジャイルな思考の持ち主です。(僕としてはありがたいことに)

ちなみに、今んとこ上手くやってるようなのも、今回のプロジェクトで導入したユーザのWebサーバにRedmineとSVNを独走気味にぶっこんで、ユーザーにRedmine使ってもらってるからです。これ便利。相手も絶賛。今までのExcelの課題表は(僕としては)その時に切り捨ててます。ユーザーもそれをわかっていて、必要なことは改めてRedmineに追記していくので、課題量が視覚化され直されるってもんです。その他出てきていないことは、見てないか、要らないか、まだ理解出来てないってことです。最初からこの仕組導入して、1年かけて書き直すべきだったよな…いまの仕事…

正直軽く見積もっても、まだ半年以上かかると思いますが、がんばれてます。
楽しいし。やっと出口が見えてきたと思う。

次はアジャイルサムライを読んでます。
どっちも会社の後輩が実費で買って会社においてくれてるから読んでいられるんですけどね。感謝。

 HOME TOP next>>