ウォークスルーまとめ

どうもJudaです。
レビューに引き続き、ウォークスルーについてまとめます。
第8回　ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
点検対象物としては，システムのDFD（Data Flow Diagram），データの正規化結果，E-R（Entity-Relationship）図，データ・ディクショナリ，画面・帳票仕様や操作仕様などの 外部入出力仕様，データベース仕様，モジュール構造や処理機能記述，各種の作業手順書などがある。

「ウォークスルー」を成功させるコツ ――ソフトウェア工学のテクニックがHDL設計を支援 part II
一般にレビューは契約ないしは，標準として定められた正式な認証行為である．これに対して，ウォークスルーはよりインフォーマルな活動を指しており，レビューにはない利点をもっている．

他人の設計ドキュメントやコードを読むのであるから，集中力が必要である．したがってウォークスルー自体は短時間に区切って進めるべきである．集中はする が，時間としては「あっさり」すませるべきだ．前述の『ソフトウェアの構造化ウォークスルー』では，ウォークスルーの時間は30分以内が望ましいとしてい る．

[1]設計された全体の構造
[2]重要で困難な設計箇所
[3]複雑なロジックを実現しているコード






総括すると、

• 短時間で済ませる。
• 長時間やることは不適切。例えば30分ぐらいですべてを確認する。
• 問題全体の構造を理解できるような資料を可視化することが重要。
• 困難な部分に焦点を当てる。
• 問題点を対象としてウォークスルーを行う。

コードレビュー解体

どうもJudaです。
コードレビューがあるので、しっかりと基礎固めをします。
と言っても、まずは既存の解説記事に当たろうと思います。
効率の良いコードレビュー [software]
Effective Code Reviews Without the Pain
レビューの基礎知識
をあげます。

やはり基本的にはコードレビューは、

1. コードの品質の保証
2. 知識の共有/開発者同士の成長促進

が念頭にあります。

また議論としてコードを題材にしているだけであり、それを記述した個人の資質、存在に言及することはよくないことであると注記しています。つまりよくあることであると言っているのです。

またToshiya HASEGAWA氏の意見である、ソースコードを頭から眺めていくことの非効率性についての言及はもっともであると思います。
しかしToshiya HASEGAWA氏の意見に私見を加えるならばペアレビューでの、文法チェックやコーディングルールの遵守の確認は、あまりに機械的な作業であるため、コンパイラやチェッカで調べればよく、人間でなければならない理由はあまりないと考えます。私はペアレビューをもし行う場合には、局所的なロジックの妥当性確認やクラス単体での呼び出し整合性の確認を行うほうがより苦痛（退屈）が少なくなると推察します。

チームレビューでのチェックは、微に入り細に入ったレビューを行うがため、
The developer often feels like it's a bashing session designed to beat out their will. 
（意訳：開発者はコードレビューは彼らの心を打ちのめすために設計された糾弾の打ち合わせのように思っています。）
すべては雰囲気作り次第であるとは言えますが、たやすくそういう場にしてしまうので、参加者すべてがルールを強く守らないといけません。

宿澤経営情報事務所さまの記事では、さまざまなレビューについて簡単にまとめられており、そのなかで挙げられているインスペクションの有用性と落とし穴についても言及されています。この中でも、レビューが個人の資質を糾弾するための記録として利用されるかもしれないという疑心暗鬼のために、自身の資質をPRするために、レビュー自体が活発なものにならない可能性を指摘しています。組織内での政治的な活動の一部が正常なインスペクションを阻害するのです。組織内での政治的な活動のために、協調的教育的な意味合いの近い活動を利用することは本来のレビューの目的を阻害してしまうため、とても強く注意されていますが、やはりそれだけ多く見られる行動であると推察します。

コードレビューの多様な形態やその基本的なルールを勘案すると、

• コードというよりも、そこに記述されているロジックを如何にすれば、特定の目的により合致するようにできるのかを多様な解答の中から提案する場としてレビューがある。
• 個人の資質について言及することは、それ自体がレビューの趣旨に合わず、場の活動を阻害するため、参加者すべてがつよく守るべきルールである。
• 微に入り細に入りコードをレビューすることは、全体的な質を均一にするためには必要かもしれないが、あまりに時間がかかりすぎるため、ここでもカプセル化を推進し、事象の粒度を粗から細に臨機応変にすることが望ましい。
• なぜという問いかけは、その質問自体がコードを記述した個人のみに帰属する問いになるため、絶対にしてはならない。

