悪態のプログラマ -11ページ目

悪態のプログラマ

とある職業プログラマの悪態を綴る。
入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。

Joel Spolsky 氏の「Javaスクールの危険 」という記事を読んだ。趣旨としては、従来の「ポインタ」と「再帰」に関する学習は、プログラマを鍛え、不向きな人をふるい落とす効果があったが、最近の Java を主体とする教育では、それができていないといったようなことである(※1)。

ポインタを学ぶということの必要性については、当ブログでも「ポインタという考え方 」という記事に書いた。再帰については、私もそこまで重要視はしていなかったのだが、コンピュータサイエンスの世界では、同様に重要な概念だということだろう。


再帰といえば、以前、以下のようなコードをみつけたことがある。他社から派遣されてきたプログラマが書いたものだ(※2)。

void do() {
  
  // 処理
  ・・・
  if( 処理成功 ){
    return;
  }
  
  // 再試行
  if ( YES == message("失敗しました。再試行しますか?") ){
    do();
  }
}

do() という関数の中から、「再試行」のために do() を再帰的に呼び出している。数回の再試行を行うだけであれば、彼の意図の通りに動作するだろう。しかし、プログラムというのは、動けばいいというものではない。

彼は、おそらく「再帰」という概念自体を持たぬまま、いや、持たぬが故に、このような変なコードを書いてしまったのだろう。それ以前に、「関数」の概念が十分に理解できておらず、「処理に付ける名前(=ラベル)」と同じ程度にしか考えていないことが窺える。少なくともプログラマとして他社に派遣できるようなレベルではないはずなのだが・・・。


ポインタや再帰がプログラマにとっての試練だとすれば、それらはそのまま採用試験にも使えるということである。実際、Joel Spolsky 氏は、プログラマの面接にポインタと再帰の質問を行っているようだ(「採用面接ゲリラガイド(version 3.0) 」)。

私の会社でも、そのような面接を行っていれば、上記のようなコードを書いたような派遣プログラマを雇うことはなかったのだろうが・・・。





※1
「Joel on Software」の邦訳版 より。CodeZine のメールマガジン(CodeZine News 2006-11-15)で紹介されていた記事。ポインタと再帰の話の他にも、オブジェクト指向プログラミングが「凡庸なプログラマをふるい落とすのには簡単すぎる」という意見にも共感。数年前には、古参のプログラマの中に「オブジェクト指向が分からない」という人がごろごろいたが、それは難しいからではなく、単に新しいことを覚えようとしなかっただけなのだ。

※2
簡単な仕事を探す難しさ 」に登場するBさんである。実際には、Java のコードだった。



■関連記事
ポインタという考え方
簡単フレームワーク・プログラミングの罠
プログラミングは体で覚えろ
プログラマは誰でも同じ?
続・プログラマは誰でも同じ?



Joel on Software
Joel on Software
posted with amazlet on 06.11.20
Joel Spolsky 青木 靖
オーム社
売り上げランキング: 7357
おすすめ度の平均: 4.5
3 プログラミングチームを率いるときに
4 優秀な開発者がいつも考えていること
4 批判的精神を持って読むべし




新人プログラマに仕事をしてもらう時に悩むことがある。それは、技術的な内容について、どこまで細かく指示するかということだ。経験のあるプログラマなら、仕様を伝えるだけで済むところでも、初心者プログラマの場合には、実装方法(プログラムを書く際の細かい設計)まで教えてやらなければならないことも多い。

とにかく早く仕事を片付けたいなら、具体的な実装方法をズバリ教えてやった方がよい。彼ら自身に考えさせていたら、いつできるか分からないし、不適切なものができて、作り直しが発生するリスクも高いからだ。

しかし、教育という観点では、簡単に「答え」を教えないほうがいい。プログラミングでは、ソースコードを書くことよりも、実装方法を考えることの方が重要だからだ。初心者には、少しでも多く、その「考える」という経験を積んでもらう必要がある。


具体的にどこまで教えるかということは、個人の能力や仕事の内容、プロジェクトの状態にもよるので、一概には言えない。実装の方針だけを伝えて細部は考えさせる、あるいは、あらかじめ関数やクラスの「枠」だけを作ってやってから中の処理を実装させる、というように、中間的な指示を出すことが多いだろうか。スケジュールに全く余裕がないときには、実装方法自体を教えることもあるが、そのときには、なぜそのような実装が良いのかということも、同時に教えてやる必要がある。

新人に指示を出すリーダー的な立場の人はもちろんだが、彼らから技術的な質問をされる周囲の先輩達も、彼らの勉強のために、こうした「気遣い」をしてやったほうがいいだろう。


一方で、新人の側としては、常にそうした教育的指導が行われることを期待してはいけない。短納期、人手不足のプロジェクトが多い中、社員教育よりも開発効率やリスク回避を優先せざるをえないという現実もある。

誰かに質問をして、答えを教えてもらった場合でも、どうしたらその答えに到達できるのか、ということは必ず確認すべきだ。そして、自分だけでその答えに到達できなかったのはなぜか、ということもよく考えてみることである。





