ウォークスルーまとめ

どうも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-座標系向けではありません。