というのが大枠である。

The Bug Genie

どうもJudaです。
Issue Tracking Systemを検討中で、掲題のソフトウェアが最近出た奴でいい感じという記事を見つけたので準備中。
せっかくのLinux系のマシンもあるので、いろいろ調べています。導入するためにDBが必要なのだが、この関連の知識に乏しいためインストール手前でぐるぐるしてます。

AndroidでのAdapterView-Adapter

どうもJudaです。

今日はAndroidでのAdapterVIewとAdapterの関係についてです。

AdapterViewの継承クラスでは、Adapterを使ってデータと表示を密に連携させることだと思います。
この場合にAdapterViewは大量のデータを高速に表示し、スクロールをよりよくサポートしていることを要求されます。

単純なLinearLayoutの実装では、子要素の数が増えれば増えるほど遅くなります。
これは表示可能領域以外の要素の計測、レイアウト、描画を行ってしまうからです。
また合わせて覚えておきたいことは、Androidでもっとも計算コストの高い処理の一つにLayoutInflaterでのinflateメソッドがあります。XMLからのパース処理はAndroidでもやはり遅いのです。またView要素のコンストラクトも同じく重くなる可能性が高く、あまり多用すると著しい処理コストになります。

上記のような制約がある中で、ListViewなどは高速な表示を可能にしています。
これは、一度生成したViewを再度利用しているからです。
ここからがAdapterViewとAdapterの連携に関わります。
AdpaterViewは、onLayoutでItemを準備します。
この際に、新規にレイアウトする際に、スクロール変位を計算し、それのあと可視領域内に残っているView要素のみを残して、可視領域を外れたものをリサイクルするために格納します。ここでAdapterのTypeIDCount分の格納場所が用意されています。
Viewは排除したあとに、新しく可視領域に出現するView要素を子要素として追加します。このときに使われるのが、addViewInLayoutです。この段階では、単純に子要素として追加したのみであるので、計測処理を行い、のちにLayoutを行います。これはAndroidのLayoutメカニズムの基本です。
addViewInLayoutで追加する際に、利用しているViewは、AdapterのgetViewメソッドによって提供されるものです。このときにconvertViewとしてViewが提供されます。このViewは先ほどの可視領域外にでてしまったViewを格納したところからリサイクル用に提供されたり、また存在しない場合にはnullで提供されます。

大まかな流れはこんな感じです。Adapterには、今回説明していない実装を行うことが求められるメソッドがあります。

静的なIDはデータベースで言うところのIDであり、通常使われるPositionは抽象的な意味でリストの「位置」を表します。またこれを抽象的な意味での「位置」とすることで、内部でソートを行っても、フィルタリングをかけても、とにかく該当するデータを取得する、表現を行うViewを提供することの実装部分をうまく隠蔽できます。

ただ、よくできたInterfaceなのですが、AdapterViewからの実装がめんどくさいです。AbsListViewはそもそもの実装がY-座標系指向が強いので、X-座標系向けではありません。

Android覚書

どうもJudaです。

Androidについてあれこれ。

