スラッシュドット・ジャパン

私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。

なのに

ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるのに成功した人はいませんか?

というのは何か間違っている。

この人の場合、２つの異なる障害があって、それが複合的にプロジェクトの息の根を止めていると思われる。会社を直すのはより時間が掛かるので、まずは自分を治すことからはじめるべきだろう。

プログラムが『バギーで、遅くて、脆弱で、保守するのも一苦労』な状態になるのは、

・熟慮されたアルゴリズムを用いず(バギー、遅い)
・計算量を事前に予測せず(遅い)
・例外が多く(バギー、脆弱、保守が大変)
・目の前の問題を直せばよい、と修正を最小化使用としすぎるから(保守が大変、脆弱)

である事が多い。これを直すのは一筋縄ではいかないが、

1) まずはアルゴリズムの勉強をする
2) 特に「計算量」の勉強をする
3) アルゴリズムの勉強には「マクロ」レベルからビット操作などの「ミクロ」レベルまであるが、その全てを勉強する事で「例外」を減らす
4) 常に「問題の本質」について考え続ける(症状消しをしない)
5) socket プログラミング、multi thread など、マニュアルを見ただけでは判らない事が続発する領域に関しては、本を読みまくる。他人のコードは「本を読んだ後」の方が良い。腐ったコードの方が世の中には多いので、間違ったコードを覚えてしまう確率が異様に高いからだ。
6) コンパイラ…特にオプティマイザについて勉強する。すると、最近のコンパイラは「わかりやすい記述」をしたほうが最適化が進むことがわかる。すると、「半端に凝った記述」をしなくなる(保守性向上)

というプログラミングの勉強と、

7) コードを書く前に、そのコードが何をするものなのか、文章で書いてみる。で、その通りに本番コードとは異なるプログラミング言語で書いてみる。すると曖昧な部分が判るので、文章を直す。それから本番コードを書く。するとなぜかバグが減る(曖昧な部分が減るため)
8) 明文を書く練習をする

という、実はプログラミング以外でも鍛えられる属性を鍛える訓練を続ける。

結局、知識が圧倒的に不足し、その知識を全てロードしようとすると脳がパンクする所に問題があるのだ。脳の容量を拡張し、マニュアルを見れば判るような知識は捨て、もっと本質的なことを覚えると良い。

二言で言い換えると、「努力不足」「プログラミングを舐めるな」になるんだと思う。

> 私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。

こう思ってくれる人なら、今は悪くてもそのうち良くなるよね。
自戒しない人は、何度指摘しても、次から次へとゴミを増産してくれる。

今朝目覚めたら、自分のベッドに知らないコードが寝ているんです。
しかもコメントとかつけてないんです。全裸です。

昨日飲んだ所までは覚えているんですけど・・・

自分の過去に書いたコードは、目を覆いたいものばかりです。先輩やオープンソースのコードを眺めて、ある程度「見られる（可能）」品質にあげたいなぁ。上記２例は、かなりいいお手本です。

お客さんとのやり取りであったのは、自分が仕切るときは徹底的にやります。間に１社入ったときは「いわれたことだけ」に切り替えます。

とても安く買い叩かれていたサーバ構築の案件だったんですが、単純・費用を安く・止まらない（＝ありえないでしょう）構成を求めてきたので、散々うだつのあがらない会話をして、
「これ管理するとしたら、月いくらで管理しますか？」ときたので、
「管理しません！」
とはっきり断りました。地雷は埋まっているかもしれないから怖い。地雷が埋まっているとわかっている道は、歩かない。

ちょっとプログラミングからは話がそれましたが、内容的にも金額的にも納得しない仕事は、作業量・品質もスルーして「やりっぱなし」にしたほうがいいとおもいますよ。PHPを安く受けている連中の話聞くと、担当者がもういなくなった、当時のやっつけ仕事（＝品質管理なんかあるわけが無い）が、近々大更新（PHP4->5もあるし）するようです。人材確保できてんのかなぁ。

設計や物作りに携わっている人達の共通の悩みかと思いますけどね。

私も自分で設計した物や作った物を、後から見て恥ずかしくなることは良くあります。

自分で設計して図面も引いた案件で、実際竣工して現場を見てみたら、自分の浅はかさに気がついた・・・とか
運用してみたら現場の保全要員からだめだし食らった・・・とか