■関連記事
「人に頼れる」技術者の話
プログラミングは体で覚えろ



なぜ、「できる人」は「できる人」を育てられないのか?
吉田 典生
日本実業出版社
売り上げランキング: 5136
おすすめ度の平均: 4.5
4 まずは心構えの問題
2 「できる人」が注意しなければならない点は共感したが・・・
4 コミュニケーションが重要


リーダーのためのとっておきのスキル
石田 淳 小阪 裕司
フォレスト出版
売り上げランキング: 741
おすすめ度の平均: 4.5
5 人の上に立つ人のための本
5 なかなか味わいのある本でした
5 サラリと読めて、ズシリと重い


あるプログラマが、データベースに保持しているデータを独自形式のファイルに出力するプログラムを作った。処理自体は単純なのだが、項目数が多いため、動作確認が大変だった。彼は、全ての項目が正しく出力されていることをチェックするために、Excel を使うことにした。

まず、プログラムの入力データと出力データを、Excel のシート上に2列に並べた(※1)。そして、その次の列には、入力データと出力データのセルを比較する「数式」を書いた。両方のセルが同じ値なら "○"、違う値なら "×" を表示する数式である。

プログラムの動作が正しければ、シートの全ての行に "○" が表示されるはずだ。彼は、この方法で単体テストを完了させた(※2)。


しかしである。その後の結合テストで、このプログラムにバグが見つかった。1つの項目について、入力元の項目名が間違っていたのである。

当然、「なぜ単体テストで発見できなかったのか?」と問われた。そこで、単体テストで確認に使われた Excel ファイルを開いてみると、該当の項目にはちゃんと "×" がついていた。

つまり、彼は大量の "○" の中にある1つの "×" を見逃してしまったのである。Excel の「数式」で自動的にチェックしているということに安心して、結果の確認が疎かになってしまったのだ。



彼がデータの確認に Excel を使ったのはよい選択だ。しかし、項目ごとに "○" と "×" を表示しただけでは、結局は、その数だけ人間の目でチェックしなければならない。

人的ミスを減らすには、人間の仕事を減らすことだ。この例では、更に全項目の "×" をカウントする数式を追加することで、人間が見るべきところを1箇所に集中させることができる。項目が百個だろうが千個だろうが、人間は1つのセルを見ればよい。どうせ Excel を利用するのなら、そこまで「設計」して欲しかった(※3)。

ただ Excel の数式を書くというだけのことではあるが、これも立派なソフトウェアによるソリューション(問題解決)である。システム開発は問題だらけなので、問題解決のための「ネタ」には困らない。プログラマには、常に業務要求の分析力やソフトウェアの設計力を鍛えるための機会が与えられていると言っていいだろう。それを生かせるかどうかは、自分次第である。




※1
本当はデータを「2行」(つまり「横」)に並べたかったのだが、Excel の最大列数(256 列)を超えてしまうため、ここでは「縦」に並べた。

※2
本来なら、別の人間によるテスト記録(ここでは Excel シート)のチェックをもって「完了」とすべきだった。しかし、このケースでは、それができていなかった。

※3
もちろん、「数式」を間違えていないという前提であるが。



■関連記事
面倒くさいこと
プログラミングは体で覚えろ
テストを簡単にし、品質もアップする方法
気の利いたプログラムは顧客満足度を上げ、開発工数を下げる



Excelマニアックス!―誰も知らない、セルの裏側。
井上 孝司
ラトルズ
売り上げランキング: 96,872
おすすめ度の平均: 5
5 Excel生誕20周年


問題解決プロフェッショナル「思考と技術」
齋藤 嘉則 グロービス
ダイヤモンド社
売り上げランキング: 816
おすすめ度の平均: 4.54
5 平易だが奥は深い
4 問題解決の「思考」と「技術」の基本が分かる。
4 これで理論と実践をつなげられる!
プログラマに、未経験のプログラミング言語でコーディングしてもらうと、微妙に違和感のあるコードを書いて来ることがある。

Java のコードを見ていると、このようなメソッドがあった。

String GetName();

VC (Visual C/C++) や VB (Visual Basic) を専門にしていたプログラマが書いたようだ。VC や VB では、関数名の先頭は大文字になるのが一般的である。しかし、Java では小文字になるのが普通なのだ。Java でも文法的には間違いではないので、コンパイルは通る。しかし、ここは慣例に従って、getName() に直すべきだろう。

原則として、自分だけが異なるコーディングルールを使うべきではない。可読性が落ちるし、コードに対して何らかの処理(例えば検索や置換のような)をしたい場合に、足かせになることもある(特に、上記のような例では、JavaBean のプロパティとして成立しないという問題もある)。

開発チームで細かいルールが決められていたり、プログラミング言語の提供元などからガイドラインが出されているような場合は、もちろん、それに従うべきだ。そして、そのような厳密なルールがない場合でも、慣例的なルールに従うべきである。


