キャリア20年超。ずっとプログラマで生き延びている女のコラム。

消えゆくコードに送る言葉を

»

 昔、読んだ記事によると、プログラマは「バグ」よりも「仕様変更」に強いストレスを感じるそうです。

 バグは自分が悪いとあきらめもつきますけど、仕様変更ってのは天災みたいなもんで(←人災以外のなにものでもないけど)、いきなり襲ってきてせっかく作りあげたコードを潰してしまいますから、バグよりストレスだと感じる人が多いのは当然かと思います。

 仕様変更の何が大変って、頭の中で「うん、これはきれいにまとまった」と思っていたものを崩して、ロジックを作り直さなきゃいけないってことなんですよ。

 脳内できれいにルートがさだまっていたものを、方向転換するのは意外と大変です。

 プログラムを組み立てるまでに費やした時間と、同じだけの時間をかけて修正できるのなら話は別ですが、たいていの場合「すぐに直して」って言われますからね。

 あせって修正をした結果、古いルートと新しいルートが妙に交わって、バグの荒野に飛び出すこともしばしばです。

 仕様変更でつぎはぎした感が濃厚なコードをたまに読みますけど、ものすごくせつない気持ちになります。

 プログラマが苦労していることはよっくわかりますけど、もうちょっとていねいに直してあげて欲しいなあ、と思っちゃうんです。

 わたしはどうしても、一枚板から打ち出しました、って感じにしたくって、修正しなくてもなんとかなる部分まで手をいれたりすることがあります。

 それって意味のないこだわりにみえるかもしれませんが、わたしの経験からいえば意外と意味はあります。

 コードに妙な「継ぎ目」があったりすると、その後でさらなる修正を加えた際に「亀裂」になることがあるんですよ。

 ですので、仕様の変更や追加をする時は、できるかぎりコードをフラットな状態にすることに、わたしはこだわります。

 まあ、自己満足だといわれちゃえばそれまでなんですけどね。

 なら、仕様の削除はばっさり切り落とすだけだからそんなに大変じゃないだろう、というとそうでもなくて、意外に精神的なダメージが大きかったりします。

 「我ながらこのロジックはよく思いついたぞ」ってこっそり悦に入ってた部分が不要になっちゃって消さなきゃいけない時とか、ホンキでヘコみますよ。

 コードをテキストファイルとして残しておくことはできますけど、結局、誰にもつかってもらえないのでは「死んだコード」ですから、なんか亡骸を後生大事に抱えてるみたいで余計にさびしい、と思った時にいきなり思いついたわけです。

 コードのお葬式をやってみたらどうだろう!(←我ながらイタすぎる発想)

 「汝が0と1の海に還ろうとも、その魂は我がニューロンの内で生き続け、いつか、新たなるコードの礎となるであろう」(←もっと荘厳な弔辞絶賛募集中)とか言いながら、DELETEキーをポチッと押すのはどうだろう。

 それはいい。なんだか気持ちの切り替えが早くなりそうな気がする。

 ……とかいう妄想で、ヘコんだ気持ちを盛り上げようとしている自分がいる……(泣)。

 なんかもう、自分でもバカっぽいって思いますけど、ちゃんと動いてるコードを捨てるのってホントにストレスになるんですよ。

 わたしが過剰反応なんですかねえ。はあ。

Comment(13)

コメント

虚人

うんうん。分かります、その気持ち。

お葬式まではしたことありませんが(^^;)
自分のコードを削る時は、”退場~”って言って、Deleteキーを押してましたっけね。
まあ、退場するのは現バージョンからであり、構成管理システムには、ちゃんと過去の履歴として残っているので、「お前の足跡は残っている、ゆっくり休養してくれ」って感じでしょうか。

インドリ

>←もっと荘厳な弔辞絶賛募集中

/*
おお、愛しの我が子よ。
無残にも人の気まぐれにより消えゆくその命を私は忘れはしない。
我が血肉となりて永遠に生き続けん。
その勇姿は我が心に永遠に生き続けん。
我は汝を殺す。
その罪を背負いプロジェクトを完成させる事を我は天に誓う。
そして、多くの尊き命でプロジェクトが成り立っている事を気まぐれな人々に説く事を我は誓う。

データベースの担い手○○ロジックここに眠る。
*/

※ウケ狙いです。

ひでみ

こんばんわです。ひでみです。


虚人さん。

> うんうん。分かります、その気持ち。

わかっていただけますか~(感涙)。
そう言っていただけただけでこのコラムを書いたかいがありました。

> 「お前の足跡は残っている、ゆっくり休養してくれ」って感じでしょうか。

「消す」とか考えるからヘコむんですね。今度からは「お休みいただく」と考えるようにしてみます。
少しは前向きになれそうな気がします。


インドリさん。いつもありがとうございます。

> 無残にも人の気まぐれにより消えゆくその命を私は忘れはしない。