法律や卓上、技術的には問題なくても、設備全体（運営や保全も含めて）として優秀かどうかというとそうではないですからね。

まぁ、自分で恥ずかしいと思えるってことは、改善の必要があることに気がついてるんだから気が付かないよりはましですね。
技術屋は日々勉強して、自分のスキルを磨くのも仕事（それとも趣味か？）のうちでしょう。

いつかはどこに出しても恥ずかしくないものを作ってみたい物ですけどね。
好きなだけ予算使わせてくれれば・・・って野暮な突っ込みは無しにしてください（笑）
限られた予算で最良の物に仕上げるのも技量のうちでしょうから

クライアントとの間に中間層が無いシンプル（小規模）なプロジェクトであれば、
クライアントの真のニーズを引き出し、期間・コスト上の現実的な解を示しつつ、
クライアントと共により良い解を模索し、認識を一致させる事は可能です。

中間に営業担当等が一人入る辺りまでは、
自身のコミュニケーション能力・マネジメント能力のみで何とか...。

間に一社、複数の担当者が入ると、もう運の要素が多くなりますよね。

二社以上入った日にゃ
「言われた通りにやればいい」的な意味で
責任意識が薄れるので、逆の意味で平気（をい）

個人的には「論理的に考えられていないコードであること」だと思います。
全ての兆候は、小さなTYPOや意味不明なコメント。
首をかしげるのは、統一されていないネーミングや実装方針。
確信を得るのは、他人が読めなくなるような妙なテクニックの乱用や、名称と内容の不一致。
結論は、構造からして全てが論理的に正しくない。

しかも、そういう人に限って「こんなに色々な言語使えます」=構文しってても構造化すらできない
「ループの数減らして速度あげました」=無関係な処理をひとつにまとめるなボケ
「デザインパターン適用しました、シングルトンです」=どう見てもグローバル変数
と小手先の技や見ためばかり学ぼうとしてコケている気が。努力の方向性が間違っているのでは？
# 誇り？昨日書いた自分のコードには不満があります。成長してますから:-P

>私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。
そんなあなたに、怪しげな商品を紹介する記事かと思ったのは内緒です。

- 能力のない人に能力を上回ることをさせない
- 正確な伝達ができない者をあいだに挟まない。
- 裏づける判断力もないのに空約束する者をあいだにはさまない。
- 受注だけでは成果にせず、納入までを責任範囲とする。

# 次どうぞ。

「そんな特殊な例は考えなくっていいよ」って言われた、
その特殊だったはずの例が将来「不具合だ！」って騒がれることに。

ある意味、死亡フラグ？

>お客がいつも正しいわけではないこと、たまにはノーと言うのが一番のこともあるんだよと説得できた人はいませんか?

というのは、システム設計上の問題に関係する部分だと思うんだけどなぁ。
コードにいちいち文句をいうお客に対して困っているのであれば、私の巨大な勘違いですが、とりあえずシステム設計に対しての問題点であると仮定してみる。

本人が一番気にしている筈の部分は、文頭の

>私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。

って部分。
そんな悪い品質のコードを書いちゃう原因ってのは、そもそも物事の考え方に問題があるからじゃあないかと思う。
原文を読んでいるわけではないので、誤訳やニュアンスの違いがある可能性もあるのだけれど、
その辺一切は棚に上げておきます。

良い品質のコードを書くには、
・求められている役割（仕様）を正しく理解する
・仕様に足りないもの（穴となるであろう部分）を見つけ出す
・必要以上に複雑にせず、見やすいコードを書くように努める
そして、
・コードが仕様通りに機能し、不具合が発生しないことを検証する

なんてことは/.でわざわざ言う話じゃないか。
（むしろ元ネタを離れてツっこまれそうで・・・）

トピ趣旨からは外れますが、ありがちだけどなかなかできない事に、
「金に見合う仕事をする」
ってのがあると思うんですよ。

夢を見すぎた仕様だけど、お金はこんだけー　な感じで、
それをスタート時に夢から覚めぬまま始めちゃうと、
途中でお金無くなって、全てが中途半端なままになっちゃうと。

なるべく単純に、無駄が無く、重複が無いように心がけてます。
単純にするために、アルゴリズムを目で追えるように要点だけをまとめたものを上位におくようにしています。
無駄を無くするために、不必要な変数をなくしたり、意味の無い処理を削ったりします。
重複を無くするために、同じ処理を複数箇所に書かないこと、同じ条件は一箇所にまとめることを心がけてます。