初めてのプログラミング言語を使うとき、「慣例的なルール」をどうすれば知ることができるだろうか? 最も簡単なのは、その言語が標準で持っているライブラリを見ることだ。

一般に、プログラミング言語は、文法とライブラリ(※1)から成っている。そして、ライブラリには、文法に規定されていないような慣例的なコードの書き方が反映されている(※2)。ライブラリのソースコードが公開されている場合は、それを読めば大いに参考になるだろう。また、公開されていない場合でも、関数やクラスなどのネーミングルールを知ることはできる。


それほど難しいことではないのだが、意外とできていないプログラマも多い。それどころか、確信犯的に他の言語の(あるいは我流の)書き方を貫こうとする人さえいるようだ(参考リンク:『Cプログラミング診断室 第8章』 Pascalが好き ・・・これはかなり酷い例だ)。

このブログで何度も主張していることだが、プログラミングという仕事は、ただ「動くプログラム」を書くだけの仕事ではない。可読性や保守性の高いソースコードを書かなければ、プロの仕事としては認められない。

プログラミング言語の文法はプログラムを動かすための最低限のルールにすぎない。文法を守れば何を書いてもいいというわけではないのである。それは、実生活で「法を守れば何をやってもいいというわけではない」のと同じである。




※1
組み込みの関数やクラス。最近は「フレームワーク」を持つ言語も多いが、ここではそれも「ライブラリ」に含めよう。

※2
逆に、一般のプログラマがライブラリの書き方を真似するので、それが標準的なルールになると言ったほうがいいのかもしれないが。



■関連記事
誰のためのコード?
まずは丁寧なプログラミングを
プログラムは二度書け
チームのために自分のスタイルを曲げる覚悟
プログラムに操られた男



超図解 Javaルールブック
超図解 Javaルールブック
posted with amazlet on 06.10.29
電通国際情報サービス開発技術部 エクスメディア
エクスメディア
売り上げランキング: 70,864
おすすめ度の平均: 4.33
4 ルールは早めに身につけたほうが良い
4 Javaを再利用化しやすくする為の工夫
5 Javaプログラマ必見!!


超図解 VB.NETルールブック
電通国際情報サービス開発統括部 エクスメディア
エクスメディア
売り上げランキング: 83,833
おすすめ度の平均: 4
4 VB.NETプロジェクトの管理テンプレート

ずいぶん昔のことである。私はA社のプロジェクトに、「協力会社」の SE として参加していた。そのA社の人に、

「あなたの会社ではどんな新入社員にどんな研修をされているのですか?」

と聞かれたことがある。私はちょっと焦って、

「さぁ。中途採用だったもので、研修は受けていないんですよ」

と答えた。

しかし、それは嘘だった。なぜそんな嘘をつくかって?

そこでは、私は表向きは協力会社であるB社の社員ということになっていたが、実はそうではなかった。自分の会社からまずB社に派遣され、そこから更にA社に送られていたのだ。当然、B社の新人研修の内容など全く知らなかった。


SE やプログラマが、他社に派遣(出向)されることはよくあることである。酷いときには、多重派遣が行われることもあるようだ(※1)。

私のケースでは、A社のプロジェクトに参加してはいたが、B社の管理下で動いていたので、多重派遣ではなかったはずだ。にもかかわらず、B社から「社員のふり」をするように言われていた(※2)。何だか知らないが、大人の事情があったのだろうか。

モノ作りにしか興味のなかった私は、そんなことはどうでもいいと思っていた。しかし、おかげで、初対面の人に会う度に「名刺を切らしておりまして」などと言って恐縮する羽目になってしまったのである(※3)。


冒頭の会話を聞いていたB社の若手社員は、

「中途採用だなんて、よく咄嗟に答えられましたねぇ」

などと感心していた。

技術者にも、そんな会話能力が必要なことがあるという話である。まぁ、嘘が上手いからといって、褒められたものではないのだが。





※1
多重派遣は違法だが、この業界では当り前に行われているようだ(参考リンク: IT業界のタブー「偽装請負」に手を染めてませんか(ITpro) )。技術者の不勉強が問題だという指摘もあるが、他業種の「労働者」はちゃんと勉強しているのだろうか?

※2
法律的なことはよく分からないが、A社が「B社」という社名に対して金を払ったのだとすれば、詐欺罪になるかもしれない。もっとも、B社の社員以上の仕事をすれば、訴えられる筋合いはないとも思うが・・・。いずれにせよ、気持ちのいいものではないので、こういうくだらない指示はやめて欲しい。

※3
聞くところによれば、偽の名刺を持たせる会社もあるようだ。



■関連記事
プログラマの出向事情





平気でうそをつく人たち―虚偽と邪悪の心理学
M.スコット ペック M.Scott Peck 森 英明
草思社
売り上げランキング: 17,872
おすすめ度の平均: 4
4 怠惰とナルシシズムからの脱却⇒個人の成長
5 国家としての悪に対する方策が「徴兵制」。驚くが納得。
2 内容にどうしても首肯できない部分あり