「ある中級プログラマの告白」

http://postd.cc/confessions-of-an-intermediate-programmer/
http://www.michaelbromley.co.uk/blog/65/confessions-of-an-intermediate-programmer
メモ.
「動いてるから良いじゃない」な感じの,人よりちょっと器用なだけのPHPerの経験談かな.

斜め読みだけど,ケーススタディーとして興味深い事例.

プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。

でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。

自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、なおさら特別です。

当時の私にとってオブジェクト指向アプローチは、数多く存在する無用なオーバーヘッドやボイラープレート*1でしかありませんでした。自分の考えを裏付けてくれるような誤った情報も信じていたし、自分のプログラムに対するテストも完璧だと思っていました。と言っても何度かクリックして問題なさそうならリリースする、といった具合でしたが。(奇抜で複雑すぎる)アーキテクチャがあることは何となく気づいていましたが、それでも自分のプログラムは(恐らく最速で)非の打ち所はないと思えたのです。

自らの素手と知恵でフル機能のeコマースサイトを作り上げ、それが問題なく稼働している。この事実こそ、私のコーディングが間違っていなかったことの証しです。サイトは順調に動き、さらに拡大していきました。

残念ながら、この状況は数年間続きます。その間、サイトに関しては片手間で対応し、1日の大半はまったく違う分野の仕事をしていました。しかし数年間の保守作業と、たまに新機能を追加しているうち、サイトを構築した時の判断ミスに気づき始めます。ソースファイルのどこに何が書いてあるか、探し出すだけでかなり時間がかかるのです。それにサイトに手を加えると、まったく無関係な箇所でマイナーバグが多発しました。私はこのことに不安を感じ始めます。

データアクセス関数をすべて書き直そうとした時、私は事の重大さに気づきます。事態はかなり深刻であり、深刻になった理由まで分かりました。

その理由は、関数がいたる所に散らばっていること、わずかな変更でもどんな影響が現れるか予測できないこと、コードに一貫性がないためインスタンスごとの結果にチェックが必要なこと、大部分のコードは他と密接に連携しており、一部を変更すれば破たんする可能性もあること。こうした理由から修正は面倒になるだろうと予測したのです。要するにこの雑然としたコードは、それまでの悪癖と理解不足の産物であり、今になってしっぺ返しを食らったのです。

よくある話.日本企業で目にしたコードの9割以上はこんな感じだった気もする.

ある名言で記事を締めくくりましょう。この記事の文案を練り始めた頃、ティーブ・マコネルの著書『Code Complete Second Edition』を読み終えるところでした。この本の825ページに書かれていた言葉には、記事を書こうとした時の私の心情がそのまま表現されています。ここまで数千語を費やしてきましたが、マコネル氏はたった2文にまとめました。

初心者や中級者であること、リーダーではなく優秀なプログラマであることは罪ではない。本当の罪は自らを向上させるすべを知ったあとも、初心者や中級者の立場に甘んじていることだ

なおCode CompleteのKindle版は今月の月替わりセールの目玉商品.Kindleで購入する気があるなら,今月中がお勧め.

http://d.hatena.ne.jp/JavaBlack/20140601/p1

訳を見てみると

"It’s no sin to be a beginner or an intermediate. It’s no sin to be a competent programmer instead of a leader. The sin is in how long you remain a beginner or an intermediate after you know what you have to do to improve.”(Curiosity)

初級者レベルや中級者レベルであることは罪ではない。指導者レベルではなく上級者レベルであることも罪ではない。罪であるのは、自分の能力を向上させるために必用なことをすべて知った後も、初級者レベルや中級者レベルに甘んじることである。(33.3「好奇心」の末尾)

微妙に意味が違う気がする.

http://b.hatena.ne.jp/entry/postd.cc/confessions-of-an-intermediate-programmer/

  • id:hush_puppy 数年かけて、自分の負債で自分を苦しめる経験ができるなんて、本当に幸せ者だな。

ある意味でそれなりに優秀ではあったのでしょう.

残念なのは,系統的な学習や先人達の知恵を軽んじたこと.

  • id:hatekun33 過去に自分が書いたクソコードをメンテナンスするつらさ…
  • id:stealthinu ああ… 人の書いた糞コードに苦しめられるのも嫌だけど過去の自分が書いた糞コードに苦しめられるのはキツイな。なんせ人のせいに出来ないから…

