悪態のプログラマ

このブログの読者はこんな本を買っています。
このブログの読者を雇いたい方は画面右をご覧ください。
プログラマ向けオリジナルグッズを販売しています → 　UPSOLD店 / ClubT店

2009年05月05日(火)

低レベルなプログラミング

テーマ：専門用語

「低レベルなプログラミング」と聞いて、どういうものをイメージするだろうか。プログラマとそうでない人では、答えが違ってくるのではないだろうか。

一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。

しかし、プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。つまり、「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い（たとえばアセンブラのような）言語を使ったプログラミングだとか、直接ハードウェアに命令を送って制御するようなプログラミングのことである。

このハードウェアとの「近さ」は測定できる類のものではないが、プログラマ（あるいはその周辺の業界人）は、なんとなく了解していると思う。このブログの「スキルアップのためにラップを剥がしてみる」というエントリで「層」と表現したものにも近いだろう。

★

もともと「レベル」という言葉は「何らかの基準」を意味しているだけである。それが何の基準であるか、ということは文脈によって変わるので、別段ここでの使われ方が特殊であるというわけではないだろう。

しかし、何の説明もなく「低レベル」という言葉を使うと、上記のような了解のない人には、「品質が低い」、「スキルが低い」といった侮蔑的な意味に誤解される可能性があるので、気をつけたい。

また、初心者プログラマの中には、そのような誤解をしてしまう人も多いかもしれない。あるいは「低レベル・プログラミング」と聞いて、「簡単そう」と思ってしまう人もいるかもしれない。しかし、低レベルなプログラミングほど難易度は高レベルだったりもするので、注意が必要である。

応援のクリックお願いします →

CPUの創りかた

posted with amazlet at 09.05.05

渡波郁
毎日コミュニケーションズ
売り上げランキング: 1745

おすすめ度の平均:

基本的な電子回路でCPUができる

趣味の本だよねぇ

読んでもすぐには理解できませんが、他のＣＰＵ本はもっと理解できません

ノイマン型コンピュータを自作する・・・名著かも

CPUの超基本構造

Amazon.co.jp で詳細を見る

真・コンピュータ用語辞典 (ホームページブックス)

posted with amazlet at 09.05.05

tell‐a‐lie
キルタイムコミュニケーション
売り上げランキング: 377785

Amazon.co.jp で詳細を見る

同じテーマの最新記事

記事URL コメント(14) ペタ

2009年03月22日(日)

ダーティなデータ

テーマ：専門用語

「データがダーティである」という言い方は一般的だと思うが、私の周囲では伝わらないことも多い。

何らかのデータを変更するプログラムにおいて、保存されているデータを直接書き換えるのではなく、データをコピーしてからそのコピーを変更し、最終的に元のデータに書き戻す、という方法をとることがある。このとき、「コピーの方は変更されているが、元データには反映されていない」という状態を「ダーティである」という。

たとえば、ユーザーが画面でデータを編集するようなソフトでは、既存のデータを編集してそのまま終了しようとすると、「変更されています。保存しますか？」といったメッセージを表示するのが一般的だ。このような、データが「ダーティかどうか」という判定を「ダーティチェック」と呼んだりする。

また、データベースで「ダーティリード」という時の「ダーティ」も同じ意味だろう（「汚い」という英語の意味を考えるとこれが語源かも？）。

★

「ダーティ」という言葉を使わなくても、「データが変更されたかどうか」と言えば伝わるのだから、あえて使う必要もない、と思うかもしれない。

しかし、開発チームの中で、このような、「使わなくてもやっていけるが、使うと便利」というレベルの言葉がどれだけ共有されているか、ということは、円滑なプロジェクトの進行のための要素のひとつである。

また、言葉を共有することの効果は、コミュニケーション面の向上だけでなく、ものの考え方（システム開発であれば「設計思想」など）の共有にまで及ぶことも多く、侮れないものである。

応援のクリックお願いします →

■関連記事
・曖昧言葉

