--/--/--(--)


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コメント(-) | トラックバック(-) | --:--:--

2009/04/01(水)


@IT エンジニアライフ様にコラムを投稿させていただいています。

「気難しいプログラマとの人間関係に必要ないくつかのポイント」

1. はじめに
2. 不具合の話しかしない嫌な奴
3. バグと不具合の違い
4. あなたの問いかけに反応が悪いとき
X. 反応の悪いプログラマのいいわけ
5. わりと嫌われる飲み会への誘い
6. 説教してはいけません
X. エラー番号
7. あなたの依頼に反論するとき
8. 奇妙な態度で仕様変更に抵抗するとき
9. 自分の価値観が揺るがされる

「優れたプログラムとは」

1. ソースコードの質 (原文
2. 優れたプログラムとは (1)
3. 優れたプログラムとは (2)
X. ポリモーフィズムについて
X. 優れたプログラムとは (3)

「未分類」

1. 被害者か加害者か
2. ユーザーインタフェースについて雑感

スポンサーサイト
コメント(0) | トラックバック(0) | 12:13:00

2010/09/14(火)


入社してから数年、ようやく私は仕事にも慣れ、毎日意欲的に作業をこなしていました。
当時の私は、どのプロジェクトでも利用可能な汎用的機能を集めた共通ライブラリの作成(開発言語はC)に携わっていました。
私の担当は、とあるメモリ領域を同サイズに等分し、それぞれを貸し出したり返却したりする機能でした。
私はその機能を「メモリブロック管理」と名付け、愛着を持って開発してきました。

「貸し出すメモリブロックがなくなった場合のエラーなんだが」

ある日、上司が私に話しかけてきました。

「君はENOBLKという独自のエラー番号を使ってるね? 『エラー番号はなるべくerrno.hに沿う』というコーディング規約があるんで、それにしたがって直した方が良くないかな。例えばそう、一時的なバッファ不足という意味でEAGAINがいいんじゃないか」

「いいえ、それは違います」

私は得意げにそう言います。

「確かに今回のプロジェクトにおいてはEAGAINでいいのかもしれません。しかしこの共通ライブラリは今後、他のプロジェクトでも使われる汎用的なものです。使い方によっては、それが一時的なエラーではない可能性も出てくると思います」

私は話を続けます。

「例えばシステムの起動時にすべてを取得し、終了時に一気に返却するという使われ方をされた場合がそうです。一度取得されたブロックは返却されることがないため、EAGAINが返ってきたからといってリトライされてしまうと、無限ループに陥るかもしれない。メモリブロックの枯渇は、それが一時的なものなのか、それとも回復不可能なものなのか、共通ライブラリのレイヤーでは判断がつかないのです」

私は上司が反論してくるのを待ちました。
自分は正しいことを言っている。
かたくなにそう信じ、上司の反論に応酬するつもりでいました。
しかし、その上司は「そうか」とだけ言って私の元を去りました。

実は上司が関数仕様書にEAGAINと記述し、それがすでに関連部署に配布済みであったことを知っていました。
正直なところ、メモリブロック管理はその機能特性上、私が例として挙げたような使われ方をされることはまずありえませんでした。
にもかかわらず、そのときの私は自分の主張を押し通したのです。
ひょっとすると、私に一言の相談もなく仕様書を作って配布してしまった上司に腹を立てていたからなのかもしれません。

その後、何も言われなかったため、私はENOBLKを返すコードを修正しませんでした。
しかしなんの問題も出ないまま、製品は出荷されていきました。

ある日、共通ライブラリのエラー番号を定義するヘッダファイルを見る機会がたまたま訪れました。
そのファイルを見て、私は驚愕しました。
なんと、ENOBLKはEAGAINと同じ値で定義されていたのです。



さて、あれから十数年の月日が経ち、私はテスター、サーバ管理、PG、SE、PM等ほぼソフトウェア開発に関わるほとんどの役割を経験してきました。
この出来事を思い出し、ふと考えることがあります。
もしあのとき私が上司の立場だったら、あのくそいまいましいプログラマにどのような対応をしただろうかと。

コメント(0) | トラックバック(0) | 12:13:23

2010/10/07(木)


番外編:エラー番号」のアンサーのようなものをこちらに書いてみました。
もし良かったら読んでみてください。
コメント(0) | トラックバック(0) | 12:18:37

2010/11/03(水)


@IT エンジニアライフ様に投稿させていただいたコラムです。

ソースコードの質

twitterでの紹介で「名コラム」とかもったいないお言葉をいただいたので、舞い上がって少し宣伝してみました。
もし良かったらコメントくださるとうれしいです。

本文中では調子にのってコードの可読性の話までしてしまいましたが、肝心の可読性そのものについての言及ができずじまいになってしまいました。ひとくちに可読性と言ってもその対象範囲は広く、この辺りにあまり問題意識を持っていない方にとっては、(なまじ可読性という単語を使ったせいで)ピンとこないトピックになってしまったかもしれないと若干後悔しています。ですが、コードの質の向上、ひいてはソフトウェアの拡張・保守性とは、コードの可読性を抜きにして語れないという持論は、私の中で確固たるものになっているのは事実ですし、そこはどうしても主張しておきたかったところでもあります。

なんてことを言いながら、実は可読性の話は語ることが非常に難しいことを自覚しています。主張はしたいけど語れない。正直なところ、どうやってテキスト化しまとめていくべきか検討がつかないのです。

なので今後は、断片的な考えをこのブログにて少しずつ展開していこうかなと思っています。同じくコラムを投稿なさっている方がtwitterで実践されていた手法で、この手法だとfollowerから絶えずフィードバックを得ながら自分の考えを推し進め、アウトプットを仕上げることができるんですね。こんな使い方があるのかと関心してしまいました。

まぁ、私の場合はtwitterのアカウントも持っていませんし、このブログの参照数もスズメの涙ですのでフィードバックは期待できませんが;;
コメント(0) | トラックバック(0) | 12:58:56

2010/12/07(火)


私のくだらない雑談でコメント欄を汚しては申し訳ないので、こちらに書こうと思います。

一口にソフトウェア開発と言っても、その領域は驚くほど広いです。「私はプログラマです」という人同士の会話で、相手の言ってることがちんぷんかんぷんだった、というのはよくあることです。

このコラムのコメント欄を見て、私もAhfさんと同じ感情を抱きました。人それぞれ色々な環境に身をおき、色々な経験をし、そしてそれを通じて色々な意見・主張を持っているのだなぁ、ということです。
例えば、ここでコメントなさっているかるたやさんは、

>ソースコードの可読性が良いからといって、保守性に優れているとは思えません。

と言っています。ソフトウェア開発者の多くがあまり新鮮味のない保守業務(というと御幣があるかな?)に従事しているなかで、主にプロトタイプ開発をなさっているという、なんともうらやましい環境にいる方で、コラムの内容も大変面白くいつも拝見させていただいています。この方のように常に新規開発をしている現場では、度重なる仕様変更や長期化した保守工程によってボロボロになったソースコードを見る機会は恐らくあまりないのでしょう。あくまで一例ですが、私のコラムにある坂本さんのコメントでは、引継ぎ業務においてその深刻さを物語っています。
また同じくコメントなさっているインドリさんは、周りのプログラミングスキルの低さに相当苦労なさっているようです。

このような環境の違いははなっから想定されるべきことですが、保守性や可読性といった基礎工学的な話をする場合は、論点以外の要因を注意深く取り払わないと議論が発散しかねないんですね。インドリさんの主張は単に周りのスキルレベルの低さが問題なだけなように思いますし、Ahfさんの現場では、そもそも上流工程に保守性の観点が盛り込まれていないことが問題なように思います。

ソフトウェア工学が対象とするものは、主に中~大規模のプログラムにおける技術論であったり方法論であったりすると思っています。なぜなら小規模なものはどう作っても意外となんとかなるからで、あまり本質的な問題は出てこないんですね。たいていの場合、設計工程がごっそり抜け、保守工程がプログラマの力ずくで成り立っているので、下流工程は相当優秀な人でないと勤まりませんけどね。

色々言いましたが要するに工学の話をする場合は、プロジェクトが良好な業務で遂行されている前提に立ち、それでもなお問題が起こる場合を議論しなければならないと思うのです。そしてそこで生まれた工学的な思想は、大部分が小規模プログラムにも適用できるものになるでしょう。

ちなみに私はソフトウェア工学なるものをまともに勉強したことがありません。あくまで実際の現場で得た経験や、それに付随する学習をもとにしたものであり、ここでの主張は決して机上の空論になっているとは思いません。
コメント(0) | トラックバック(0) | 00:40:35

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。