補足
書きながら、今のこの話題って暗黙にドメインが限定されてて、ここで言ってる負債は誰がどんな文脈でみても駄目な想像を絶する酷いコードのことじゃないかっていう気がしてきましたが、そうすると話が続かないのである程度設計判断が絡むレベルってことにして書きました
「UMLモデリングの本質」について、批判的な文脈で引用してますが、この本そのものを批判するつもりは一切ありません。ちょっと定義を引きたかっただけです。あと、本来の文脈だと美しいモデルは変更に強くなる、つまり変更への強さは結果なんですが、とりあえず話を進めるために流しました(^^; ちなみにこの本は設計の善し悪しを語りたくなった人は絶対読むべきです。なお、業務システム開発を前提とした本ですが、組込み方面の人々も参考になるはずです。
技術的負債に関する僕の理解は以下の記事（およびそこからたどれる2つの記事）をベースにしています。していますが、本当に参考にしているならもっと良いこと書けた気がしてなりません。。
M. ファウラーのリファクタリング本には、「いつリファクタリングすべきか」についても言及しています。ここでは触れませんが是非読んでおきましょう
It dependsとしか言えないのは僕の知識や経験がアレなだけです多分
技術的負債に対処するヒントを書こうとした筈だったのに精神的に老いたプログラマによる鬱陶しい苦言になってしまった文章
技術的負債なんて結構前からある単語なのに急にTwitterあたりで流れ初めて面白いなーと思う。まぁこれに関して何を今更とか原典出さないのとか野暮なことは言わない。コードは動けば良いものじゃないという意識が広まるのはよいことだ。
しかし、可能ならば、乗っかって愚痴ったり逆に単に反省したりするだけでなく、議論をもう一歩進めてほしい。
まずは、負債とならない「きれいな」コードは常に正義なのかと言うこと。きれいなコードを書くには少なからず余分な工数がかかるし、誰もが出来ることではない。熟練者であってもうまく書けないこともあるだろう。書き捨てのモックアップに見えない部分まで手間をかけることに価値はあるだろうか。納期直前の切羽詰まった状況でベタ書きしててもちょっと責めづらい。この辺りを加味せず「常にきれいなコードを書こう」というのは、ちょっと非現実的ではないか。エンジニアたるもの、常に現実を見据えていたいものである。
ついでに、美しく粗結合を実現したコードは往々にして理解が難しく本人以外に修正困難になる、という点にも注意が必要である。 Cプログラマからコンバートされたての人々を集めた現場にOO言語の機構を存分に生かしたコードを渡したとして、それか想定通り拡張されることは期待できるだろうか。将来の変更に備えるためのコーディングをするなら、その将来の変更は誰が行うのか？ということも考えておかなければならない。
そもそも、負債の少ないコード、きれいなコードってなんだろうか。ある定義に*1よると変更に強いコードなのだが、極端な話、変更に強いかどうかなんて変更が来てみなければ分からない。ではなぜそんなコードがかけるかというと、バグ修正を含め、発生しそうな変更を予想しているからに他ならない。多くの現場を経験している熟練エンジニアでない限り、概ねそんな芸当は不可能である。デザインパターンも万能ではなく、どのパターンをどのように使うかは人間の判断である。それが容易に出来ているとすれば、それは単なる思い上がりであるか、ソフトウェアの形をしたソフトウェアでないものを作らされている場合である。
「きれいなコードを書こうよ！」って言うのは簡単だが、いざ実践しようと思うとさまざまな障害がたちはだかる。無理に押し通そうと思うと独り善がりだと糾弾され逆効果になるおそれもある。正直一般解は無い。無いんだが、まぁ一応、他人事っぽく僕が思うのは、無理に最初からきれいに書こうとせず、コードが汚くて困ると思ったら、そのタイミングで直せば良いじゃないか、と言うことである。言い換えると、汚いコードが存在することそのものは許容する代わりに、汚いコードに遭遇したらどうするかと言うことを常に考えておく。世の中キャッシュフロー経営というものが有るように、負債を前提に適切に管理してけば良いのである。プロトタイピングでは多少荒くてもガンガン書き進めて動くことを目指し方向が定まってからまた書き直せば良いし、固まっている部分は丁寧に進めれば良い。コアとなる部分は少数精鋭で徹底して作り込む一方で、誰が触るか分からない多くの部分は理解性重視でコードそのものは手加減し文書でカバーするのも有効である。
でもこれを単純にやると、またスキルの高い人がダメなコードを直し続ける羽目になってしまうので、みんなでコードレビューしてリファクタリングするフェイズを用意するといった手立てが必要になると思う。この辺りはソフトウェアプロセスとの絡みもあり難しいところだが、この問題を個人のスキルや意識/意志の問題に閉じさせるんじゃなくて、チームの戦略の問題にすることは必要になってくると思う。みんなでコードの良し悪しに関する嗅覚を鍛えて感性を共有してかないといけない。
という感じで竜頭蛇尾甚だしく「常に現実を」と言いながら全然現実味のあることが書けず単なる鬱陶しい茶々入れになってしまったが、まぁ、これ以上は"It depends."としか言えない気がするのでこの辺で。
SES2011便乗 関東＿＿＿＿け〜ん飲み会
SESで東京に人が集まるのにあわせ，9/12に＿＿＿＿け〜ん飲み会を開催します．いまのところ，吉祥寺近辺を予定しています．
参加してもええよ！という方は下記URLにてご表明ください．
http://sel.ist.osaka-u.ac.jp/~m-itii/local/nomi/
（※いつもの認証がかかっています）
このエントリのコメント欄や，その他，任意の私への連絡方法でもOKです．なお，参加表明などは9/5くらいまでに頂けると，人数を把握しやすくなって幹事が喜びます．そんなところでよろしくお願いします．
ハワイに行った気分になれはしなかったけれど
ICSE2011勉強会に東京拠点で参加しました．色々わがまま聞いてもらった林先生に多謝．
その割に発表ぐだぐだですみませんでした…．つぎはもちょいマシなモノにするので，懲りずにまた呼んでください．
あと，阪大方面の皆様，挨拶も無しで失礼しました．
関係ありませんが，twitterが盛り上がってて楽しそうだったので，いい加減アカウントが必要だと思いました．ちゃんと参加したのになんだかおいてけぼり気分．
それはともかく，参加された皆様お疲れ様でした．とても有意義な1日でした．
「ここの仕様って何故こうなってるんですか？」「現行バージョンががそうなっているからです」
Cは既に時代遅れ? | スラド デベロッパー
卜部昌平のあまりreblogしないtumblr - どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。
うっかりマジレスしてる人々は、 s/C/C++/g とか s/C/VB/g とか何ならs/C/Java/g とかやっても、あんまり違和感が無い時点でまじめに議論することに意味が無いことに早く気づくべきだ。
# タイトルと本文は多分関係ありません
ports/devel/bazaar と ports/devel/bazaar-ng
現行のBazaar (bzr) が欲しいなら、ports/deve/bazaar-ng が正解。ports/devel/bazaarは、旧Bazaar (baz)。
どちらもCanonical Ltd.製という点では一緒だが、旧Bazaar (baz) がGNU archのクライアントとして開発されていたものであるのに対し、現行Bazaar (bzr) は、新しい分散VCSとして、"Bazaar-NG"という名前で開発されてきたものであり、仕様・実装ともに完全に別物*1。もはや旧Bazaarの開発は止まり、Bazaar-NGがBazaarを名乗っているが、Ports名を安易に変えるとハマるので、開発スタート時の名前がそのまま維持されているんだと思う*2。とはいえ、そのうちbazaarが削除されてbazaar-ngがbazaarになるんだろう。多分。
*1:http://ja.wikipedia.org/wiki/Bazaar
*2:いや、他から依存されるパッケージでも無いし、普通の手順でアップデートする限りあんまりハマらない気もする。-ngじゃないbazaarの名付け方で困るから保留してるだけだったりして。
FreeBSD 8.2 on VirtualBox
PC-UNIX環境*1を用いて試したいことがいくつか出てきたのに、Windows環境をVistaから7にアップグレードしたタイミングでVirtualPCで構築してたFreeBSDが使えなくなってしまった。仮想HDDのファイルがファイルとして認識されなくなってしまった。意味が分からない。でもそれはそれで新しくインストールすれば良いだけかと思いVirtualPCで新しく作ってみたら、インストール作業は無事終わるのに起動しようとするとBTXの段階でこける。意味が分からない。んで原因を調べようかとも思ったけどVirtualPCを使ってる理由は「楽そうだから」であり起動でハマるようではVirtualPCである意味があんまり無い。というか元々ゲストOSとしてWindows以外考えてなさそうなVirtualPCだからがんばっても不可能だったり起動できてもその後またハマる可能性も存在する。VirtualPC以外の選択肢としては複数存在するがVMWareは商用利用不可なのでせっかくココで使い方を覚えても会社でつかなくて微妙。かといって企業サポートの無いOSS系は完成度が不安。ということで、例によって前置きが異様に長くなったが、いつの間にかOSSになっていたVirtualBoxを使ってみることにした。
VirtualBoxとはOracleの仮想マシン環境であり*2、XP Mode専用といって差し支えないVirtual PCと異なり、Linuxや*BSDを公式にサポートする上、仮想H/Wを色々と細かく設定出来る。その一方、基本的な部分はOSSであり*3、VMWareと違って商用利用もOK。
VirtualBoxのインストールはインストーラを落としてきて実行するだけ。ゲストPCのインストールも、ウィザードに従っていくだけで、割と簡単。
実際に、Windows 7 Professional (64bit) にVirtual Box4.0.6をインストールし、ゲストとしてFreeBSD 8.2Rをインストールしてみた。カーネル再構築とかportsのビルドとか、FreeBSDの基本的な使い方の範囲内では、特に問題は無く動いている。常用OKな感じ。
ただ、ネットワーク構成でちょっと悩んだ。
VirtualBoxでは、仮想NICの接続方法として、「NAT」「ホストオンリー アダプタ」「ブリッジ アダプタ」「内部ネットワーク」の4通りの選択肢がある。それぞれ、次のような振る舞いとなる。
- NAT
- ゲストPCから、ホストPCを経由し、外部ネットワークにアクセス出来る。流行りの言葉で言い換えるとテザリング的な感じ。一方で、ゲストPCのアドレス空間がホストPCからも見えないので、ホストPCからゲストPCへ到達出来ない*4。
- ホストオンリーアダプタ
- ホストPC上に作られた仮想NICを通じて、ホストPCとゲストPCの間で通信できる。一方で、この場合のホストPCはNATしてくれないので、ゲストPCから、外のネットワークへのアクセスはできない*5。
- ブリッジアダプタ
- 名前の通りブリッジ接続を使い、ゲストPCをホストPCと同じ空間に投げ出す。ゲストPC−外部もホストPC−ゲストPCもOKだが、外部の環境に強く依存するので、自宅LAN環境以外ではゲストPCを使えなくなる*6。
- 内部ネットワーク
- よく分からん
ホストPC単独で、ホストPC-ゲストPCの通信を実現しつつ、ゲストPCから外部ネットワークへの通信もやりたいのだが、どうも要求をちゃんと満たせる選択肢が無いらしい。ということで、安直にNICを2枚生成し、それぞれNATおよびホストオンリーアダプタとした。どちらもDHCPでアドレスを振ってくれるが、ホストオンリーアダプタの方はIPがころころ変わると面倒なので固定で振った。デフォルトでは192.168.56.100から192.168.56.255まではDHCPの割り当て範囲なので、そこは外して99で。rc.confはこんな感じ。
ifconfig_em0="DHCP" ifconfig_em1="inet 192.168.56.99 netmask 255.255.255.0"
em0がNAT側、em1がホストオンリーアダプタ側。ホストPCからはem1にアクセスする。なお、仮想NICの作成など、ホストPC側の設定はVirtual Boxインストール時に勝手にやってくれるので、改めて行うことは無い*7。
また、仮想HDDをUSB HDD上に作成したのだが、遅いので、セットアップ中だけでもローカルディスクに置いとこうと思って移動してみたら、「同じUUIDのHDDが既に存在する」という意味のメッセージ*8が出て、マウント出来なくなった。ちゃんとアンマウントした後なので多重マウントということでは無いはず。ちゃんとパスまで覚えているということかもしれない。…が、そうするとUSB HDDのドライブレターが変わったらハマる気がする。とりあえず、そのときはそのときということで、一旦忘れることにする。