2009-'10年版 [最新] パソコン・IT用語事典

posted with amazlet at 09.03.22

堀本勝久大島邦夫
技術評論社
売り上げランキング: 35830

Amazon.co.jp で詳細を見る

IT英語のナゾ

posted with amazlet at 09.03.22

豊沢聡緒方孝文
カットシステム
売り上げランキング: 261531

おすすめ度の平均:

実務英語に即した本です。

多少勉強になる

もっと収録語数をしぼってくれたほうが、個人的にはよかった。

この著者は語学もコンピュータも詳しい

IT業界人に限らず中級以上の英語学習者にもお勧め!!

Amazon.co.jp で詳細を見る

記事URL コメント(8) ペタ

2008年11月25日(火)

サンプルコードで語る難しさ

テーマ：コーディング

プログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。この課題に対して「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか？」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。

これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。

★

CodeZine の「コーディングスタイルの常識をぶち壊せ」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。

この記事の２つ目のサンプルソースについて、「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなことは分かっているだろう。

ここでは、「同種の記述を繰り返す時は、複数行にせず、桁位置を揃えて書くと見やすい」と言っているだけである（つまり「表」のようなコードにしろと）。サンプルソースでは、その「同種の記述」の単純な例として、たまたま「２つの文字列リテラルの変数への代入文」が書かれているというだけである。もちろん、代入文である必要はなく、数値演算でも関数呼び出しでも、何でもよかったはずだ。

しかし、この何でもいいはずの処理内容（ここでは代入文）に引きずられてしまう読者は意外と多い。プログラマがソースコードを読むということは、普通なら「処理内容を理解する」ということなので、そういう読み方が染みついてしまうのだろう。「ソースはこう読むものだ」という「常識」にとらわれて読み方を変えることができないとも言える。

そういう意味で、「処理内容以外のことを伝える」ためのサンプルソースを作ることは難しい。

★

このブログでも、「コードの書き方」を論ずるためにサンプルソースを載せることがあるが、文章を書く以上に頭を悩ませる。「書き方」を見せるだけだから「処理内容」は何でもよい、といっても、リアリティがなければ上記のように読者の気が逸れてしまう。実例（職場で見つけたコード）を載せればリアルではあるが、逆に複雑になりすぎて論点がぼやけたり、一部だけ抜き出しても意味不明になったりする。

実は、上記の CodeZine の記事と似た内容の記事も書いたことがある。「あなたにもできること」がそれだ。配列を使った簡単なサンプルソースを載せているだけだが、実はかなり悩んだ結果である。今読み返すと、あまりに説明が短いため、意図が伝わっていないような気もするので、ついでに補足しておこう。

コーディングの際、同じような処理を繰り返して書くときには、上に書いた行をコピーして下の行を作り、少しだけ改変していくような書き方をすることが多いと思う。が、そこで、改変し忘れるというミスをしたことはないだろうか？　この手のミスを防ぐには、どうすればよいだろうか？

最低限必要なことは、自分で書いたソースコードを読み返してチェックすることである。その時、「修正箇所」の桁位置が揃っていた方が、ガタガタと不揃いであるよりもずっとチェックしやすい。視線を縦に真っ直ぐ流せるからだ。

コードを印刷してチェックする場合は、指でなぞったり、ペンで印もつけやすい。画面でチェックする場合でも、カーソル（キャレット）を同じ桁位置で縦に動かして記述を追えるので確認しやすい。少なくとも私は、何度もそういう経験をしているので、自然とソースコードの桁を揃えるようになった。

★

このようなソース・チェック時のメリットは、CodeZine の記事で「ケアレスBUGの混入が防げるため、メンテナンス性が上が」ると書かれていることと同じだろう。CodeZine の記事では、「桁位置を揃える」というだけでなく、「複数行にまたがらせない」という点も例示されているという意味では、よい記事だと思う。

