自分のコードに誇りを持っていますか? 61
ストーリー by mhatta
人生相談 部門より
人生相談 部門より
pinbou 曰く、
本家/.の記事より。ある悩めるプログラマからの問いのようだ。
私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。同じような思いをしている方はいませんか? もしあなたもそうなら、何があなたの潜在能力の開花を阻んでいるのでしょうか? もっと大事なこととして、こうした状況を打破するために何かやろうとしていますか?
私は若いころからプログラミングを楽しんでいて(Apple IIe上のBASICで覚えました)、いろいろな言語やプラットフォームを使い、大小様々な企業で働いてきました。悲しいことに私のキャリアで一定していたのは、私が割り当てられるプロジェクトは、プロジェクトの開始からお客さんの資金が無くなるまで、あてどなく漂流してしまうということです。ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるのに成功した人はいませんか? 誰か自分の上司に、お客がいつも正しいわけではないこと、たまにはノーと言うのが一番のこともあるんだよと説得できた人はいませんか?
主張に矛盾がある (スコア:5, 参考になる)
なのに
というのは何か間違っている。
この人の場合、２つの異なる障害があって、それが複合的にプロジェクトの息の根を止めていると思われる。会社を直すのはより時間が掛かるので、まずは自分を治すことからはじめるべきだろう。
プログラムが『バギーで、遅くて、脆弱で、保守するのも一苦労』な状態になるのは、
・熟慮されたアルゴリズムを用いず(バギー、遅い)
・計算量を事前に予測せず(遅い)
・例外が多く(バギー、脆弱、保守が大変)
・目の前の問題を直せばよい、と修正を最小化使用としすぎるから(保守が大変、脆弱)
である事が多い。これを直すのは一筋縄ではいかないが、
1) まずはアルゴリズムの勉強をする
2) 特に「計算量」の勉強をする
3) アルゴリズムの勉強には「マクロ」レベルからビット操作などの「ミクロ」レベルまであるが、その全てを勉強する事で「例外」を減らす
4) 常に「問題の本質」について考え続ける(症状消しをしない)
5) socket プログラミング、multi thread など、マニュアルを見ただけでは判らない事が続発する領域に関しては、本を読みまくる。他人のコードは「本を読んだ後」の方が良い。腐ったコードの方が世の中には多いので、間違ったコードを覚えてしまう確率が異様に高いからだ。
6) コンパイラ…特にオプティマイザについて勉強する。すると、最近のコンパイラは「わかりやすい記述」をしたほうが最適化が進むことがわかる。すると、「半端に凝った記述」をしなくなる(保守性向上)
というプログラミングの勉強と、
7) コードを書く前に、そのコードが何をするものなのか、文章で書いてみる。で、その通りに本番コードとは異なるプログラミング言語で書いてみる。すると曖昧な部分が判るので、文章を直す。それから本番コードを書く。するとなぜかバグが減る(曖昧な部分が減るため)
8) 明文を書く練習をする
という、実はプログラミング以外でも鍛えられる属性を鍛える訓練を続ける。
結局、知識が圧倒的に不足し、その知識を全てロードしようとすると脳がパンクする所に問題があるのだ。脳の容量を拡張し、マニュアルを見れば判るような知識は捨て、もっと本質的なことを覚えると良い。
二言で言い換えると、「努力不足」「プログラミングを舐めるな」になるんだと思う。
fjの教祖様
大半の問題はこの一点だろ (スコア:0)
必要なときに、壊して一から書き直す手間を省くからそういうことになる。
カウボーイだかエクストリームだか知らないけれど､とりあえず書いて動かすなんて手抜きが許されるのは必要があればいつでも捨てて書き直すという約束が守られる間だけだ。
最初はプレハブや掘っ立て小屋でも構わない。何が建つかも分からないうちから丈夫な基礎を作っても無駄だ。でもそれを大きくしたいなら、基礎から造り直さなきゃ丈夫なビルは建たないってこと。
Re:大半の問題はこの一点だろ (スコア:2, すばらしい洞察)
この前、レビューを頼まれたソースコードはひどかったですね。読んでいて「このコードを書いた人は、この関数がどのように動作すると正しい動作と言えるのか、厳密なイメージが描けていないな」ということが、ありありとわかるのです。おそらく、仮組みしたコードを動かしてみながら、例外的なパターンを後から発見し、アドホックに完成に近付けていったものに違いないのです。
僕自身は探索的プログラミングの信奉者で、コーディング前に綿密な設計が必要だとはあまり思わないのだけれど、こういう事例を見てしまうと「コーディングにはその前提となる設計が必要だ」ということをもっと強調した方が良いのかも知れないと思ってしまいます（もちろん探索的プログラミングは、コーディングを通じて「より良い設計」を追求するのであり、設計が不要だという主張はまったく持っていないのですが）。
やはり、ソフトウェア開発における「生産」はコンパイルであり、コーディングは「設計」なのだということをもっと多くの人が知るべきなのでしょうね。プログラマーは誰でも設計者になる意識を持たないとダメですよ。
Re:大半の問題はこの一点だろ (スコア:1)
努力は怠ってほしくないけど
だれだこの...2KLもある関数作った奴は...
ってのは良く聞く話
Re:大半の問題はこの一点だろ (スコア:2, 興味深い)
うーん、これはどうなんだろう。私はあまり気にしない。
これが可能になるためには、プログラムを「フレームワーク(骨組み)」と「肉付け」に分離する、といったことを意識してコーディングする必要がある。
しかし、ちょろっと書く程度のプログラムで、これらを意識するのは、それ自体重たい作業。エクストリームなどでこれを最初から意識するのは辛かろうし、そもそも「ちょちょいと書いてみる」という方針には合わない。
なので、そんなことは意識せずに書き、『ゴッソリと捨てる』事を勧める。
大事なのは『ゴッソリと捨てる』前に、「なぜ捨てる必要があったのか」「何が悪いのか」をきちんと記録すること(文章の形で)。他の人に見せる必要は無く、「意識するべきポイント」をはっきりさせるために、これをやっておくと良い。
# 大抵の場合、全部捨てて書き直すことになるけれど。
あと、「書き直す」時には「使えるフレームワークが世の中にはすでに無いか」調べること。書き直すのだから、フレームワークにどういう機能があると良いか、イメージはできているはず。それを探してみる。見つかる可能性はあまり高くないけれど、見つかった場合は「世のほかの人達とバグを共有できる」のでbug fix が楽になる。
大丈夫。全部捨てることになるに決まってるから (^o^)。
# 商用ソフトの場合書いた行数より削った行数の方が多い気がする…。
# 三項演算子を if/else に直す等、書く場合は行数が増えているはずなのに…
fjの教祖様
Re:大半の問題はこの一点だろ (スコア:1)
その後になって発覚しませんか？
作り直すのにお金がもらえるなら良いんですが、ボランティアじゃ困りますよね
無論作った当人がやるならそれでも良いんですが...大抵消えてたり...
一人で作ってたり使い捨てとわかっているソースなら良いとは思いますけど
それは客先に納品する製品では出来ないのでは？
今後一生修正しないソースってのもありえないだろうし
Re:大半の問題はこの一点だろ (スコア:1)
そういう実情があるから、捨てるにしても捨てやすいように作ってほしいと
まぁ絶対に納品しない廃棄前提のプロトタイププログラムならまだ良いけど
試験用のプロトタイプをそのまま使おうとしてえらいことになった
プロジェクトってのも見たしなぁ～
なかなか実情は...
Re:大半の問題はこの一点だろ (スコア:1)
プログラムとかだとそういうことも出来るけれど、「プロトコル」とかだとそうはいかない。
結果として「そのまま使おうと言い出す」ならいいんですが「そのまま売りに行っちゃう馬鹿」が出て…大変な目にあいましたよ。何とは言いませんが。
fjの教祖様
自戒してくれるならまだマシ (スコア:5, すばらしい洞察)
こう思ってくれる人なら、今は悪くてもそのうち良くなるよね。
自戒しない人は、何度指摘しても、次から次へとゴミを増産してくれる。
Re:自戒してくれるならまだマシ (スコア:1)
ちょっとどうなんでしょぅね。反省だけなら猿でもできるというか、
実践の伴わない反省には価値がないわけで。
#自分も今までの人生で反省だけはたくさんしてきたので自戒をこめてID
釣りじゃないかな? (スコア:1)
ここにつけるのは不適当かもしれないし、議論に水を差したら申し訳ないけど。
私は「ひどく恥ずかしい思いをしています」ってのは釣りというか、他の人に発言させやすくするためのリップサービスだと思います。「Apple IIe上のBASICで覚えました」ってことならキャリアは普通に考えれば15年以上。「あてどなく漂流してしまう」仕事ばっかり、それだけの間続けられると思います?その間には成功体験がどこかであるはず。しかもこの人、曲がりなりにも「いろいろな言語やプラットフォームを使」えるくらいの柔軟性があって、「大小様々な企業」の人事担当者なりが「この人だったら採用したい/任せてみたい」と思わせるような人なんです。自然に考えると成功体験もそこそこあるんじゃないでしょうか。
# 最初大手で、失敗続きで訳あり小企業しか雇ってくれなくなったってパターンかもしれませんが。
「バギー」ってのは最初の内部コンパイルが通った後は0.1件/KLOC。「遅くて」っていうのが「同じ仕様のSTL実装に負けました」ってレベルで「恥ずかしい」んだったら、私も自分の実力には大変恥ずかしい思いをすることになるでしょう。
もちろん、何年経っても腕が上がらない人はいるでしょうけど、そんな人がこんな問題提起をするかな。本当は、身近にいる「数年やっているんだけどなかなか腕が上がらない人へのよきアドバイス」を求めているような気がします。
# 深読みしすぎ?
とはいえ、そういう人を想定してアドバイスなり意見なりを/.jpの住人が述べることには文句はありません。むしろ、各々の発言は興味深く読ませていただいてます。
vyama 「バグ取れワンワン」
Re:自戒してくれるならまだマシ (スコア:0)
えてして嘆く人間は自分では前に進もうとしません。
よくあること (スコア:5, おもしろおかしい)
しかもコメントとかつけてないんです。全裸です。
昨日飲んだ所までは覚えているんですけど・・・
Re:よくあること (スコア:5, おもしろおかしい)
二度と使わないつもりだったんですけど
結局、関係はずるずると続いてしまって…
まったく個人的な付き合いのつもりが
いつの間にか同僚や上司にバレてしまい、
「責任取れよ」と清書まで求められる始末です
目を覆いたい (スコア:3, 興味深い)
お客さんとのやり取りであったのは、自分が仕切るときは徹底的にやります。間に１社入ったときは「いわれたことだけ」に切り替えます。
とても安く買い叩かれていたサーバ構築の案件だったんですが、単純・費用を安く・止まらない（＝ありえないでしょう）構成を求めてきたので、散々うだつのあがらない会話をして、
「これ管理するとしたら、月いくらで管理しますか？」ときたので、
「管理しません！」
とはっきり断りました。地雷は埋まっているかもしれないから怖い。地雷が埋まっているとわかっている道は、歩かない。
ちょっとプログラミングからは話がそれましたが、内容的にも金額的にも納得しない仕事は、作業量・品質もスルーして「やりっぱなし」にしたほうがいいとおもいますよ。PHPを安く受けている連中の話聞くと、担当者がもういなくなった、当時のやっつけ仕事（＝品質管理なんかあるわけが無い）が、近々大更新（PHP4->5もあるし）するようです。人材確保できてんのかなぁ。
-- gonta --
"May Macintosh be with you"
プログラマじゃなくても (スコア:3, 興味深い)
私も自分で設計した物や作った物を、後から見て恥ずかしくなることは良くあります。
自分で設計して図面も引いた案件で、実際竣工して現場を見てみたら、自分の浅はかさに気がついた・・・とか
運用してみたら現場の保全要員からだめだし食らった・・・とか
法律や卓上、技術的には問題なくても、設備全体（運営や保全も含めて）として優秀かどうかというとそうではないですからね。
まぁ、自分で恥ずかしいと思えるってことは、改善の必要があることに気がついてるんだから気が付かないよりはましですね。
技術屋は日々勉強して、自分のスキルを磨くのも仕事（それとも趣味か？）のうちでしょう。
いつかはどこに出しても恥ずかしくないものを作ってみたい物ですけどね。
好きなだけ予算使わせてくれれば・・・って野暮な突っ込みは無しにしてください（笑）
限られた予算で最良の物に仕上げるのも技量のうちでしょうから
何層離れているか (スコア:2, すばらしい洞察)
クライアントの真のニーズを引き出し、期間・コスト上の現実的な解を示しつつ、
クライアントと共により良い解を模索し、認識を一致させる事は可能です。
中間に営業担当等が一人入る辺りまでは、
自身のコミュニケーション能力・マネジメント能力のみで何とか...。
間に一社、複数の担当者が入ると、もう運の要素が多くなりますよね。
二社以上入った日にゃ
「言われた通りにやればいい」的な意味で
責任意識が薄れるので、逆の意味で平気（をい）
品質に問題あるコードの共通点って何だろう？ (スコア:2, 興味深い)
全ての兆候は、小さなTYPOや意味不明なコメント。
首をかしげるのは、統一されていないネーミングや実装方針。
確信を得るのは、他人が読めなくなるような妙なテクニックの乱用や、名称と内容の不一致。
結論は、構造からして全てが論理的に正しくない。
しかも、そういう人に限って「こんなに色々な言語使えます」=構文しってても構造化すらできない
「ループの数減らして速度あげました」=無関係な処理をひとつにまとめるなボケ
「デザインパターン適用しました、シングルトンです」=どう見てもグローバル変数
と小手先の技や見ためばかり学ぼうとしてコケている気が。努力の方向性が間違っているのでは？
# 誇り？昨日書いた自分のコードには不満があります。成長してますから:-P
Re:品質に問題あるコードの共通点って何だろう？ (スコア:2, おもしろおかしい)
## コードは非の打ちどころがないけど仕様を満たしていない、なんてケースもありますし。
昨日書いた自分のコードが読めないのですが、これは進化なのでしょうか、退化なのでしょうか。
そんなあなたに応援歌 Oliverたんが歌います (スコア:3, おもしろおかしい)
「君はコーディングができる」
若い日はみな デスマで疲れ
書いたソース 自分もわからないよ
夢でデバッグしよう
とても 追いきれないよ
納期よりもっと 大事なことは
バグを出して 自分を試すことだ
君はコードが書ける
誰もコードが書ける
RFP 燃やせばそれで
心も体もさわやかだ 僕らは
若い日はみな 徹夜で逝けよ
( ﾟдﾟ )
こっちみるなw 白目を向いて逝くなｗ
それがデバッグなんだ
それがデバッグなんだ
泣ける日もある そんな時には
バグだろうが 仕様と突き放せよ
君が仕様をだした
僕も仕様をだした
この胸が今 すがすがしいよ
きのうよりも
ソースが大きくなった
これでエンバグ増えた
これでエンバグ増えた
体脂肪 増えるにつれて
心も体もやさぐれた
二次元に 萌えればそれで
心も体もさわやかだ
僕たちは
このあらいを作ったのは誰だぁっ!! (スコア:2, おもしろおかしい)
通信販売？（オフトピ-１ (スコア:2, おもしろおかしい)
そんなあなたに、怪しげな商品を紹介する記事かと思ったのは内緒です。
------------
惑星ケイロンまであと何マイル？
銀の弾丸はないらしいので (スコア:2, すばらしい洞察)
- 正確な伝達ができない者をあいだに挟まない。
- 裏づける判断力もないのに空約束する者をあいだにはさまない。
- 受注だけでは成果にせず、納入までを責任範囲とする。
# 次どうぞ。
Re:銀の弾丸はないらしいので (スコア:2)
それだと成長しないので、能力をやや上回るくらいのことをさせるのが良いと思います。もちろんバッファは用意しておいた方がいい。
その場限りの(プロジェクト|人)ならそれでもいいけど。
Re:銀の弾丸はないらしいので (スコア:1)
その論旨とは外れたところで恐縮ですが、
個人的に、この「バッファ」という言葉の使い方にいつも違和感を感じるのです。この言い回しを使う人、沢山いるのですが。
この場合「マージン」が正しいと思っているのですが、私がおかしいのでしょうか。
いや、つまらん話で誠に申し訳ない。難癖つけるつもりはありません。
重箱の隅には穴があいている (スコア:2, 興味深い)
その特殊だったはずの例が将来「不具合だ！」って騒がれることに。
ある意味、死亡フラグ？
Re:重箱の隅には穴があいている (スコア:2, すばらしい洞察)
正常系だけ書けばいいなら楽なものです……。
-- Where your reading book is, there will your heart be also 天戸 司郎 (Silo Amato)
問題の履き違い？ (スコア:2, 興味深い)
というのは、システム設計上の問題に関係する部分だと思うんだけどなぁ。
コードにいちいち文句をいうお客に対して困っているのであれば、私の巨大な勘違いですが、とりあえずシステム設計に対しての問題点であると仮定してみる。
本人が一番気にしている筈の部分は、文頭の
>私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。
って部分。
そんな悪い品質のコードを書いちゃう原因ってのは、そもそも物事の考え方に問題があるからじゃあないかと思う。
原文を読んでいるわけではないので、誤訳やニュアンスの違いがある可能性もあるのだけれど、
その辺一切は棚に上げておきます。
良い品質のコードを書くには、
・求められている役割（仕様）を正しく理解する
・仕様に足りないもの（穴となるであろう部分）を見つけ出す
・必要以上に複雑にせず、見やすいコードを書くように努める
そして、
・コードが仕様通りに機能し、不具合が発生しないことを検証する
なんてことは/.でわざわざ言う話じゃないか。
（むしろ元ネタを離れてツっこまれそうで・・・）
トピ趣旨からは外れますが、ありがちだけどなかなかできない事に、
「金に見合う仕事をする」
ってのがあると思うんですよ。
夢を見すぎた仕様だけど、お金はこんだけー な感じで、
それをスタート時に夢から覚めぬまま始めちゃうと、
途中でお金無くなって、全てが中途半端なままになっちゃうと。
自分のコードの方針は (スコア:2, 参考になる)
単純にするために、アルゴリズムを目で追えるように要点だけをまとめたものを上位におくようにしています。
無駄を無くするために、不必要な変数をなくしたり、意味の無い処理を削ったりします。
重複を無くするために、同じ処理を複数箇所に書かないこと、同じ条件は一箇所にまとめることを心がけてます。
自分の過去のコードの反省と、メンテ要員の質が悪すぎでとんでもないことになってたソースを眺めた経験からこうするようにしました。
心がけなんで、実際のコードはまだまだ直すべきところが多いんですが。
行動しないというのもひとつの行動 (スコア:1, 参考になる)
PCの前に座らず、
ソースを書かないでいる時間を増やすこと、ですかね。
助さんが刀を抜くのは、番組後半。
さらに言えば (スコア:1)
最後は印籠で無理やり治めるので、あまり本気で刀を振るう必要もないのであった。
Re:さらに言えば (スコア:1, おもしろおかしい)
悪代官クライアント側なのであった。この紋所が目に入らぬか！ (スコア:1)
「そこをなんとか入りませんかね。」
『これじゃ検収無理だね』
「今月形だけでも検収いただかないとこちらも回らなくなりますのでなんとか。」
『とはいってもこっちも首かかってるしねぇ』
「3ヶ月間常駐して無償で対応しますから。」
『半年だねぇ。』
# この作品はフィクションのはずであり、実在の人物団体等は一切関係ないと思われます。
## まぁ微妙にリアリティ無いけどな。
コードの品質とは何か (スコア:1)
メモリ容量がなかった時代は簡潔で短いコードが良しとされました。
今はメンテナンスが容易なコードでしょうか。
時代と共に品質の示すものも変わるでしょう。
Re:コードの品質とは何か (スコア:1, 興味深い)
Re:コードの品質とは何か (スコア:0)
たいていの場合、短くて簡潔に書かれたコードはメンテが容易だと思うよ。
変数名を1文字だけにするとか、スペースや改行を置かずに詰めて書くとかの
ムリヤリな短縮化はしない方がいいけどな。
しかし、元記事のヒトはApple IIeなんて時代からプログラム書いてるのに、
短く簡潔に書こう！みたいなクセが付かなかったんだろうか。
オレ、NECのパピコンあたりからプログラム書いてるけど、いつも
もっと短く、速く走るようにできないだろうかって、ある意味偏執的なぐらい
自分のコードを推敲するよ。
なので、わりと人に見せても恥ずかしくないコード(まー極上とはいわないが、
少なくとも中の上程度)が書けてる自信はある。
Re:コードの品質とは何か (スコア:0)
今は迂遠でもわかりやすいコードを書くことに注力しています。
場合によってはわざとダラダラ長く書いたりもしてますよ。
Re:コードの品質とは何か (スコア:0)
私もそうしてますね。
自分の手を離れた後、どの程度のスキルを持った人がコードを読むかわからないので、
極力初心者でも理解できる＆コメントいっぱいのコードを書いてます。
---------------
昔やった作業で、私から作業を引き継いだ人が本当のPG初心者で非常に困った事があり、
その時の経験からこの考えに変わりました。
Re:コードの品質とは何か (スコア:0)
自分のコードももちろんだけど (オフトピ) (スコア:1)
-supercalifragilisticexpialidocious-
コード品質についてだけ言えば (スコア:1, 興味深い)
持っていません!! (_) (スコア:1)
誇りを持たないことが誇りです。
誇ってしまうと成長が止まってしまいがちになるからです。
...って、啓発系のお話ではないようですねw
このシナリオに出くわしたことがないですね。
上司はお客さんについてある程度正しく認知しているパターンが多く、とりあえず自分と同じ理由で悩んでいることが多いです。
お客さんを説得する前に 'システム開発がわかっていない' 上司を説得しなくてはいけないということですね。
普段からコミュニケーションをとって聞く耳を持ってもらった上で、根気良くわかってくれるまで説明するしかないでしょうね。(専門用語抜きで)
難しいことは理解しようと思えない人が多いですから、聞く耳を持たせるのは重要です。
聞く耳を持たせるために仲良くなるのも結構重要です。でも正直なところ臨機応変でしょうね。
C# と VB.NET の入門サイト [wankuma.com]
顧客からの変更や途中の注文が多いみたいだけど (スコア:1)
技術的には「昨日のコードはクソ」だなぁ...。自分のコードを誇っていられるのはそれを吐いてる時だけだよ。
「誇り」だけでは足りない (スコア:1)
自分が手がけた仕事の成果に誇りと「責任」を持つ必要がある。
この二つは不可分。
「誇り」だけでは独善的になり、まともな仕事は来なくなる。
「責任」だけでは便利屋と見なされ、こき使われて潰される。
態度は偉そうだけど成果はヤリ逃げ＆責任転嫁、な連中に
さんざん煮え湯を飲まされた挙句の、
さしあたっての結論。
----------科学は思考の柔軟剤
格言 (スコア:1)
「他人の仕事は自分でしない」
コメントから作る (スコア:1)
自分の作るプログラムは、アルゴリズム・デバッグだけ自分でやり、それを実用化のために修正するのは他人ですから、分かり易く、直し易くないと始まらない。
コメント (文章) から書くと、機能分割も言葉で表現し易くなり、「コメントで分かる」以上の効果があります。(当然、説明とプログラムが食い違うなどありえない)
かなり、特殊なプログラミング状況だけどね。(プログラムじゃなく、アルゴリズムを作ってる)
the.ACount
ほえ？ (スコア:0)
＞たまにはノーと言うのが一番のこともあるんだよと説得できた
＞人はいませんか?
仕事してれば、そんなの日常茶飯事だと思うけど？
# 日常茶飯事じゃないほうが理想ではあるけどね
Re:ほえ？ (スコア:3, 興味深い)
どうせ届かない「ノー」なら、言うだけ労力の無駄と悟った結果であった。
とか？
スラドはフリープログラマが多いな(オフトピ:-1) (スコア:0)
の書き込みが多くてびっくり。
Re:プログラマの適性 (スコア:1, 興味深い)
オレが若い頃いっしょに仕事してた同僚は、いつまでたっても(3〜4年くらいしか
付き合いなかったけど)スパゲッティ状のコードばっかり生産してたなー。
でもね、彼のデスクの上とか引出しの中などは、ビシーっとキレイに整理整頓
されてるの。オレはどっちかというと乱雑に放りっぱなしだったが。
書くコードの内容(読みやすさ)は正反対、みたいな。