日本のSIerだと,スパゲッティになった頃には当の本人はトンズラして,保守は他人に押しつけるという糞プログラマーにとってのベストプラクティスがあります.

  • id:ka-ka_xyz こういうコードは大抵書いたヒトが何処か他所へ逝ってしまい、押し付けられたヒトが一日20回ぐらいの割合で四文字言葉をつぶやきつつメンテすることになる。

激しく同意.

  • id:hiroyuki1983 これは多分正しい成長のプロセスなんだと思う。壁にぶつかりもしないうちから頭でっかちに壁の登り方ばかり研究している姿ほど滑稽なものはない

んなことはない.

  • 良い教育者なら適度な小さな事例で失敗を経験させ,教訓を学ばせることができる.
  • センスのある開発者なら,見た時点でOOPのメリットと自分のコードの「悪い臭い」を感じ取ることが出来る.
  • ベストプラクティスや失敗事例は,良い書籍から学ぶことも出来る.
  • 他にも他人の意見を求めることだって出来たはずだ.むしろ何年も耳を貸さなかった結果がこれ.

その理屈だと,この程度の基礎知識を学習するために,ベンチャー企業を一つ倒産させねばならんことになる.それは論外だろう.*2

「okkyの日記: 伸びるエンジニアについて」

http://slashdot.jp/journal/273146/%E4%BC%B8%E3%81%B3%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

大昔に読んでたのをメモを取り忘れていたのを発掘.

経験は関係ない

実はこの条件は 先のページ と意見が衝突する。私は経験は関係ない派である。

本来脳というのは共通項目抽出機だ。 つまり「あれも車」「これも車」という事実から、 「車とは何か」という抽象概念を自立導出する能力がある、 というのが脳の最大の特徴である。

しかし、現実には多くのプロジェクトを通じ 何も学習しない人は多い。 だから、Brooksの Mythical ManMonth などという本が書かれて 25周年記念をしているのに、 それどころか孫子の兵法まで「逐次投入愚の骨頂」と 書かれているのに、人月計算と逐次投入をやれば問題は解決する というプロジェクトマネージャばかりになる。

これは結局どういうことかと言うと、 プロジェクトから共通項目を引き出せるほど 人は多くのプロジェクトを経験できない と言うことだ。100のプロジェクトを経験すれば 馬鹿にでも導出できるかもしれない基本原理も、100のプロジェクトを経験できなければ導出できるわけはない。3つのプロジェクトを経験しただけで 同じ基本原理が導出できるのは天才だけだろう。

結局、経験したプロジェクトの多寡は影響しない。というかできない。

影響して見えるのは、プロジェクトの多寡ではなく、 そこからいかに多くを学び、それを表現できるかである。 学ぶことが少なかったプロジェクトについて言及できることは あまりない。だから学習能力の低い人はプロジェクトをあまり経験していない ように見える。でも、そんなことはない。 その人はプロジェクトを経験していないのではなく、 プロジェクトから学んでいないだけだ。

全部ではないけど,基本的な考え方としては同意.


上記の例のような「中級プログラマ」は,実際に何かトラブルが発生して,悪化して,手に負えなくなるまで気付かない.
優れたプログラマはそうではない.何か問題が発生する「前」にそのトラブルを予測し,対策をうつ.つまり問題が発生する前に問題を解決する.これができない人間は,いつまでたっても中級のままなのでは.

では、上級のプログラマはどうするであろうか。まず、できるだけ誤りを犯さずに済む方法を考える。これが、上級者にとってのテーマである。こういうことを考えないようでは、上級レベルまで行くことはありえない。当然、彼等のプログラムには、誤りを犯しにくくなるような、あるいは、たとえ誤りを犯しても発見し易いような工夫がされている。

この差は、開発時間の差になり、プログラムの品質の差になってくる。

http://www.pro.or.jp/~fuji/mybooks/okite/okite.2.3.html


たとえばセウォル号の船長が「経験30年のベテラン船長」だった事実は忘れちゃならんと思う.日本にはセウォル号船長に勝るとも劣らない,経験年数だけが売りのベテランプロマネやらSEやらがゴロゴロいるんだろうな.

*1:boilerplate:(コード中に何度も登場する)決まり文句.「おまじない」と呼ぶこともアリ.
「意味はわからなくていいから,とりあえずそこに同じ文言をコピペしとけば問題なく動くよ」程度の意味だと思われ.

*2:セウォル号船長一人育てるために,船一隻転覆させて300人近くの犠牲者を出す必要がある?んなバカな.その程度の学習ならば,可能な限り犠牲無しに行うべきだ.