« 2014年10月 | トップページ | 2014年12月 »

2014年11月の記事

「実践!、コードレビュー」の話

10月の定例会の際に、三文字さんしょっちゅうご紹介している名前ですが)から、顧客先で行われた「ソースコードレビューに関して」を発端として、三文字さん自身の経験や見解の話をしてくれました。

Pict2665
彼はアーキでありサブリーダーでもあり、一流のプログラマーでもあります

プロジェクト中で、レビュワーとしても多忙を極めた結果を踏まえたお話でした。

話の内容全体を下記に要約します。

そもそも「コードレビューとは・・・」
 クソコード(唐突に過激な表現で済みません...)をましなコードに直す!
 レビューしないとそもそもクソコードかどうかすら分からないので、先ずはレビューしましょう!

クソコードとは・・・
 「レビュー中に怒りの渦に叩き落されるコード」
 ・そもそも正しく動かない
   読んだ限り正しそうに見えない
 ・読めない!(読みにくい)
   コメントと実装が合ってない
   変数名や関数名が適当(名前が機能・意義付けを表していない、etc.)
   実装が不必要なほどに、やたら複雑
 ・要領が悪い
   冗長なコードがある
   関数化が適当じゃない
   言語の特性を殺している
   フレームワークの売り・特性を無視している
 ・意図が不明
   設計書と実装に乖離がある
   謎の計算式など

コードレビューはなるべく優秀なプログラマに見てもらうこと
 では優秀なプログラマとは・・・クソコードを書かない人
 一行一行について、背景にある論理を熱く語れる人!

レビューする上での要点
 ・レビューの観点を明確にする
   クソコードの廃止
   パフォーマンス
   セキュリティ
   (余り多くの観点を、同時にレビューしようとしない)
 ・自分のことは棚に上げる!
   遠慮はNG!!
   自分の悪い点も気付いたのであれば、自分の成長のチャンスと捉える寛容さが必要
 ・悪い点は論理的に説明する
   悪いという直勘は7割ほど当たるが、指摘される側を理解・納得させる必要がある
   以降に書くコードが改善されることが目的
 ・お手本になるコードを共有する
   初期ならチーム全員のディスカッションでも良いかも知れない
 ・小さい単位でレビューする
   レビュー自体が30分~1時間程度で終わる単位
   貯め込むと、レビューするのも、直すのも、直した結果を確認するのも大変になる
   時間が無いからいいかな...、とか「直せない」心理を防ぐ
 ・指摘は素直に聞く(聞いてもらう)
   なぜ指摘されたのかを理解・納得して対応する
 ・人格を攻撃しない
   「クソコードを憎んで人を憎まず!」
   今後のコミュニケーションや信頼関係に影響が出るので要注意(プラスにもマイナスにも)

この「コードレビュー」に関しては、先の記事(Seleniumでのテストコード)に付いても言えることですね。

テストコードは「正しい」という前提で動かしますから、テストコード自体のバグは継続的に引き継がれて行ってしまうことになります。
(実際に、このような例が現場でも見られたそうです)

無論の事ですが、レビューにもコストが掛かります
メリットとデメリット、納期、スキルのばらつき...。
様々な要素が有るので、通り一遍のレビューガイドラインを単純に、全員に・全コードに適用すれば良い!、という訳でもありません

この辺は、明示的なレビューガイドラインを共有し、全員が理解・納得していること
現実の運用に際しては、実態に応じて見直していく、その時々でベターな適用の仕方をしていくことも必要です。

さて!、定例会の最後に毎回・振り返りをしているのですが、
「クソコードをレビュー会を実際にやってみたい!」という声が上がりました。

Tryですね!!

「12月の定例会に合わせて準備し実行する」ことに、その場で決まっちゃいました!

毎度毎度で申し訳ないんですが、三文字さん、宜しくお願いしますっ!!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

現場でSeleniumを使ってみた!

11月の定例会にて、某大手サイトの1カテゴリー分の改修開発に、アーキテクト・兼・プロジェクトのサブリーダーとして参画している三文字さんから、現場の実案件にSeleniumを導入した実績からお話をして貰いました。

Pict2667_2参画時点ではSeleniumIDEを使った疎通(正常系をざっと流す)試験にのみ利用されていたようですが、本格的な導入と言うほどではなかったようです。

Seleniumは、当ブログのWebページにも記載させて戴いていますが、決して開発上の「銀の弾丸」として万能の効力を発揮するものではありません

適用のポリシー決めと、メンバー各位への周知と理解・合意の徹底。
コストと納期、コードの寿命、画面・機能の特性など、様々な要素から考えて、自動テストの適用範囲と運用フローを決めなければなりません

