本日、レガシーコードに逢いました
ボクのような平凡な人間には一生お目にかかることはないと思っていた人に出会ったんだ。それもとびっきりのね。
ことの発端は、2年前にとある会社に外注したコードを機能拡張して欲しい、と言う依頼。久々のSKILL*1の仕事だと思ったら、出るわ出るわ、嫌な臭いが。。。
何がひどかったか
まず、コードが読みにくい。なぜ読みにくいか。
全てグローバル変数で定義
これが全てのガン。そもそもSKILLと言っても、Lisp何だから、letかprogでローカルな環境を作ってやればよいのに、なぜか全てグローバル変数を使っている。それも必要なグローバル変数だったら、まだいい。ほとんどがただの一時変数に過ぎないのに、なぜ、そんなライフタイムの長い変数を用意する!!
そして、グローバル変数にしているものだから、変数名の先頭にプレフィックスをつけてしまって、余計にコードが醜い。
仕方が無いので、リファクタしているのだが、コメント等が何も無いので、必要なグローバル変数かどうかをコードを追って、テストしないとわからない。
長すぎる関数
関数内には、一つの働きしか書かない、と言うのは、常識ではないのか？ 違うのか？
そもそもSKILLと言っても、LISPの分布をCライクにしただけ。カッコの多さは変わらない。とすると、可読性に優れるのは、流れていくような構造をもったプログラムだと思うのだけど、幾つかの処理を関数内に入れ込んでいるので、そのような美しさは皆無。
意味不明な変数名
上のグローバル変数とも絡むけど、最初にプレフィックスがあるので、変数名が不要に長い。その割に、肝心な情報がなく、識別が全くつかない。
No Comment
僕自身は、コメントはなくてもいいと思っている。むしろ、誤ったコメントを書かれるぐらいならいらない。そのかわり、雄弁と語るようなコードじゃないとダメだ。変数名が意味不明では、語るどころか、こちらの意識まで吸い込まれてしまう。
文法的な問題
これは、SKILLの問題。いや、エディタがちゃんとサポートしていればいいのだが、その担当者はノートパッドで書いたのではないか、と思わせるぐらい、インデントが無茶苦茶だった。
以上、ただの愚痴ですが
ということで、久しぶりに放り投げたいプログラムに出逢いました。これが、社内のプログラマが書いたのであれば、担当者を注意するだけで良い。問題は、社外に発注して、納品としてこんなヒドイコードを受け取っている、と言う事実だ。確かに受け入れ検査が甘かったのだろう。おそらくは、ブラックボックスとして機能だけを見て、受入検査をやっているのだろう。
このコードを見て、ボクは新人が担当したのだと思った。しかし、当時の事情を知る人に聞いたところ、このプログラムを担当していたのは、それなりに(少なくともボクよりはよっぽど)SKILLでプログラミングをした経験があるらしい。
待て待て待て待て。そんな経験のある人間がこんなにヒドイコードを書くの？ バカにしてるの？
今までのコードもそうなの？
その会社は、何もレビューしていないの？
こんなやっつけのようなコードを書くような仕事のやり方をしているの？
コードって面白いもので、その人の思想なりが見えてくる。このようにメンテナンスを一切考えない、バグが起きやすいコードを作る、抽象化を一切考えない、と言うのは、エンジニアとして失格でしょう。ボクもソフトウェアのマトモな講義なんて受けたことがない。しかし、それ以外の工学的な講義や、今までの経験などから、例えソフトウェアプラクティスを知らなくても、どのようにしたらバグが発生しにくいか、ぐらい想像がつくだろう。
この人には、プログラムだけでなく、そもそもモノを作る技量があるとは到底思えない。
確かに、うちも受け入れが甘かった。しかし、このような汚物に近いコードを平気で納品してくるような会社とは、ボクの目が黒いうちは、2度と取引をすることはないだろう。品質を一切考えないような会社とは。
さようなら。
3歳7ヶ月になりました。
土曜日に幼稚園の土曜参観、日曜日にアンパンマンミュージアムに行ったりと、久しぶりに娘と共有する時間が多かったので、備忘録がわりに。
幼稚園
娘が幼稚園に通い始めてから、早2ヶ月。当初は「行きたくない」と言うかと心配してたけど、今のところ積極的ではないけど、嫌がる素振りを見せずに行っている。そして、土曜日に普段どういう事をしているのか観てきた。
よかったところ
- 返事がいい。親ばかもあるけど、クラスの中で一番良い返事をしているような気がする。
- 遠慮深い。これは良くない面でもあるかもしれない。
- 楽しそう。
よくなかったところ
- スタンドプレーが目立つ。まだ、人と協調して、と言うのはないのかもしれないけど、とにかく一人で行動する。
- 前のめりにならない。どちらかと言うと、引いている方。お座りのときとかでも、一人で一番後ろにポツンと座ったりする。
何となく心配しすぎなだけかもしれないけど、積極性が足りないのが、親としてはちょっと心配。
アンパンマンミュージアム
だいたい楽しんでいたと思う。でも、食パンマンが広場に来て、みんなと写真を撮っているときに、うちの娘も寄っていったのだけど、どうしてももう一歩が出ずに、食パンマンの前でもじもじしている。その間に、他の子が続々と割って行くので、どんどん順番を抜かされてしまう。
どうも、大勢の子どもが殺到したときに、どういう行動をとればいいのかがわからないらしい。これは一人目の特質なのだろうか？ 二人目だと、上を見て育つので、どのように行動すべきかは、すぐ出てくる。と言うよりも、シチュエーションと取るべき行動が脳内で直結しているのかな。これが、大人だとシチュエーションというインプットに対して、複数の選択肢(主に経験から)から最良と思えるものを導きだして、出力できる。うちの娘には当然経験もなければ、上の参考になる人もいないので、まだどのように行動すべきか、と言う脳内回路が出来ていないのかな。
それ以上に少し心配なのは、自信がないのかなぁ、と思える。メガネをしてたら1.0ぐらい視力はあるらしいので、十分だと思うのだけど、どうも反応が鈍いところがある。そして、そういうところに気後れしている？
う〜ん、心配しすぎか。
いずれにせよ、親としては見守っていくしかないかな。そして、自分に自信がつけられるようにサポートするだけかな。
開発環境改善タスクフォース
http://d.hatena.ne.jp/yukichanko/20110524/1306248332
先週、ボクが体調崩して延期になったので、今週やりました。
内容は、ボクが東京勤務時代に使っていた環境をツラツラと紹介、と言う感じ。話が盛り上がったのは、
と言ったあたりかなぁ。
これだけの内容だったハズなのに、気がつくと2.5時間も経っていた。恐るべし。
これからは、タイトルのように名前を変えて、自己啓発ベースで週1、もしくは隔週でやっていくことになりました。
次は、別の人が某新横勤務のときに効率改善のために構築していた機能だったり、開発3種の神器(VCS, BTS, CI)をどのように使っていくか、と言う議論をしたい。この辺、社内ですでに展開してる人の意見を聞きたいなぁ、と思ったり|дﾟ)ﾁﾗｯ
個人的には開発環境に留まらずに、共通的な技術一般についても話し合ったらいいんじゃないかと思う。
例えば、GPGPUプログラミングであったり、GUIプログラミングであったり、関数型プログラミングであったり。
そういえば、何で統合開発環境を使っていないのか、と言う質問を受けた。確かに、C++で開発してて、デバッグの時には使いたいなぁ、と思ったけど、それっきりだなぁ。自社に戻ってきて、Pythonで主に作るようになってからは、print文デバッグしかしてないし(ヾ(・∀・；)ｵｲｵｲ)。
SKILL++とは
ボクの嫌いな言語No.2にランキングしているSKILL。理由は、せっかくのきれいなLispなのに、C言語風のコードが書けたり、CamelCaseを推奨しているところ。もちろん、それ以外に仕事的な理由もありますが、それはまたの機会に。
しかしながら、Cadenceもその辺はある程度理解しているのか、SKILL++と言うのも用意している。しかし、SKILL嫌いのせいで調べることもほとんどしなかったけど、とある人から指摘されてしまったので、少し調べて見ることにする。
と言っても、CadenceのBlog
http://www.cadence.com/Community/blogs/cic/archive/2011/01/04/skill-for-the-skilled-what-is-skill.aspx
を見てるだけだけど。
そういえば、SKILLをスタンドアローンで動かすことってできないの？ > Cadenceさん
特徴
Lisp-1と言うのはあまり知らなかったけど、Matzさんのブログに詳しく書かれているので割愛w
基本的に名前空間が一つしかないLispのことをLisp-1と呼ぶ。たとえばSchemeがそう。
http://www.rubyist.net/~matz/20080201.html#p01
とりあえず、変数と関数が同じ名前空間に属している、と言うことですね。Pythonもそうらしいですね。そういえば、関数を普通に変数に代入できたりします。Rubyは単一名前空間じゃないから、ブロックで囲んでやって、変数に渡さないといけない。
さて、この3つの特徴を見ていると。。。これってScheme？と思ってしまいますね。実際、CadenceのBlogでも
In this article, we'll ignore the SKILL++ object system and concentrate on the first two of these capabilities -- sometimes referred to jointly as the SKILL++ Scheme Dialect.
http://www.cadence.com/Community/blogs/cic/archive/2011/01/04/skill-for-the-skilled-what-is-skill.aspx
例題
CadenceのBlogでは、以下のコードがサンプルで載っている
(defun walkCvHier (cv consume) (foreach inst cv~>instances (walkCvHier inst~>master consume)) (consume cv))
あいかわらずCamelCaseなのが若干気にくわないが、これはなにかデザイン上のオブジェクトがあったときに、そのインスタンスを探していって、プリミティブに当たったときに、 (consume cv)を実行する、というもの。
SICPをやっていれば、すぐに分かるけど、いわゆる高階関数の例。以前は、Lispと同じ風に書かないといけなかったのが、Scheme風に書けるよ、ということか。いまいち、説得力がないぞw
ということで、
今回は終わり。Cadenceのブログも続きがあるらしいので、その都度どんなもんか見ていきます。
でも、僕自身、CLOSのオブジェクトの使い方がいまいち分かっていないので、仕事でSKILL++を使うべきか悩んでいます。この辺は、プログラミングGaucheを読んで勉強すべきかな。
開発環境勉強会はじめま〜す
と言っても、社内で、ですけどね。
来週、開発勉強会の話を先輩にしてみよう。もし、感触がよければ、二人でもやる!!
と、ヘベレケ(多分、ワインをかなり飲んでた)な状態で書いたら、先輩に反応してもらえたので。
ということで、まずは、自分の環境を整理。
My 開発環境
ないと仕事に支障がでるもの
あればよいと思うもの
- python
- Sphinx: そういえば、最近使っていない。以前は、ドキュメントを大量生成する必要があったけど、今はないので。
- Wiki: 今はPukiWikiをグループで使っている。と言っても、放置状態。もっと使いやすいWikiはないか？
- BTS: 昨年度までは、Redmineを使ってましたが、Ticket Drivenなやり方はしてません。
- emacs
- org-mode: 議事録書くのに最高。
- gnuplot: 簡単なグラフは、gnuplot, 複雑、もしくはプレゼン資料を作るときはmatplotlib
- GUIプログラミング: PySide(Python + Qt4)を導入したい。
- GNU Global: Emacsを使っていたときは、必須だったけど、Vimに変えてからあまり使っていない。
- git
- git-flow: 使っていないけど、今後導入したい。
- tig: GitXがないので、使いこなしたい。
今度導入していきたいもの
- TDD: ツールではなく開発思想ですが。
- Jenkins: 継続的インテグレーション。。。憧れてます。
- OMake: 依存関係をよしなに解決してくれると聞いて。
- github: Gitoriousというものを社内に導入してみたい。
- 社内SNS: twitterを展開して、もっと気楽な情報共有を。
Windows環境
- VirtualWin
- Vimperator: Windowsだけではないけど。
- fenrir: Windows版Spotlight
余部鉄橋をめぐる旅
ボクが関西を離れたのが2007年3月。その時には、まだ、朱に染まったトレッスル橋があった。時代は変わるもので、たかだか4年しか変わらないのに、余部鉄橋がつけ代わってしまったので*1、すごく久しぶりに、鉄分補給をかねて行ってみた。
スタート
旅行の日は、5/5~6の1泊2日で鳥取をめぐって帰ってくる。さて、5/4といえば、きしくも新生大阪駅が公開された日でもある。早速、「何これー？」となってしまった。
出迎えてくれたのは、丹波路快速。私がいた頃は、221系しかなかったものだが、これも時代の影響か、223系がJR宝塚線まで侵食するしていた。これも噂には聞いていたのだけど、実際に体験してみると、宝塚線もメジャーな路線になったものだと思ってしまう。もう、117系もこの路線では見ることができないんでしょうね。
そして、一番驚いたのが、223系が篠山口以降、さらに福知山~城崎温泉間でも運行されていたことである。この区間は、113・115系の中間車を無理やり先頭車に改造した食パン車が走っているものだと思っていたのに、蓋を開ければ、ローカル線にはにつかない223系。まさか、城崎までずっと223系の恩恵をあずかれるとは、思っていなかった。
キハ47系と223系
余部鉄橋着
城崎からは、キハ47系ディーゼル車両。やはり、このエンジン音が旅の気分を盛り上げてくれる。車両は、円山川から離れて日本海の険しい地形をトンネルを使用してかけていきます。
そして、列車は鎧駅に到着。この駅も風情があって良い。最後のトンネルを抜けると、まるで列車が余部の集落を飛んでいるんじゃないか、と思うぐらい、視界が一気に広がります。
しかし、何とも物悲しい。あの雄大なトレッスル橋が、わずか4本のコンクリート橋になってしまうとは。今まで知らなかったのですが、明治の時代、余部はまさしく陸の孤島。この余部鉄橋は、海からの水運に全てをかけて建設されたそうです。そして、材料は全てアメリカからの輸入品。もし、日本海の大しけが悪さをしていたら、山陰本線の開業も大幅に遅れていたんでしょうね。また、太平洋戦争で大きな打撃を受けなかったのは、不幸中の幸いというものです。
途中で切れているのが物悲しさを語っています。
次の浜坂行きの電車まで1時間近くあったので、付近を散策。展望台には登れない、と聞いていたのですが、途中まではいけるらしく、行ってみました。しかし、新しい橋梁しか見えないのが少し不満。
そして、少し余部鉄橋からは離れている虹と谷のギャラリーへ。ここでは、無料で余部鉄橋の映像や写真などを見ることができます。オナーの粋な計らいに感謝。
久々に訪れて
余部鉄橋がなくなったというのは、兵庫県に生まれ育った人間としては、やはり一抹の寂しさを覚えます。JR西には、何とか余部鉄橋の痕跡を残してもらいたい。そして、偉大なるローカル線、山陰本線をいつまでも維持して欲しいなぁ、とも思います。
*1:もちろん、計画はあったのだけど
Bareリポジトリのmasterブランチを削除する
はいっ。こんなことをするシチュエーションはほとんど考えられないですが、つい今日、そういうシチュエーションがあって、どのように対応すべきかよくわからなかったので、メモがてら書いておきます。
シチュエーション
私の開発環境は、メインはMacBook Proなのですが、数値計算のプログラムを走らせるためには、MBPではキツクて、やはり大容量のメモリマシンに持っていく必要があります。
その時に、同期をするのに、サーバーマシン上にgitのBareリポジトリを置いています。
ちなみに、マスターのリポジトリはsvnでそこにみんなcommitしております。
そんなとき(特にマスターのsvnリポジトリから、git svn rebaseで最新のコミットを取り込んだ時)、git pushで上流に上げても、Fast Forwardではないため、mergeが必要になってしまいます。
ところが、そんなのめんどくさい。ということで、上流のリポジトリのmasterブランチを削除して、git pushでmasterを上げたいと言うのが動機です。
やり方
とりあえず、gitのBareリポジトリに移動
% cd
% git branch
* master
と言う具合になっているところで、おもむろにmasterブランチを消そうとすると、
% git branch -d master
error: Cannot delete the branch 'master' which you are currently on.
と、「今そのブランチにおるくせに消せるかー」と怒られます。
仕方が無いので、新たにブランチを作って、checkoutしようとすると、
% git branch master.yymmdd
% git checkout master.yymmdd
fatal: This operation must be run in a work tree
とこれまた、「Work Treeじゃないのに、checkoutできひんわ」と怒られます。
しかし、gitのbranchは所詮はポインタであることから、HEADのリファレンス先を直接変えることができます。
% git symbolic-ref HEAD refs/heads/master.yymmdd
% git branch
* master.yymmdd
master
そして、あとはmasterブランチを削除。
% git branch -d master
% git branch
* master.yymmdd
と言う感じ。あとは、下流からmasterブランチにpushすれば、またmasterブランチができあがる、と言うわけです。
