2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2010年12月28日

これは自分の反省でもあるんだけど。

継続的統合をやってると、作り壊しっていうのが、どうしても
避けられないのね。

作り壊しっていうのは、ある機能を変更や追加したときに、
他の機能を壊しちゃうっていうこと。

で、そのために回帰テストだとか、自動テストだとかを
やるわけだけど。でも、テストで作り壊しちゃったことを
知ることはできても、防げるわけじゃない。

作り壊しを避けるには、変更を加える機能だけじゃなくって、
その変更の影響範囲も見極めなきゃいけない。でも、
そんなもん、なかなか見切れるもんじゃないんだよね。

で、実際に作り壊しちゃったと。まぁ、簡単に直せるん
なら直しゃいいだけなんだけど。

ハマるパターンの典型がモグラ叩きってヤツ。こっちを
直したらあっちがダメになっての繰り返しになるパターン。
こうなったときは、腰を据えて設計を見直すとかしないと
ダメ。それこそ見切るくらいのつもりで。

もうひとつ、確かに回帰テストは失敗するんだけど、
仕様変更にしちゃってもいいんじゃない?っていうケース。
要は、製品コードじゃなく、テストのほうを直しても
いいんじゃない?っていう。

まぁ、実際、テストのほうを直すこともあるんだけど。
数値を見るテストなんかは変更の影響を受けやすくって、
テストが仕様の変更に追いついてないっていうことがある。

でも、そんなのはほんの少ししかないんだよね。

安易にテストを直す、つまり仕様変更を許しちゃうと、
テストの意味が薄まっちゃうんだよね。やっぱり、テスト
直すのって後出しジャンケンみたいなもんだしね。

それと、やっぱり、製品コード直すより、テスト直すほうが
楽だよね。でも、そういう安易に流れる姿勢は、必ず品質の
低下をもたらすと思うんだよね。品質のハードルを下げちゃう。

だから、作り壊しちゃったときでも、安易に妥協しちゃ
ダメなんだよね。そこで踏ん張らないと。

--

だから、自律心ってのがほんとに大切なんだよね。

ちょっと話が変わるけど、マニュアル仕事ってあるでしょう。
マニュアルに従って作業するだけの簡単な仕事。

まぁ、確かに、やらされてるほうは退屈だよね。

でも、自発的にマニュアルを作るんだったら話は変わって
くるでしょう。

マニュアルを作るっていうのはルールを作るようなもんで。
それを自分たちで作って自分たちに課すわけで、それは
自律ってことだよね。

『どこでも、誰でも、簡単にモノが造れる』って聞くと、
マニュアル仕事のように感じるけど、でも、それを実現
する道程はマニュアル仕事じゃないし、新しいモノを
造るとなれば、また新しいルールを探すことになるし、
そういう過程がずぅっと続くわけだよね。で、そういう
過程に参加できれば働きがいも感じられるんじゃないの?

--

一人が生み出した工夫をみんなに広めればマニュアル
というものになるっていうこともいえるんじゃないかな。

本家Permlink


2010年12月27日1

他人が書いたコードをいじるときには、細心の注意を払う
のが当たり前なんだよね。それが礼儀といってもいい。

たとえばLinuxならLinuxの、GNUならGNUの、BSDならBSDの
スタイルというものがある。そういったコードをいじる
ときは、その周囲のスタイルに合わせる。

インデントは4スペースなのか、8スペースなのか。
インデントはタブなのか、スペースなのか。
関数のシグニチャはどう書いているのか。
CamelCaseなのか、_でつないでいるのか。
名前は短縮形なのか、フルスペルなのか。

このくらいはコードを見てパッと判断しなきゃいけない。
そして、それに合わせて書かなきゃいけない。

そういうことができないのではあまりにも無神経だし、
他人のコードをいじる上での準備が足りてない。他人の
コードをいじるんだから、そのコードを読む、観察する
というのは当然やらなきゃいけない準備なんだよね。

--

情報処理技術者試験の中でバージョン管理ってずいぶん
軽く扱われてるのね。

ブランチやマージといったバージョン管理の基本は、
今のソフトウェア開発には必須の概念だし、実務でしょう。

--

しかし、ITパスポートの出題範囲広すぎ (笑)。なんか
ビジネス書でも読んでるみたい。


本家Permlink


2010年12月27日

プログラミングには、孤独を愉しむというところがある。

これは別にペア・プログラミングを否定しようという
ことではない。

よい実装方法が思い浮かばず、独り悶々とした時を過ごす。
それもまたプログラミングの愉しみなのだ。

快調に動いていた指先がピタリと止まる。それまで完璧と
思っていたロジックに穴があったことに気づいたのだ。
穴を塞ごうとするが塞がらない。別な方法はないかと
必死になって探す。でも、見つからない。考えても
堂々巡りを繰り返す。

