wikisourceに日本語訳が上がっていたので一通り読んでみました。(なぜか#45が欠けてる?)
プログラマの仕事を長年続けていれば、まぁそうだよね、というものばかりです。
(最初、一人で97個ものネタを考えてコラムを書いたんかい、と驚きましたが、複数人によるネタの寄せ集めですね＾＾；)
3 ユーザが何をするかを観察する(あなたはユーザではない)
ユーザは、自分の目的がどうにか達せられれば、それでよしとします。
効率良くやろうとはあまり考えません。何とか目的を達せられる方法を1つ発見すれば、ずっとその方法に固執します。
それがいかに非効率な方法だろうと、容易には変えようとしないのです。
バージョンアップしてせっかく機能追加しても、使ってくれないってのはありますよねｗ
また、ユーザだけでなく私自身も、１つのプログラミング言語(C/C++)から抜けれません。。。(43 プログラミング言語は複数習得すべき)
92 顧客の言葉はそのまま受け取らない_
顧客には顧客独自の用語とコンテキストがあります。
日本人プログラマによる知っておくべき10のこと 9
ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。
実際にそうした機能やオプションが欲しいとおもっているのは、ごく一部であるにもかかわらず、声の大きいユーザからの要望を無視することができず、忠実に応えようとするあまり、あなたはそれをすべて実装してしまいます。
付き合いの長い顧客ならいいのですが、初対面の顧客だと対応は慎重になりますよね。どんな使い方をするユーザなのかわからない。
事前デモ、納品検収まで経て、実ユーザが登場してやっとUIの改良すべき点が見つかったりします。
また、私は顧客側とセールス側のどちらも経験しましたが、顧客側の場合には、「要望が通ったらしめたもの、もっと要求して予算以上のものを作らせてやる」ってのが頭にありますｗ
ユーザのためにと何でもホイホイ対応するのでなく、詳細検討します(本当はできるんだけどね)、とワンクッションおく駆け引きをするようになります。
(日本人の「できません」ですね)
9 他人よりまず自分を疑う
プログラマというものは(つまりわたしたちは)自分の書いたコードに何か誤りがあるとは、なかなか考えようとしない人種です。
現に問題が起きていても、それが自分のせいだと思うことは滅多になく、「きっとコンパイラのせいだろう」などと思ったりします。
この考えが行き過ぎると、普段の生活でも何かあったときに自分に否があったんじゃとすぐ考えるようになってしまうんですけどね。。。
11 ドメインの言葉を使ったコード
何ヶ月か時間が経ってからコードを見たプログラマは、きっと最初にコードを書いた人に感謝するでしょう。
そしてそのプログラマは、最初にコードを書いた本人かもしれないのです。
これもあるある。えっこんなきれいなコード書いてたんだとびっくりしたり。
__56 未来へのメッセージ__にもありますが変に凝った処理をしないってのもそうですね。
7 共有は慎重に
コードの再利用を安易に促進すると、かえってひんしゅくを買ってしまうのだ、ということを。
あるある。リファクタリングやってて、やりすぎて戻ることがよくあります。
あと、同一処理の繰り返しでも下の13のように、同じ処理の繰り返しの違う部分だけを見つけやすくするって効果があるので
敢えて手を加えなかったり。
13 コードレイアウトの重要性
同じように書かれている部分が続くと、それはまるで「背景」のように見えます。
見た目が似ているコードは動きも似ているという原則が徹底されていれば、違いをすぐに見つけることが出来ます。
人間の視覚は、他と違っている場所をすぐに見つけられるようにできているからです。長いコメントを入れたり、ホワイトスペースを多く入れたりすることは、名前に8文字の制限があった時代、
ラインプリンタの時代には意味がありました。ですが、今やシンタックスハイライトやクロスリンクなどの機能が使えるIDEの時代です。
つまりディスプレイの制約の方が大きいのです。できるだけ多くの要素を一度に見渡せた方が、コードは理解しやすくなります。
17 コードに書けないことのみをコメントにする にもありますが、
私がリファクタリングをやるときに最初にやることはコメントと字下げの(自分用の一時的)整理です。
歳を取ると一時的な記憶力が低下してキーワードをつぶやきながらでないと作業したい内容をすぐ忘れてしまうので、なるべく1画面でやりたいことが
わかるようにします。ただし7の作業とバランスを取りながら。
16 コメントについてのコメント
怒りのあまり、私はそのメールの文面をコードのヘッダコメントにコピー&ペーストしてしまいました。
そして後になって、そのコードをコミット後にレビューするのは、まさにメールを送ってきた上司である、ということがわかったのです。
25 見られて恥ずかしいデータは使わないこと にもありますが、これは私にも経験あります。。。
__88 コードは生涯サポートするつもりで書く__にあるように、自分の子のように健全にコードを育てて面倒みないといけませんｗ
27 死ぬはずのプログラムを無理に生かしておいてはいけない
どんなことが起きたのか、それを知るほんのわずかな手がかりさえも残らないのです。
普通ならばダンプが吐かれて状況が記録されるような場合でも、何も残らないのです。彼は「例外に関する情報をユーザの目に触れさせてはならない(NEVER LET THE USER SEE ANE XCEPTION REPORT)」それがUIデザイナーのおきてだ、と言ってきました。
UIデザイナーの言ですからね。きっと顧客からエラーメッセージ/ログばっかりでウザいと抗議されたことがあるんでしょう。。。
だからといって無理やりバグを回避してフォールトトーレラントにしてしまうのも考えものですので、
どういうユーザにどういう使われ方をされてどの程度の頻度でエラーが発生するか、でしょう。
52 「その場しのぎ」が長生きしてしまう
いったん暫定ソリューションができてしまうと、既成事実化するのです。
すでに存在していて、一応役に立っていて、皆に一応受け入れられている。
もしそうだとすれば、その状況を今すぐ変える必要性を誰もあまり感じません。
上の3も参照ですね。あえてバグを作るような修正しなくてもいいじゃん(その分の開発費用を出さなくてもよくなるし)、とか。
そういうことを知っているからこそ、最初にコードを書くときのアルゴリズムの選択は慎重になります。
63 ユーザの操作ミスを防止する
フォーマット間違いのエラーもよく起きます。しかし、たとえば日付のテキストフィールドに"July 29, 2012"と入力されたとして、
これが指定のフォーマット(“DD/MM/YYYY"など)とは違っているからエラーにしてしまうのは理不尽ではないでしょうか。
この例は判断が難しいですね。
ユーザとしては、フォーマットが自由すぎるとかえって不安になるんですよ、本当はどう入力するのが正解なのって聞かれたり。
コーディングにおいても、自由度が高すぎるとあれこういう書き方でもよかったんだっけ？と不安になり結局仕様を確認したりしますし。
84 正しいアルゴリズムとデータ構造を選ぶ
「まずは動かすこと。速くするのはその後でいい」という格言を知っている人は多いでしょう。
局所的な最適化の落とし穴を避けるためには、この格言の心に留めておくことが大切です。
しかし、先の例のようなコードを見ると、「遅くても何でもいいからとにかく動かせ」というマキャベリ的な発想でコードを書いているのではないか、と疑ってしまいます。一般には「良くない」とされているアルゴリズムもありますが、優れたプログラマであれば、そういうアルゴリズムでさえも状況によっては良い結果を生むと知っています。
プログラマーとしてのセンスが問われますね。
なぜそういう書き方にしたのか、コメントをちょろっと書いてメモっておかないと理由を知らない他人(日をおいて見返したときの自分も含めて)から非難されることもあります。