しかし、「メリット」の説明がこれだけでは不足だ。「そんなことは誰もが承知している」という前提で書かれているのだろう。つまり、プログラマの「常識」だと。しかし、ソースを読み返さないプログラマは、意外と多い（記述ミスは動作確認でも見つけられるので）。常識と思っていることも、本当は常識ではないのかもしれない。そういう意味でも、「常識をぶち壊す」ということは難しいものである。

応援のクリックお願いします →

プログラマの完全常識開発者が知っておくべきプロの知恵

posted with amazlet at 08.11.25

矢沢久雄
技術評論社
売り上げランキング: 175375

おすすめ度の平均:

コンピューターを舞台裏から見よう

ソフトウェア業界で働く事を考えている人は読んでおいた方が良い。情報処理技術者試験対策としても。

プログラマ入門用本です。

プログラマの完全常識

Amazon.co.jp で詳細を見る

Code Reading―オープンソースから学ぶソフトウェア開発技法

posted with amazlet at 08.11.25

トップスタジオまつもとゆきひろ平林俊一鵜飼文敏
毎日コミュニケーションズ
売り上げランキング: 14938

おすすめ度の平均:

コードリーディングのイロハ＆必要な知識・技術の全装備

Code completeと併せて読むとよい

着眼点は良いと思う

意外なほどに教科書的な内容

ホップ・ステップ・ジャンプ

Amazon.co.jp で詳細を見る

記事URL コメント(9) ペタ

2008年10月26日(日)

できること、できないこと

テーマ：見積

「こういうことができるか？」といった質問を受けることがある。質問する方は簡単なのだが、答えるのは難しい。何かが「できる」ためには、いろんな要因があるからだ。

・理論的にできる／できない
・技術的にできる／できない
・時間的にできる／できない
・費用的にできる／できない
・感情的にできる／できない

など。

ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か？」という質問があったとする。それが、システムの仕様として矛盾がなく、実装方法が頭に浮かぶようなら、「できます」と答えてしまう。

しかし、ほとんどの仕事には「いつまでに（納期）」「いくらで（予算）」など、他の条件があるはずだ。質問者と回答者の間で、そうしたことが全く話題にならなかったとしたら、誤解が生じている可能性がある。回答者は多忙で寝る時間もない状態なのに、質問者は「頼んだらすぐやってくれるのだろう」と思ってしまうかもしれない。

★

ついでに書いておくと、「できるか？」という質問の答えは「はい」か「いいえ」である。上記のように「条件」によって答えが変わる場合があっても、結局は「はい」か「いいえ」だ。

ところが、「できるか？」と聞かれて「がんばります」と答える人がいる。それは、できるの、できないの？　がんばったらできるの？　できないけどがんばるの？

いずれにせよ、できない可能性があるということなので、リスクを考えると、「がんばります」＝「できない」と見なすしかない。

しかし、これを「できる」とみなす人もいて、困ってしまう。できる前提でスケジュールを立てて、結局は遅れてしまう。

その仕事の成果として最低限必要な部分を 100％とすると、「できるか？」という質問に対しては、その 100％の仕事ができるかできないかを明確に答えるべきである。「がんばる」という言葉を使うとしたら、更にそれ以上の成果、110％、120％を目指す場合にしか使うべきでない。

★

プロジェクトでスケジュールを立てる場合、どの仕事を誰がどの期間で行うのか、ということを組み合わせていく。リーダーから各作業者に「できるか？」という質問がなされる場合も多いだろう。この際、各人の「見積能力」が重要なことは言うまでもないのだが、コミュニケーションについても注意が必要、という話である。

応援のクリックお願いします →

本当に使える見積もり技術―ソフトウエア開発を成功に導く

posted with amazlet at 08.10.26

初田賢司
日経BP社
売り上げランキング: 20625

おすすめ度の平均:

FP法を詳説した良書

ズバリ良書だと思います

見積りの全体構造

ファンクションポイント法の使いこなし方

Amazon.co.jp で詳細を見る

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS)

posted with amazlet at 08.10.26

田中淳子
日経BP社
売り上げランキング: 17930

