codeseek
TOP
.NETサンプルの解説
プログラミング考
codeseekBlog 
勉強会
ダウンロード
リンク
プロフィール
お読みください













累計:
本日
昨日



mail

第22回codeseek勉強会まとめページ

この勉強会の成果をもとに、デベロッパーズサミット2008にてライトニングトークスを行いました。
その時に使った資料が、以下からダウンロードできます。

Developers Summit 2008 - デブサミ 2008>タイムテーブル セッション資料ダウンロード
(全セッション一覧とダウンロード)


http://codezine.jp/devsumi/2008/data/download/14-B/14-B-5.zip (ファイル直リンク)


勉強会で使ったPPTの内容です。

第22回Codeseek勉強会

P.1 なぜプログラマーによってコードがかわるのか
・FizzBuzz問題の流行で再度考えてみた
・みんないろいろ考えているようだけど、作られたプログラムコードがあまりにも多彩なのはなぜなのか

P.2 プログラムコードを見た経験
・その人がこれまでにどのくらいの量・質のコードをみたか
・その人の頭の中にどれくらいの量・質のコードが入っているか
・その人はこれまでにどれくらい教えられたか

P.3 3つの理由
1.プログラマーは技巧を凝らそうとする
2.仕様をどうよむかによってかわる
3.単に知らない

P.4 1.技巧を凝らそうとする
・行を少なくしたがる
・文字数を減らしたがる
・ループを減らしたがる
・代入を減らしたがる
P.5 2.仕様をどうよむか
・基幹系システム
・パッケージソフト
・ゲーム
・誰がお金を握っているか
・仕様書を実現するのかそれとも
   仕様書を実現するという発想か
   客の言っていたことを実現しようとするのか
   客に良いと思うことを実現しようとするのか

P.6 仕様書をどういうものととらえているか
・仕様書通りに完全に再現すべき
・仕様書はおおざっぱに記述してあるだけ ・計算式のようなものだから組み替えてもいいじゃないか

P.7 3.単に知らない
・良いコードを見たことがなければ、自分で編み出さなくてはならない。
・今のやり方があまりよくないとわかっていても、どういう書き方をすれば悪くないものができるのかわからない
・上司がプログラミング事情をしらず、良いコードに書き換える機会をあたえてくれない

以上、全7ページ。

このあと、Fujiwo氏、tkinugaw氏、高萩氏、かるあ氏からいただいた、そして私が書いた、同じことを目的としているのに、違うコードとなっているサンプルプログラムを題材としたディスカッションを行いました。
特に、そのたびに計算するのではなく、計算済みの値を表示するだけ、というプログラムに関心が集まりました。

参加した皆様からいただいたご意見。

技巧に走る
無駄に高速化しようとする
わざと難しい書き方をしようとする
覚えたばかりの技術をつかいたがる
無駄にオブジェクト指向
小さなクラスが大量に!
無駄にテンプレート
無駄にオーバーロード 演算子
オーバーライドされてて、意味不明


Aさん
Webの仕事をされている方
仕様をお客様から抽出する仕事をしている
この作業を間違うと悲惨
条件を抽出すべき
FizzBuzzは仕様書としてよくない


Bさん
FizzBuzzを学生のときにみたことがある
計算式としてとらえる
仕様書としてとらえるという感覚はなかった


Cさん
個人でプログラムを書くときは、計算式の結果通りだったら良いのではないかと思う。
FizzBuzzはいろんなかきかたがあるならば、と、いろいろ考えた
まずは、15でわった、あまりで、Switch文でわけるというもの
結果さえ合っていればという考えのさいたるものはこれかと思う。
全部結果を作っておくというものも。
運用のときこまるので、仕様書どおりにかくべきと、再認識した。
これは、勉強会の成果だと思います。


Dさん
Wikipediaのページをみて、コードを頭で考えた時は、シンプルな、Fujiwo氏、高萩氏のようなものを考えた。
Wikipediaに100までの条件はなかった。
計算してしまったもの。も感心した。固定値がよくないと教えられていたが、あれも、ありだったんだなぁ。と思った。


Eさん
もう、いいつくされているけど、
リテラルはうめるというのに、反省を含めて
Fizz Buzzとくっつけるのもありえるのに、感心した


Fさん
仕様書にてらしあわせてかんがえると、実際に仕様書に従ってかいてしまうと、たぶんとんでもないものができてしまう。
仕様書自体をちゃんと書ける人がかいていないから。
今の仕事をやるうえでは、プログラムを作る人の解釈がないとつくれない


かめがわさん
わたしもどっちかっていうと、ちいさくちいさくしてしまうほう。
かけるコードをおもいうかべながら、仕様書を作りましょう。ということでしょうか。


吉原さん
高萩氏とほとんど同じコードをかいた。
その場でリファクタリング


かるあさん
結果がよければよいではないか派
計算済みにすると、ものによってはバグとなる。素数とか


高萩氏(とっちゃんさん)
仕様書にもいろいろある
Wikipediaみたいなものもあるし、という
これはゲームなので、人間ならばどうするのかという発想でつくってみた。
仕様書どおりに評価した。
コードの高速化はあとで


とても楽しく、ためになる勉強会でした。
もっとこのことで話ができると思います。
またやりたいところです。