また、テストコード自体に対するコーディング規約やポリシー、共通部分を含めたテスト実装のアーキテクチャも決めていなければなりません。

これが抜けていると、テストコードがメンバー間で重複したりで、テストコード量が増えてメンテナンスコストが激増してしまいます!!
(これは、今後に際しても負の遺産としてメンバーに苦痛を与え続けることになります...)

Pict2669_2リリースに迅速性が求められていますし、当然ながらコストも無視できません。

単発のサービスやイベントとは違うので、ある程度長い目で見て、品質を担保しつつ、トータルで低コストで、かつ退屈で品質リスクを伴うな手動テスト(担当者への個別依存性は出来るだけ下げたい)は可能な限り避けたい(モチベーションの低下にも結び付き、これは人間である以上は品質にも直結しますよね)。

Seleniumの本格的な導入には、当初はリーダーさん(顧客側)からは難色を示されていたようですが、部分的&試験的な実施により、実績値を取って(Selenium導入機能と、非導入機能とで工数や不具合件数を比較した)リーダーさんに提示&説明することにより、本格導入にゴーサインを戴けました。

三文字さん得意の、ソースコードを中心とした自動生成技術と併用することで、顧客からプロジェクト単位での高い評価を得ることが出来ました!

これは嬉しい事です!!

しかし、同時に、Seleniumは想定していた以上に運用コストも大きいことが分かって来ました。

テストコードのアーキテクチャの改善と共に、テスト適用対象の絞り込みが重要であることも大きな学習ポイントとなりました。

Pict2670_2これは、インターネット上で検索すれば多々見かける情報なのですが(当サイトのWebページにも記載していますが)、Seleniumでのテスト実行は「テストそのものに驚くほど時間が掛かる」!

まるで、20年ほど前に、「ビルドを始めたら4~5時間かかるので、1日に1~2回とか、帰宅前にしか実行できない」ようなレベルです。

なので、全テストを一気に自動実行するのではなく、テストをブロックに分けて実行しました。

この辺に関しても自動化(テストブロックの自動実行; エラーが出たらそこで止まって担当者に通知メールを流すなど...)をしたかったのですが、諸々の事情によりとにかく時間が無い...。
結局、ビルド管理を三文字さんが引受け、ブロック毎のテスト実行を手動でキックすることになってしまいました...。

次回以降では要改善点ですね。

でも、実現できた様々な点、メリットも有ったし、メンバー間で共有も出来た!

これは大きな収穫だったと思います!!

これを今後のフェーズにも活かしたいし、別プロジェクト間でも横断的に、ナレッジの共有・交換を進めていければと思います。

三文字さん、まだ終了ではありませんが、一旦はお疲れ様でした!&社内共有有難う御座いますっ!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

jenkins導入に関するページを作成しました!

継続的インテグレーション(CI)ツールとして、現時点でよく利用されている jenkins に関して、インストールから運用までの実戦的な情報をまとめて静的ページとして公開しました。
http://aspire.way-nifty.com/majime/TIPS-jenkins.html

元原稿を作成(自社社員用のWebサイト記事として)してくれたのは、またまた若手の渡辺さんです!
毎度・毎度、ありがとー!!

Seleniumとの連携に関しても記述しています
(Selenium関連の情報ページともリンクしています)

こちらに関しても、より良い方法、基準、アプローチ、Tipsなど有りましたら、ご教示戴ければ幸いです。

m(_ _)m


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

"Selenium導入ガイドラインなど"をアップしました!

Webアプリケーションを開発する場合に、Webブラウザを使用して行わなければならないテストも当然・存在します。
このテストを自動化(支援)してくれる道具の一つが"Selenium"です。

当ブログから、静的コンテンツ群としてSelenium関連のナレッジも幾つか掲載させて戴いていますが、今回、社内の若手:渡辺さんが"Selenium導入ガイドラインなど"を資料化しましたので、社外公開致します。

http://aspire.way-nifty.com/majime/selenium.html

「技術的にどんなモノかは分かったけど、どんな基準で、どんな所に適用すりゃ良いんだ?」・「メリットは有るんだろうけど、デメリットだって有るんじゃないのか?」など、実戦的な点に関して触れています。

なお、当然ながら同コンテンツは弊社:アスペア内での経験値の範囲で記載しています。
(今後、弊社内・別プロジェクトでのナレッジなども反映・更新していきたいと思っています)
.....ので、
より良い方法、基準、アプローチ、Tipsなど有りましたら、ご教示戴ければ幸いです。

m(_ _)m


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

« 2014年10月 | トップページ | 2014年12月 »