傍から見れば、当人に何が起こったかまったくわからない。
『考えごとしてるな』と思ってくれればいいほうで、
『眠いのかな』、もっとひどいと『暇そうだな』などと
思われてしまう。

苦悩を周囲に打ち明けるのもひとつの手ではある。
しかし、その苦悩を説明するには、背景まで説明
しなくてはならず、言葉にするのももどかしい。

そうして、独り考えに耽ることになる。

一種産みの苦しみではあるのだが、プログラミングならではの
時間であり、それを愉しみと呼ばずして何と呼ぼう。

本家Permlink


2010年12月21日

さすがに、今どき、インスタンス変数はprivateにする
のは常識なんだけど。でも、publicなsetterがあったら
台なしなんだよね。

publicなsetterっつっても、状態遷移を引き起こすような
ヤツね。これは特に危ない。

1つのオブジェクトを状態機械と見なしたら、それに外部
から作用できるのはイベント入力なんだよね。状態の
遷移先っていうのは、そのオブジェクトが決めるもの。

状態遷移を引き起こすようなpublicなsetterがあるって
いうことは、状態遷移がオブジェクトの外部で決まってる
ってことで、何のためにオブジェクト使ってるの?って
話になる。

だから、状態遷移を引き起こすようなpublicなsetterは
除去するのがリファクタリング。

--

publicなsetterがあっても、そのクラスのメソッドでは
インスタンス変数に直接アクセスしてるってことは、
ごく普通にある。

で、上で書いたみたいなsetterを除去するときは、
リファクタリングでいうところの自己カプセル化
フィールドが役立つ。

特に、今どきのコンパイル型言語ならばツールの支援が
受けられて、どこでsetterが呼ばれているかが一目瞭然に
なる。

--

ボタンが押されたら、(インスタンス変数として表現されて
いる)フラグを立てて、それに続く一連の処理の途中で
そのフラグを見て処理を変えて、その直後にフラグを
落とすっていうのはダメパターンなのね。

だったら、そのフラグを引数として渡したほうがわかり
やすいし、もしかしたら、本来違う流れなのをムリヤリ
ひとつにまとめてるのかもしれないし、より構造的な設計
(Stateパターンとか)を必要としているサインなのかも
しれない。

--

製品っていうのは共有地なんだよね。

メーカーにとっても、顧客にとっても。

元請けにとっても、下請けにとっても。

本家Permlink


2010年12月01日

うわ、ちょー久しぶりなんだな。まぁ、入力が少なければ
出力も少ないのは当たり前のことだけど。

--

最近のSNSの会社を任天堂と比べる向きがあるけど。

いくらなんでもムリがあるよな。

30年もの間、ハード、ソフトともに業界のトップ集団に
あり続け、信者ともいえる熱心なファンを獲得している
企業と、たかが数年の実績しかない企業を比べるほうが
土台ムリというもの。

--

もうひとつ。この業界、読書家が多いんだけど。
リクルーティングやスカウティングの話も結構出てる。

たとえば、Joelにしてもそうだし、PGにしてもそう。
あるいは、もっと古ければ人月の神話なんかも一種の
リクルーティングの話といえなくもない。

それらの本は、例外なく『人を増やすのは大変だよ』
ということを説いてる。

で、それらはどれも一定の評価を得ている本で、読書家なら
必ず目を通しているはず。

だのに、だ。なぜかSNSの会社が大量の技術者を雇うと
いう話にあまり疑問の声を聞かない。

おかしいだろ?

SNSは特別なのか? それとも、その会社に何か特別な
魔法があるのか?

急成長してるんだから人を集めるのは当然だ。そういう
つもりか? バカバカしい。
それじゃ人月商売と変わんないだろ。

--

東洋経済がカメラの特集だったんだけど。読んでて
感じたのは、メーカーのハードへこだわりと、そこから
透けて見えるソフト軽視だね。

今どき、ソフト抜きのハードなんて考えられないし、
そういう目で見れば、日本のソフトは世界に通用してる
んじゃないか。そこらへんをメーカー自身も無自覚
なんじゃないか。

--

http://spectrum.ieee.org/geek-life/hands-on/using-the-canon-hack-development-kit

この記事、いろんな意味で驚いたんだけど。IEEEが
キヤノン非公認(のはず)のCHDKを取り上げるという点。
CHDKというからには、それはソフトウェアの話で、
カメラのハードではなく、ファームウェアをハックする
ためのもので、それを取り上げるのにも驚いた。

こういうところは米国の懐の深さを感じさせる。日本で
こうした話を取り上げるメディアがあるだろうか。まぁ、
ラジオライフくらいしか思い浮かばない(笑)。

--

ラジオライフも全然買わなくなったんだけど。あれも
おしい雑誌だよね。日本版makeみたいな位置に立てる
のに。案外、買って満足、見て満足の話が多かった
気がする。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails