「コンテキストなしでソフトウェア開発を話すのは・・・」が共通認識になってほしい：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
コンテキストとは直訳すると文脈。本エントリでは開発の前提や事情を示す。結果や状況は必ず、コンテキストと対にして考える。前提や事情を示すことで、結果や状況の共通認識を得やすくすることを目指している。コンテキストの定義手順は、まだ明確化されてはいないが、何らかの結果や状況に影響を与えうる要因を挙げることからはじまる。 エンピリカルソフトウェア工学での推奨の話だが、カンファレンスや勉強会等をはじめ他組織との交流時には習慣になってほしいなぁと思う。過去のエントリ（「なぜウチではうまくいかないか？」を考える開発コンテキストの解説」）にも書いた。 勉強会等で議論していると「分かり合えるはずなのに、何か通じてない」と感じるときにはコンテキストの違いを意識してみると、うまくいくかもしれない。極端な例を挙げると超高信頼性ソフトウェアと市場投入への早さが重要なソフトウェア。前提を明示せず話を進めるとかなり食い
「名前の適切さは間接的に品質に影響する」という仮説：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソースコードの変数名、メソッド名、設計ドキュメントのサブシステム名として「こだわってつけてるなぁ」という名前は、時間をかけて作成することができた部分であり、その周辺もきちんと作りこまれている。逆に名前が安易につけられていると時間をかけられなかったことを示していて、品質に問題があるかもしれない、という仮説を考えた。 ソースコードの変数名へのこだわりというのはよく聞くが、設計時に「・・・部」というようなサブシステム名にどれくらい時間をかけてらっしゃるだろうか？名前にこだわる理由は自己満足という側面もあるだろうが、メンテナンス性に響く。また、他の開発者への誤解の可能性を少なくするだろう。 「処理部」というような名前は確かに中身を表しているが、理解容易性という点では少し疑問が残る。「処理」がシステム固有の言葉として使われていれば別だが、どのような機能であれ、何らかの処理をするからだ。ソースコードの
ソースコードを書くスキルよりも読むスキルが求められる理由：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソースコードを読むスキルと書くスキル、読むスキルのほうが多くのエンジニアに求められる。理由は、書くスキルはプログラマ中心に求められるのに対し、読むスキルは、他のエンジニアにも求められるからだ。たとえば、以下のような場面で読むスキルが求められる。 設計、コーディングの前に、既存のコードを流用して開発してよいか？ コーディング中に、他の担当者の書いたコードとの整合性はとれているか？ テスト開始前に、そのコードでテストを開始してよいか？ テスト中に発見された不具合の修正を受け入れてよいか？ 検収完了としてよいか？ 大規模化が進めば他人のコードを読まずにはすまされない。派生／保守開発の割合が高れば、既存のコードを読まずには改変ができない。今後もこの傾向は強まっていくだろう。コードを書くスキルと比較すると、コードを読むスキルのほうがより多くの開発関係者に、より多くの場面で求められる傾向にあるといえる
『Javaソースコード読解力をはかる』大人の夏休みの宿題としていかが？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Javaで書かれたソースコードの理解と機能追加の妥当性の判断をするもの。ここ（我々の研究グループのWeb）からオンラインでソースコードを読み、無料で参加できる。結果は個人情報を削除した上で、3, 4か月程度でWebで公開する予定。ご自身のスキルの位置づけに使ってもらえればと思う。同時に、その結果から得られた知見を論文化することを目指している。 今回診断できる読解力は、次のとおり。 与えられたソースコード全体の理解 機能追加（機能改善）のためのソースコード（1との差分）の理解とその差分により不具合が起きないかどうかの判断 1のソースコード理解は、必ずしもプログラマだけの仕事ではない。コーディングを誰か他のメンバが担当していた場合でもそのソースコードを大まかに把握しておくことは必要になる。また、パートナー等へ外部委託する際には、納品・検収時に納品物を大まかに把握しておく必要がある。ソースコード
ソフトウェアレビューでは問題点の指摘だけでなくよい点も指摘したい（コストの範囲内で）：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
国際会議、国内会議にかかわらず研究論文のレビュー（査読）書式があり、多くの書式に「積極的に評価できる点」という項目がある。査読者はここにレビュー対象の論文の評価できる点を記入する。 査読の主目的は、その論文を採録とするかどうかを決めることにあるが、そうすると問題点の指摘に目が行きがちになってしまう。「積極的に評価できる点」の項目には、これを抑止する機能がある。よいものが公開されなければ、その分野全体が沈んでいってしまうからだ。 通常、著者がいない場で実施される論文の査読であっても「積極的に評価できる点」が存在する。ソフトウェアレビューは、問題点の指摘と修正が主目的の場合が多いが、レビュー対象の作成者がいる場では、できるだけ「積極的に評価できる点」も指摘すべきだと思う。 私の新人時代もレビューとなると気が重かったのだが、その理由は「これはダメ」がリスト化されるからだったように思う。「ここは伸
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