自分の過去のコードの反省と、メンテ要員の質が悪すぎでとんでもないことになってたソースを眺めた経験からこうするようにしました。
心がけなんで、実際のコードはまだまだ直すべきところが多いんですが。

もっと大事なこととして、こうした状況を打破するために何かやろうとしていますか?

PCの前に座らず、
ソースを書かないでいる時間を増やすこと、ですかね。

助さんが刀を抜くのは、番組後半。

という定義が必要でしょうね。
メモリ容量がなかった時代は簡潔で短いコードが良しとされました。
今はメンテナンスが容易なコードでしょうか。
時代と共に品質の示すものも変わるでしょう。

自分の*行動*に誇りをもちたい、と思う年末進行中。

尊敬できる確かな技術を持った先輩、要は間違ってたら丁寧に教えてくれる人が身近にいないとなかなか上達しないと思う。

自分のコードに誇りを持っていますか?

誇りを持たないことが誇りです。
誇ってしまうと成長が止まってしまいがちになるからです。
...って、啓発系のお話ではないようですねw

誰か自分の上司に、お客がいつも正しいわけではないこと、たまにはノーと言うのが一番のこともあるんだよと説得できた人はいませんか?

このシナリオに出くわしたことがないですね。
上司はお客さんについてある程度正しく認知しているパターンが多く、とりあえず自分と同じ理由で悩んでいることが多いです。
お客さんを説得する前に 'システム開発がわかっていない' 上司を説得しなくてはいけないということですね。
普段からコミュニケーションをとって聞く耳を持ってもらった上で、根気良くわかってくれるまで説明するしかないでしょうね。(専門用語抜きで)

難しいことは理解しようと思えない人が多いですから、聞く耳を持たせるのは重要です。
聞く耳を持たせるために仲良くなるのも結構重要です。でも正直なところ臨機応変でしょうね。

だとするとまずプロジェクトの開始前に顧客の「本当の望み」を聞き出せてない事が問題。「仕事と私、どっちが大事なの？」と詰め寄られたときの模範解答が「寂しい思いをさせてごめん」だったりするようなもん。顧客は仕様の話をしようとするだろうけど顧客はソフトウェアの仕様に関しては素人なので、まず前の段階へ話を戻す必要がある。この要素に関しては営業サイドの責任の方が重い。

技術的には「昨日のコードはクソ」だなぁ...。自分のコードを誇っていられるのはそれを吐いてる時だけだよ。

コードに限らず、
自分が手がけた仕事の成果に誇りと「責任」を持つ必要がある。
この二つは不可分。
「誇り」だけでは独善的になり、まともな仕事は来なくなる。
「責任」だけでは便利屋と見なされ、こき使われて潰される。

態度は偉そうだけど成果はヤリ逃げ＆責任転嫁、な連中に
さんざん煮え湯を飲まされた挙句の、
さしあたっての結論。

とりあえずプログラム上の格言を一つ
「他人の仕事は自分でしない」

プログラム自体はコメントから書き始めます。(その前にアルゴリズム説明書を書くけど、プログラム作ったら、実際の作動状況／テスト結果も説明書に入れる)
自分の作るプログラムは、アルゴリズム・デバッグだけ自分でやり、それを実用化のために修正するのは他人ですから、分かり易く、直し易くないと始まらない。
コメント (文章) から書くと、機能分割も言葉で表現し易くなり、「コメントで分かる」以上の効果があります。(当然、説明とプログラムが食い違うなどありえない)
かなり、特殊なプログラミング状況だけどね。(プログラムじゃなく、アルゴリズムを作ってる)

そんなの日常茶飯事

しかし、担当者が上司に上げた「ノー」は、顧客に届かないのが常であった。

日常茶飯事じゃないほうが理想

どうせ届かない「ノー」なら、言うだけ労力の無駄と悟った結果であった。

とか？

あー、あるかもしんないねー。
オレが若い頃いっしょに仕事してた同僚は、いつまでたっても(3〜4年くらいしか
付き合いなかったけど)スパゲッティ状のコードばっかり生産してたなー。

でもね、彼のデスクの上とか引出しの中などは、ビシーっとキレイに整理整頓
されてるの。オレはどっちかというと乱雑に放りっぱなしだったが。
書くコードの内容(読みやすさ)は正反対、みたいな。