• layoutファイルはlayout*/*に配置される。
• layoutファイルでのandroid:*は、xmlnsで定義されているから利用できる。
• xmlnsを新しく定義すれば、別の区切りを使えるようになる。しかしEclipseでの入力補助はうまく効かなくなる。
• 別ファイルに別のlayoutを作成できる。
• 別ファイルに定義したlayoutは、で呼び出せる。
• プログラムから呼び出す場合には、LayoutInflaterを利用する。AndroidのVersionによって呼び出し方が異なるので、要注意。
• mergeをrootにもつlayoutは、基本的にはLayoutInfalterからLayoutを呼び出し、親要素に対してアタッチすることが必要になる。
• またmergeでアタッチする場合に、親要素はFrameLayoutなどの一部のViewGroupの派生系に限られる。
• merge機構を利用して、構築済みのレイアウトを使うカスタムViewコンポーネントを作成できる。
• mergeする場合には、親要素とは継承したクラスのことになることが多いので、FrameLayoutなどを継承することで処理を簡略化できる。
• inflateしてアタッチした場合はidなどの設定がずれることがあるので、LayoutInflaterのinflateメソッドの戻り値に対して、findViewByIdなどを使うことが必要になる。
• onLayoutは、親から呼ばれ、表示可能領域が親要素からの相対的な引数で与えられる。
• ViewGroupの系列にあるクラスコンポーネントを開発する場合には、onLayoutやonMeasureを実装することが、必然的に必要になってくる。あとはaddViewの実装を操作するとXMLでのLayoutで子要素を書く数を変えられる。
• onLayoutでは、子要素をレイアウトすることが趣旨である。
• onLayoutで呼び出す子要素は自身からの相対位置で子要素に対して通知する。その後の配置と描画はここのViewに依存する。MerginやPaddingの取り扱いについては、不定。
• onMeasureは自分自身のサイズと子要素をもつ場合には、子要素が確保できるサイズに関して通知をする。はず。。。
• onMeasureでは複数のモードを確認する必要性がある。EXACTRY,AT MOST,UNSPECIFIEDがある。
• Androidではインスタンスの生成はとてもリソースを必要とする。またLayoutInflaterは更に多くのリソースを必要とする。XMLのパーサが重いらしい。
• AndroidではViewの作成が重いため、ListViewとAdapterViewの組み合わせでは、利用したViewを再利用する機構を採用している。
• ListViewでは、Scrollによって表示内容が変更された場合に、表示しているViewを減らしたり増やしたりをしている。減らす際に、ViewをRecycleBinに入れておき、なるべく再利用する。またViewの種類が幾つかある場合には、RecycleBinを増やし、種類を識別して対応している。
• ListViewやScrollViewはaddChildの利用を制限してる。
• 独自のクラスを作成し、属性を増やす場合には、value/attrsで記述する。基本的な動作はAndroidのソースコードを参考にすることがよい。またEclipseではattrs.xmlの記述をサポートしてもらえないので、よりソースコードを参考にする必要が出てくる。
• ListViewはAbsListViewを継承して作成されているが、あくまでVerticalな動作のみを期待しているので、HorizontalなListViewの実装はAdaperViewなどから実装する必要があり、動作の速度をあげるために、前述のRecycleをする機構を組み込む必要がある。この機構で重要なのは、onLayoutで表示しなくなる要素の確認と、表示しなくなったところを復元するために再度Viewを増やすこと、そしてスクロールオフセットを考慮して、子要素を配置することである。
• Scrollerを利用すると、スクローリングやフリックなどの処理を代行させられる。ただし痒いところに手が届かない場合には、再実装が必要になる。
• GestureDetector.SimpleOnGestureクラスの実装は痒いところに手がとどかないので、実装内容を確認して、別の実装を組み立てることがより細かな設定を行なっていく上で必要になる。
• onDrawを利用することを考えるならば、Drawableの利用を考慮することを推奨する。またsetBackgroundとの兼ね合いが問題にならないように注意したい。
• AdapterViewでinflateしてEventを作る場合には、特定のイベントで内容を更新する場合には、そのイベントリスナーに登録する実装はAdapterViewに配置しておかないとうまくnotifyを呼び出せなくなる。
• 上記のような実装は、階層性を持ったカスタムコンポーネントにそれぞれの処理を実装させてしまうと発生する。（個人の設計ミスであるとは思うが、テストなどをしながら開発しているとよく起こると思う。）
• ListViewへのrequestLayoutは子要素のonLayoutの呼び出しを保証しないので、子要素が変化する場合には、子要素自身のrootへrequestLayoutが流れることが必要になる。

読書について

どうもJudaです。

つらつらと

読書をしながら線を引いたり、

ノートを取ったり、

最近は読むという行為から一歩踏み込んで、

能動的に取り組んでいる。

しかしこの行為をすればするほど、

まとめるという行為が如何に難しいのかが、

明瞭になってくる。

まとめるために能動的に取り組んでいるのではないが、

ノートの分量は増えるし、書き込みも増えてくる。

そうなるとやはり視認性が落ちるし、網羅性も悪くなる。

だんだん頭の中が混線しているような感覚に囚われる。

そういう感覚を契機にして、ふっと、まとめようと思う。

しかし此処に至って、自分が如何に濃度の低い読書をしているのか

突きつけられる。うまくまとめられないのだ。

まとめようにもそれらをまとめていくための柱がうまく決められない。

作者の考えをなぞりながらも、自分の言葉で補足と訂正をおこなうのだが、

事柄をまとめていくための柱と道筋がうまくまとめられない。

なかなかままならぬのだ。

高等教育を受けさせてもらってはいたのだが、

この程度のことも満足できないことに情け無さを感じるが、

しかしやらねばならぬから、じりじり道を登るしかないのである。

Mac OS X+XCode4+Boost

どうもJudaです。

今日はMacOSXでXCode4を使って、Boostライブラリを利用するときの話。

一般的にはMacPortをつかうみたいですが、i386のアーキテクチャ部分がうまく噛み合わなくて、ライブラリがビルドできなかったりするので、直に使う方法をとります。

基本的にはMacOSXと云えども、Unix系なので、Boostをビルドしたりはできます。

BoostをサイトからDownloadして、展開しておきます。

この段階でstatic libraryを使わないものは利用可能な状態になっています。

XCodeにインクルードパスを追加するときには、VisualStudioとでは考え方がちょっと違って、「ヘッダーを検索するためのパス」を登録しなければいけません。そのため、項目の名前がSearch Header Pathsになってます。User〜というものあるのですが、違いがわかりません。ライブラリに関しても追加ライブラリパスは「ライブラリを検索するためのパス」を登録ということになります。

とりあえずstatic libraryのいらないものはこれでなんとかなります。

次にstatic libraryとかですが、BoostをDarwinでビルドする事になります。なんだかわかんないですけど、BoostのGet Start 〜で書かれているStepにしたがって行います。この時に bootstrap.sh --Prefix=/Path/to/installっていうのがあります。

Unixに慣れている方は普通なのかもしれませんが、WindowsのVisualStudioから来た人にはわかりにくいので、

./b2 というビルドコマンドを発行するだけだと、ビルドをするだけで、./Build installだとさっきの--Prefixで指定したパスへ生成物と必要なものをコピーします。Defaultだと/usr/localになってます。このディレクトリはアクセス制御されていて、読み込みのみの許可になっているので、sudo ./b2 install という風にしてやらないとうまくコピーが出来なくて悩むことになります。

あとはDarwinがGCC4.2のコンパイラを使っているので、XCodeのDefaultのコンパイラ LLVMとは生成物の形式が違うので、dynamic link をさせたときにエラーで落ちる原因になります。要注意です。

んで、実はProgram_Optionsを使ってみようと思っていて、組んで、ビルドはできるけど、うまく実行できず。

CommandLineOptionがうまく機能していないくて大変悲しい目にあってます。

XCodeでCommandLineOptionを指定するときにはXCodeのメニューバーのProductに該当するItemの下の方のEditSchemeで表示されるDialogのRun Argumentみたいな内容の奴にCommnad Line Optionが云々というのがあります。そこを設定すれば一応起動時の引数にはなるようです。

CppCheckの雑感

どうもJudaです。

CppCheckを利用してみました。

とりあえず日本語の動作がクサイので、setlocale(LC_ALL, "");でビルドをする。

動作的には問題がなさげ。

検出件数とかは、よくわからないけど、未初期化の指摘をしてくれるのが、個人的に嬉しい。

現在わかっている困った点はQtで作成されているGUIで日本語が読めないのか、そもそも日本語パスの扱いがおかしいのか、不明だが、利用できない。

これによって、日本語パス以下にあるファイルの解析がままならない。

手っ取り早く、.NET FrameworkでFork用のGUIだけ準備すればいいのではないかと思う。あとは、Includeディレクトリを常に覚えるのが困るので、とりあえずそこもなんか変えたいと思う。

そんな感じ。

やるきで学ぶTDD

どうもJudaです。

[ブログ紹介] やる夫で学ぶ TDD

TDDについてまとまっているので、備忘録。

C++における様々なツールについて

どうもJudaです。
最近CIについて、かなり興味が湧いてきました。また、それ以上に体系的なテストの重要性を痛感している今日この頃ですが。
CIを調べながら、いくつかのツールによる自動化も調査しています。現状ではまだ列挙段階ですが、いくつかのジャンルで情報をまとめておこうと思います。
インスペクションツール
CheckStyle
Uncrustify
Artistic Style

（追記：02/2011/09）Simian

静的解析ツール
CppCheck
ドキュメント化ツール（＋可視化）
Doxygen+Graphviz
OpenSource で利用可能なものはこんな感じですかねぇ。
とりあえず多くの人々がこれらを公開してくれていることに頭が下がります。
Doxygen+Graphvizは導入済みですが、これを自動化して、
Commit毎にドキュメント化するようにするところから初めてみたいですね。
あとはインスペクションツールでリファクタリングの目標を絞ること。
『パターン指向リファクタリング』、
『デザインパターン』、
『実装パターン』、
『リファクタリング』
と開発に関する良い指針となるような書籍を読み進めています。