おすすめ度の平均:

もっと早く、この本のことを知っていれば・・・

コミュニケーションの大切さを実感！

SE以外の人にもお勧め！

速効性は高いですが…

図解・企業論文の書き方の著者の読後感想

Amazon.co.jp で詳細を見る

記事URL コメントペタ

2008年09月27日(土)

コピー指向プログラミング

テーマ：コーディング

以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。

そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。

アプリケーションに固有の「業務ロジック（ビジネスロジック）」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想である。これには、開発期間の不足や業務面・技術面でのスキル不足など、多くの問題があるが、最もやっかいなのは、多くのプログラマがコピー・プログラミングを好むということである。

あるプロジェクトで共通機能（基底クラス）を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。これには「プログラマの管理がうまくいっていない」という指摘もできる。しかし、それ以前に、プログラマに「コピー・プログラミングへの抵抗感がない」ということが問題なのである。

実際、多くの職業プログラマを自由にしておくと、むしろ好んでコピー・プログラミングを行うようである。みんなコピー・プログラミングが大好きなのだ。

★

たしかに、チーム開発で共通化をしようと思うと、他のメンバーと相談して仕様を決めたり、あるいは他のメンバーの作った複数のソースを変更したりと面倒なことは多い。そういう役割の人（「共通チーム」などと呼ばれる）ならともかく、単なる「一機能の担当者」であるプログラマが、共通化のためにそこまでの労力を払うことは、まずないだろう。

コピー・プログラミングなら、誰にも気兼ねすることなく、自分の担当機能を作ることができる。多くの職業プログラマにとっての最優先課題は「自分の担当機能を動くものに仕上げること」であって、「ソースコードが美しいかどうか」などは二の次なのである。

★

私はこれまでコピー・プログラムには何度も痛い目にあってきたので、自分のプロジェクトでは、いかにして共通化を徹底するか（コピーさせないか）、ということに頭を悩ませてきた。しかし、多くのプログラマがコピーが大好きなのだとすれば、それを前提とした開発方法を考えるのも一興である。たとえば、以下のようなことだ。

あらかじめ完成度の高い「コピー元」を用意する

コピー元を品質の高いコードに集中させることで、「バグのコピー」や「似て非なるバージョンの散在」を防ぐ。

「コピーされたもの」が分かるようにする

例えば、コピー元のコードに特殊なコメントを埋め込む（もちろん、コピー先でも消さないでおく）などして、後からコピー先を検索しやすくする。これは、不具合修正や仕様変更などの際に、影響範囲（全てのコピー先）を特定しやすくするためである。

コピーしたコードは可能な限り変更しない

まず、コピー元はなるべく変更しなくてすむように作る。例えば、コピー先で関数名などがぶつからないように、ネーミングルールを作る。また、コピー先で無駄に変更することも禁止する。動作に影響のないからといってコーディングスタイルを自分流に変えたりしない。コピー先の記述の変更量が少なければ、コピー先の特定がしやすくなるし、記述の統一による可読性の向上にも繋がる。

あるいは、開発ツールの助けにより、コピー・プログラミングの品質向上が見込めるかもしれない。既存のツールでも、例えば、Visual Studio 等の統合開発環境で、アプリケーションの雛形を作ってくれる「ウィザード」や、「よくあるコード」を挿入してくれる「コードスニペット」は、「コピー指向」であると言ってもいいだろう。ソースコードを現在のようなテキスト形式のみで保存することに拘らなければ、他にも色々な対策はできそうだ。例えば、どのコードがどこへコピーされたか、ということをエディタが記録してくれれば、後から追跡することが容易になるだろう。

★

私も「同じことを何度も書くべきではない」という考え方を変える気はない。しかし、同じプログラマといっても、プログラミングについて誰もが同じように考えているわけではない。むしろ自分のようなプログラマは少数派なのかもしれない。そう考えると、日々の「悪態」も少なくなってくるのである。

応援のクリックお願いします →