この一文がステキです。
そうなんですよ。結局のところヘコむ最大要因はそこにあるんですよ。
仕様変更はエンジニアのストレスとバグを生むってことを、ユーザーさんにも理解していただきたいものです。

あずき

おはようございます。
社会人2年目のあずきと申します。
2年目なのでそれほど多くのコードは書いていませんが(4月以降まともな仕事がないというのもありますが)、非常に共感いたしました。

昨年末、インフラに密接に関わる仕事に携わったのですが、「こういうツールが必要だから作って」と言われ、翌日の午後に「できましたー!」と持っていくと・・・

「あぁ、あれ。昨日の夜のミーティングでいらないってことになったんですよ。」と、痛恨の一撃が。

たとえ小さくても大切な作品だったので、非常につらかったです。(しかも似たような状況でボツになった作品はあと3つほど。


でも、お葬式はしませんでした。
自宅用に仕様を書き直して自宅で作って使うという荒業に出て気を紛らわせたりしたものです。(フリーで探せばいくらでも似たようなツールがありそうというのは置いといて。

HZ

>コードに妙な「継ぎ目」があったりすると、その後でさらなる修正を加えた際に「亀裂」になる
>仕様の変更や追加をする時は、できるかぎりコードをフラットな状態にする
これ良く分かります。
逆にこう出来ないと心残りが…。

以前、vb6のコードをvb.netに置き換える仕事をしていたのですが、
「その画面は仕様が当時と変更になるからこの仕様で作って」
と仕様書を渡され、vb6のコードは参考にせず、1からプログラムを作成する事に。
2週間後、(我ながら綺麗にまとまったコードが書けた。)と思いつつ報告に行ったら、
「その画面な、今また仕様変更依頼が来ててな、簡単そうやから了解メール送っといたよ。ちょっと変わるだけやから1日あれば出来るやろ?」と。
その変更は確かにちょっと変わるだけだったのですが、根幹の部分がちょっと変わるという物だったので、綺麗にまとまったコードは解体され、継ぎはぎだらけのコードを納品する事になってしまいました。
納期数日前の仕様変更依頼を担当PGに相談も無しに受けるのは勘弁して欲しい所です。
時間さえあればもう一度綺麗にまとまったコードを書きたい所なんですが、中々厳しいですよね。

一度組んだプログラムは使われなくなったとしても自分の中に経験として残っていきますので決して無駄では無いと思います。
自分の栄養になる様にむしゃむしゃ食べちゃいましょう。

ひでみ

こんばんわです。ひでみです。


あずきさん。

> 「あぁ、あれ。昨日の夜のミーティングでいらないってことになったんですよ。」と、痛恨の一撃が。

この攻撃は私も何度もくらったことがありますが、何度、受けてもダメージは変わりません(←耐性がつかない)。
「うちの子がいらない子ですって~!」と殴りこみかけるモンスターペアレントになりたいくらいの気持ちになります。


HZさん。

> その変更は確かにちょっと変わるだけだったのですが、根幹の部分がちょっと
> 変わるという物だったので、綺麗にまとまったコードは解体され、継ぎはぎだらけ
> のコードを納品する事になってしまいました。

見た目があまり変わってなくても、ロジック的には相当な修正を必要とすることってありますよね。
それでも締め切りがあるので、「きちんと動くことは動くけど、もっときれいにできるはずなんだ~」と心の中で叫びながらコードをさしだすことになって、「はやいうちに新しい仕様変更がでますように」(←それに便乗してきれいにしようと企んでいる)と祈ったりします(仕様変更がストレスと言いつつ仕様変更を願う矛盾)。

佐々木

「これは絶対に業務が回らんなあ」という仕様をインプリメントするのもストレスが溜まります。
仕様変更は、それでビジネスに寄与するならまだマシという気もします。

友ぞう

ひでみさん、こんにちは。

気まぐれな仕様変更によってコードを作り直すのと同じくらい、
私は、すごく考えて「よし!」と決めた仕様を変えるときにも悲しくなります。
自分でコードを書くことも多いので、もちろんコード変更の悲しさもわかりますが、
仕様を設計してる方だって、結構悲しいんですよ~(笑)

あと、これはユーザーにとっていいと思った機能を設計すると
プログラマ側から「それは手間がかかるのでできません」とか
「えー、面倒くさい」と言われると憤りを感じたりします。
プログラマ側の技術のなさのために仕様をあきらめるとき
なんとも言えない気分になります。
そしてユーザーに使いにくいまま我慢してもらったりして(ああ、罪だわ)

だいたい、そういう場合は最終的にユーザー側からやっぱり我慢できなくって
最初の仕様を実装することになるんですけど。
だったら、最初からやってくれたほうが手間かからなかったのに・・・
これで仕様変更すると文句を言われたりすると、ちょっと心が折れたり。

なので、コードのお葬式は仕様のお葬式と同時にSEとPGで一緒に
やってみてはどうでしょう?(笑)

ひでみ

こんばんわです。ひでみです。

佐々木さん。

> 仕様変更は、それでビジネスに寄与するならまだマシという気もします。

どうみてもビジネスにまったく寄与しない仕様変更ってありますね。
五転くらいして最初の仕様に戻ったりとか(←これは泣けた)。


友ぞうさん。

> 私は、すごく考えて「よし!」と決めた仕様を変えるときにも悲しくなります。

SEの方々も好きで仕様変更を指示しているわけじゃないってことは重々承知しているんですが(苦笑)。

> プログラマ側の技術のなさのために仕様をあきらめるときなんとも言えない気分になります。

う~ん、これはプログラマにどの程度のものを求めているかでちょっと答えがかわりますね。
力量以上のものを求めても何もでてきません。スキルなんてある日、突然、湧いてでてくるものじゃありませんし。
とりあえずある材料でつくるしかないのは現場の常です。
もっとも、その力量を増やす努力をしない人には、さっさと現場からご退場いただきたいものですが。
言われた仕様が実装できなくて悔しい、と思えないプログラマにも。

> なので、コードのお葬式は仕様のお葬式と同時にSEとPGで一緒に
> やってみてはどうでしょう?(笑)

合同供養祭?(爆)

Atsushi777

私の場合は自分で仕様も策定することが多いので全然立場が違いますが、
基本的に仕様変更に耐えられるコードを記述するように心がけています。

なので、より抽象度を増したコードに進化することはありますが、
仕様変更でお葬式をするようなコードは基本的にほとんどないですね。

確かに仕様はかなりごろっと変わることもありますが、
コードは仕様変更に対応できるようにいかに記述するかが、
プログラマとしての腕の見せどころでは?

ひでみ

こんばんわです。ひでみです。

Atsushi777さん。

> 確かに仕様はかなりごろっと変わることもありますが、
> コードは仕様変更に対応できるようにいかに記述するかが、
> プログラマとしての腕の見せどころでは?

仕様変更に関してはおっしゃるとおりですが、機能がばっさりいらなくなった場合はその部分のコードを消さざるを得ません。
未練で残しておくと、後で修正する人を惑わせますしね。
こればっかりはプログラマの腕ではどうにもなりません。

真っ赤なレモン

かわいい。(←何が?とかいったツッコミは無しの方向で。)

コードって、ある意味で言霊ですよね。時として神が宿る。
生まれなかった神は、違う次元か並行世界で、ご活躍をされているのでしょう。


以下、単なる推測。

消えゆくコードが一番多い国は、日本のような気がする。

「走りながら修正を加える」という日本人の仕事の進め方の悪い習性が原因なのかな、と。
大きいところだけ決めて、細かいところは仕事を進めながら決めていく。
日本ではトップダウンでの仕事の進め方はだいたいこうなんだけれども、
かつてはトップがボトム(現場)のことをよく分かっていたので、
「多分、この方向で細かいところも進めていける」という見通しが存在した上で、
仕事が進められてきた。
トップには、「もしもボトムで行き詰まるようなことがあれば、
私が直接細かいところも進める。進められる自信がある」という実力と責任感があった。
今は、トップがボトムのことを知らずに思いつきだけで仕事を進めているので、
何をやってもガタガタ。そして、責任をボトムに押しつける。
トップには、納品までの具体的な方策をイメージしながら立案するという能力が無い。
いや、能力以前に、そういう発想すら無い。

さて。ここまではどんな業種でも当てはまる前振り。
この状況が日本中にはびこっているからこそ、次の話につながる。

そもそも、システム開発(プログラミング)という仕事は、
「走りながら修正を加える」という進め方とは、絶望的に相性が悪い。
なのに、日本人の大多数はそのことを知らない。し、気づいていない。

まともなものを納品してほしいならば、上から下まで、初めから最後まで、
全てに見通しがついた状態からスタートしなければならない。
(実に実に細かい部分まで見通しておく必要は無いかもしれませんが。)

欧米では(日本以外の全世界では?)、どんな業種でも契約に従って
ビジネスを進めるのが普通。
つまり、「あらかじめ決めたことを、決めたようにしかやらない」。
個人間での契約であっても、企業間であっても。
そういう感覚が、どんな業種でも身についている。
なので、日本のシステム開発(プログラミング)のように、
仕様変更という「ちゃぶ台返し」の頻発によってコードの大量虐殺や
デスマが発生するようなことは、日本以外では滅多に起こらないのでは。

ぺけぽん

初めまして♪
記事を読ませていただきました!

私は今年高卒でサイトを作っているのですが会社で働くのもためらってしまってます。私のできる事はIT業界ではまだまだだなと思っちゃいます。

本題ですが、自分が作ったプログラムは保存してしまう方ですw
プログラム初心者として自分が作ったプログラムは宝物です♪
分からないことがあっても保存しておいたプログラムを見て応用したり出来るのでどうしても消せないですw

コメントを投稿する