おいらは「知っていたが、解いたことはなかった」の一人です。ネット上では「知ってて当然」みたいなコメントもありましたが、これが現実?それともおいらの職場だけでしょうか??第1回のふりかえりと第2回社内プログラミングコンテストに向けた改善ポイントそれでは最後に第1回社内プログラミングコンテストをふりかえり、次回の改善ポイントを考えてみたいと思います。抜き打ちで実施したことにより、ロジック力やコーディング力以外のスキル(調べるスキル等)が要求された言語の得意、不得意が結果に影響してしまったバリデーション(入力値チェック)は暗に要求する必要はなかったバリデーションは別の大きなロジックを持ち込むことになり、フォーカスすべきポイントが絞り込めなくなる恐れがあるためただこれはもともと、与えられた仕様を見てその仕様だけに集中してしまう人と、「あれ?こんな入力がきたらどうするの?」という異常系入力に対しても考慮ができる人の有無を確認したい、という意図があった改善ポイント抜き打ちはやめて、事前に告知するPerlで実施することを事前に告知する。苦手な人は基本事項を勉強してもらう言語の得意、不得意による実装時間の差を考慮し、解答時間にはある程度余裕を持たせる。速く解けた人にボーナスポイントを与えるルールもなくすバリデーションは実装不要であることを問題に明記するちなみに、コメントの中にテスト駆動開発(TDD)も不要ではないか?という意見もありましたが、簡単なプログラムであっても積極的にリファクタリングするのであれば自動化されたテストはあった方が良い、というのがおいらの見解です。(速い人が勝ち!というコンテストではないので)おわりにそんなわけで、早ければ来週にでも第2回社内プログラミングコンテストを開催したいと思っています。11月の上旬に第2回社内プログラミングコンテストを開催することになりそうです。次回のコンテストの結果もまたブログにアップします。興味がある人はまたチェックしてみてください。AgileTourOsaka2011に行ってきました。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。blog)はてなブログをはじめよう!JunichiItoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。