読者です 読者をやめる 読者になる 読者になる

「ぼくはこうしてプログラミングを覚えた」に共感したことと、業界について考えたこと

先週人気のブクマに上がっていたWebの記事について、ちょっと書いてみる。
Evan Priestley 氏がどうやってプログラミングを学んだかを教えてください | Knoh (ノウ)

当初ぼくは、ほとんど考えずコードを「アンダーエンジニアリング」していた。後々これを過度に修正してしまい、全てを「オーバーエンジニアリング」し作り込みすぎてしまった。2年半という時間はこういった失敗を経験するには十分な時間で、辞めるころにはシステムのデザインの塩梅が、かなりわかるようになっていたと思う。

やらなさ過ぎても、やり過ぎてもうまくいかない、という話。これはもうホントその通り。そのバランスを取れないと、保守フェーズに入って1年とか経ったとき、うんざりするハメになる。出来上がった時はいいんだよ。その時点では完成品になってるんだし。でも、そこから何かを変える時、「いい塩梅」になっていないと、困ったことになりやすい。正規化や最適化が行き過ぎると、直しにくくなる。抽象的なアレで申し訳ないんだけども、ちょっとした「遊び」が欲しい。そこのところを「オーバー」と「アンダー」という表現で表したのは、納得。

それに、どのプログラミング言語を使うかってのは、多くの人が考えるほど重要ではないと思う。ぼくの経験上、一番PHPをバカにし、言語の重要性をうそぶく連中は、大体自分たちが提唱する言語でもロクな仕事ができないことが多い。

次はランゲージの話。まあ、ソフトウェア技術者界隈では、やっぱりランゲージの話題が喧しいんだけど、業務畑に近い立場から言わせてもらえば、そんなことはどうでもいいんだよw ほんと、これは同感。ソフトウェアが金になるかどうかは、どんなランゲージを使うかで決まらない。どれだけお客様を喜ばせられるかだよ。そのプログラムが、うんこのようなものだったとしても、利用者にはそんな事はどうだっていい事だ。結局のところ、ソフトウェア技術者の言うところの「良いソフトウェア」というのは、利用者の立場から発せられたものではない事が多い。「実装が芸術的に美しいが、実務で使い物にならないゴミ」と「うんこのような実装だけど、使い勝手のいいソリューション」だったら、後者が勝つ。ここの所を、もっと自覚しないとダメだと思う。こーゆー論はつまらん正論なので、盛り上がらないんだけどねw

そして、ぼくはコードを見てしまった。

コードの質がフェイスブックの強みであったことはないが、2007年のフェイスブックのコードはグローバル変数とextract関数にまみれたヒドいものだった。

これは、前の節の証左でもある。で、もうひとつ言えることは、いいコードや、いいコードを書く人というのが、どこにいるのかはわからん!という事だと思う。少なくとも事業規模や給与の高低と、「良いコード」を書くスキルの相関があるか?って言ったら、個人的な経験に基づいて言えば、もうホント相関はないんじゃないですかね?w 逆の相関もまたないと思う。

すごく残念な事を書くけど、これは「良いコードを書くスキル」は金に直結しない、評価されない、という事だと思う。最終製品の品質に直結するので、おろそかにできないスキルなんだけどね。という事は、最終製品の品質ってのは、ソフトウェアの商業においては、重視されていないということなのかもしれないな。

念のため書いておくけど、この事は、「最終製品の品質は重要じゃない」って言いたいわけじゃない。これまでは、重視されてこなかったんじゃないのか?(周辺の事情を鑑みるに)という指摘をしたいんです。これが本当に重視される業界なら、トップ銀行がかっこわるいシステム障害起こしたりなんて、しないと思わない? でも、「あーあ」みたいな事が現実に起こる。じゃあ、どうしたらいいんだろう?

多分、ソフトウェアの品質というものについて、もっとインセンティブやペナルティを課して技術者や会社の淘汰や世代交代を促してやるしかない。ありきたりな答えだけどもw 現実問題、大きなところほど障害起こしても、ペナルティがないと思うんだよねw お上もトップ銀行を潰すわけにもいかないし、直接の被害をうけなかった大勢の人たちは無関心だし。そこんところは、どうしていけばいいのか、全くイメージ沸かないなw

えーと、落ちがないまま終わりますw でも、なんか、元の記事のタイトルと全く違うところに思考が流れてって面白かったのでこのまま投下します。送信!