悪態のプログラマAmeba新規登録(無料)悪態のプログラマとある職業プログラマの悪態を綴る。入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。おすすめキャリアブログyasuhoの隠れ家ロマンチックなSEがIT業界を変える。)このブログの読者はこんな本を買っています。>>2010年12月05日(日)質問の答えを書くテーマ:ブログビジネスによくあるシーン。納得してもらう例えば、報告書の類とか、我々の仕事なら設計書のレビューなどもそうだ。ソースコードのレビューも同じである(以下、「ドキュメント」にはソースコードも含むものとする)。上記の流れの後でそのまま終わってしまう人も多いのだが、それはよくない。単純に考えると、質問された内容というのは、「作成したドキュメントから読み取れなかったこと」である。少なくとも聞き手が質問せずにはおられない程度に「重要なこと」なのである。そのため、今後、別の人(たとえば上司のそのまた上司)がこのドキュメントを読んだら、同じ質問をしてくる可能性が高い。質問の機会がなければ誤解されてしまうかもしれない。説明を受けた人ですら、後になってその内容が思い出せなくなって、違う解釈をしてしまうかもしれない。「質問をする人に知識や読解力がないせいだ」と言いたい時もあるだろう。読ませる相手のレベルに合っていないドキュメントは悪いドキュメントである。幼児向けの絵本を漢字ばかりで書いているようなものだ。★ドキュメントの説明で質問があったなら、口頭で説明しておしまいにせず、説明した内容をドキュメントから読み取れるように、追記や修正をしておきたい。ソースコードの場合なら、構造を見直す(リファクタリング)、変数名やクラス名・関数名を見直す、コメントを見直す、といった対応を検討すべきだろう。品質管理のために行うレビューの場合は、レビューアにドキュメントの内容を伝えることが目的ではなく、ドキュメントを良くすることが目的なのだから、なおさらである。誰かに仕事をお願いするときに、「頑張ります」という返事をされるのは好きではない。頑張らないとできないのかと思うと、不安だからだ。できれば、頑張らずに涼しい顔で遂行してくれる人を探したい。頑張るための余力は何かトラブルがあったときなど、いざという時にとっておいて欲しいのである。結果を出すために頑張ってくれるというのなら嬉しいが、それなら黙って頑張って欲しい。近づけるように頑張ります」といった文脈になるだろう。目標に頑張ります」など、具体的な達成内容まで明確にできれば理想的だ。★「あいつはいつも頑張っている」という言葉は、「100以上」を目指して頑張っているのなら褒め言葉である(「仲間の仕事まで手伝っている」とか「自己のスキルアップに取り組んでいる」とか)。目指していつも頑張っているのだとすると、その人は常にトラブルを抱えているか、スケジュールの立て方がおかしいのだろう。いつも頑張っていると、「頑張っている状態」を基準にしてスケジュールを立てるようになってしまう。普通は1週間かかる仕事でも、3日でできると自分自身が勘違いしてしまっている。実際、残業などして頑張ってやるので、何事もなければ3日でできるのだろう。そのような「もともと頑張る前提」のスケジュールでは、それ以上頑張れる余地がないため、トラブルが起きるとどうにもならなくなる。これは個人だけでなく、組織でも同じだ。スタッフがいつも残業したり休日出勤したりして「慢性的に頑張っている組織」は、無理な仕事をどんどん受けてしまう危険性がある。そのうちのいくつかはトラブルが原因で、納期が守れなかったり、品質を落としたりしてしまうだろう。★悪いことに、いつも頑張っている人が、頑張らなくなると、手を抜いているように思われやすい(普通の状態に戻っただけなのに)。それが嫌で、ずっと頑張り続けることになるという悪循環。そんなことにならないためには、「とりあえず頑張ろう」と考えるのではなく、「頑張らずに仕事をするにはどうすればよいか」、「頑張らずにできる範囲はどこまでか」といったことを考える方がよい。トラブルが起こったときなど、本当に頑張るべき時に頑張るのは当然である。そのためにも、「頑張るための余力」を残したスケジュールを立てるようにしたいものである。「低レベルなプログラミング」と聞いて、どういうものをイメージするだろうか。プログラマとそうでない人では、答えが違ってくるのではないだろうか。一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い(たとえばアセンブラのような)言語を使ったプログラミングだとか、直接ハードウェアに命令を送って制御するようなプログラミングのことである。このハードウェアとの「近さ」は測定できる類のものではないが、プログラマ(あるいはその周辺の業界人)は、なんとなく了解していると思う。このブログの「スキルアップのためにラップを剥がしてみる」というエントリで「層」と表現したものにも近いだろう。★もともと「レベル」という言葉は「何らかの基準」を意味しているだけである。それが何の基準であるか、ということは文脈によって変わるので、別段ここでの使われ方が特殊であるというわけではないだろう。何の説明もなく「低レベル」という言葉を使うと、上記のような了解のない人には、「品質が低い」、「スキルが低い」といった侮蔑的な意味に誤解される可能性があるので、気をつけたい。初心者プログラマの中には、そのような誤解をしてしまう人も多いかもしれない。「低レベル・プログラミング」と聞いて、「簡単そう」と思ってしまう人もいるかもしれない。低レベルなプログラミングほど難易度は高レベルだったりもするので、注意が必要である。「データがダーティである」という言い方は一般的だと思うが、私の周囲では伝わらないことも多い。何らかのデータを変更するプログラムにおいて、保存されているデータを直接書き換えるのではなく、データをコピーしてからそのコピーを変更し、最終的に元のデータに書き戻す、という方法をとることがある。このとき、「コピーの方は変更されているが、元データには反映されていない」という状態を「ダーティである」という。ユーザーが画面でデータを編集するようなソフトでは、既存のデータを編集してそのまま終了しようとすると、「変更されています。保存しますか?」といったメッセージを表示するのが一般的だ。このような、データが「ダーティかどうか」という判定を「ダーティチェック」と呼んだりする。データベースで「ダーティリード」という時の「ダーティ」も同じ意味だろう(「汚い」という英語の意味を考えるとこれが語源かも?)。「ダーティ」という言葉を使わなくても、「データが変更されたかどうか」と言えば伝わるのだから、あえて使う必要もない、と思うかもしれない。開発チームの中で、このような、「使わなくてもやっていけるが、使うと便利」というレベルの言葉がどれだけ共有されているか、ということは、円滑なプロジェクトの進行のための要素のひとつである。言葉を共有することの効果は、コミュニケーション面の向上だけでなく、ものの考え方(システム開発であれば「設計思想」など)の共有にまで及ぶことも多く、侮れないものである。実務英語に即した本です。多少勉強になるもっと収録語数をしぼってくれたほうが、個人的にはよかった。リブログ(0)ツイート2008年11月25日(火)サンプルコードで語る難しさテーマ:コーディングプログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。付属しているのに、なんでそんなもの作るんですか?」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。「コーディングスタイルの常識をぶち壊せ」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなことは分かっているだろう。ここでは、「同種の記述を繰り返す時は、複数行にせず、桁位置を揃えて書くと見やすい」と言っているだけである(つまり「表」のようなコードにしろと)。サンプルソースでは、その「同種の記述」の単純な例として、たまたま「2つの文字列リテラルの変数への代入文」が書かれているというだけである。代入文である必要はなく、数値演算でも関数呼び出しでも、何でもよかったはずだ。この何でもいいはずの処理内容(ここでは代入文)に引きずられてしまう読者は意外と多い。プログラマがソースコードを読むということは、普通なら「処理内容を理解する」ということなので、そういう読み方が染みついてしまうのだろう。「ソースはこう読むものだ」という「常識」にとらわれて読み方を変えることができないとも言える。いう意味で、「処理内容以外のことを伝える」ためのサンプルソースを作ることは難しい。★このブログでも、「コードの書き方」を論ずるためにサンプルソースを載せることがあるが、文章を書く以上に頭を悩ませる。「書き方」を見せるだけだから「処理内容」は何でもよい、といっても、リアリティがなければ上記のように読者の気が逸れてしまう。実例(職場で見つけたコード)を載せればリアルではあるが、逆に複雑になりすぎて論点がぼやけたり、一部だけ抜き出しても意味不明になったりする。記事と似た内容の記事も書いたことがある。「あなたにもできること」がそれだ。配列を使った簡単なサンプルソースを載せているだけだが、実はかなり悩んだ結果である。今読み返すと、あまりに説明が短いため、意図が伝わっていないような気もするので、ついでに補足しておこう。コーディングの際、同じような処理を繰り返して書くときには、上に書いた行をコピーして下の行を作り、少しだけ改変していくような書き方をすることが多いと思う。この手のミスを防ぐには、どうすればよいだろうか?最低限必要なことは、自分で書いたソースコードを読み返してチェックすることである。その時、「修正箇所」の桁位置が揃っていた方が、ガタガタと不揃いであるよりもずっとチェックしやすい。視線を縦に真っ直ぐ流せるからだ。コードを印刷してチェックする場合は、指でなぞったり、ペンで印もつけやすい。画面でチェックする場合でも、カーソル(キャレット)を同じ桁位置で縦に動かして記述を追えるので確認しやすい。少なくとも私は、何度もそういう経験をしているので、自然とソースコードの桁を揃えるようになった。記事で「ケアレスBUGの混入が防げるため、メンテナンス性が上が」ると書かれていることと同じだろう。記事では、「桁位置を揃える」というだけでなく、「複数行にまたがらせない」という点も例示されているという意味では、よい記事だと思う。「メリット」の説明がこれだけでは不足だ。「そんなことは誰もが承知している」という前提で書かれているのだろう。プログラマの「常識」だと。ソースを読み返さないプログラマは、意外と多い(記述ミスは動作確認でも見つけられるので)。常識と思っていることも、本当は常識ではないのかもしれない。いう意味でも、「常識をぶち壊す」ということは難しいものである。プログラマ入門用本です。146792位[ジャンルランキング]このブログはジャンルランキングに参加していません。トレンドもっと見る芸能人トップへブログをはじめるたくさんの芸能人・有名人が書いているAmebaブログを無料で簡単にはじめることができます。多くの方にご紹介したいブログを執筆する方を「公式トップブロガー」として認定しております。詳しく見る芸能人・有名人ブログを開設Amebaブログでは、芸能人・有名人ブログをご希望される著名人の方/事務所様を随時募集しております。申し込む「{{entryTitle}}」のリブログ一覧({{entryReblogCnt}}件){{/isError}}{{#isError}}システムエラー{{/isError}}{{entryReblogTitle}}{{entryReblogText}}{{nickname}}{{entryDate}}{{#isNewReblog}}{{/isNewReblog}}{{/list}}{{/isError}}{{#isError}}情報の取得に失敗しました。再読み込みしてください。再読み込み{{/isError}}{{#isDispMoreBtn}}もっと見る{{/isDispMoreBtn}}{{#isMoreError}}情報の取得に失敗しました。再読み込みしてください。再読み込み{{/isMoreError}}。