1 | 2 | 3 | 4 | 5 |最初 次ページ >>
2008年02月02日(土)

車輪を発明しようとする前に

テーマ:プログラマの心得

プログラミングをしていて、何か機能が必要になったとき、「こういう機能は既に誰かが作っているのではないか」と考えてみることは重要である。そういう発想がないと「車輪の再発明」をしてしまう。何でも自作しないと気がすまない人もいるが、既に安定して動くコードやライブラリがあるのなら、それを流用した方が効率がよいことは言うまでもない(プログラミング自体の勉強が目的なら別だが)。



もちろん、事前に、既存のコードやライブラリを探す場合と自作する場合とで、どちらが時間が掛かりそうかを判断する必要がある。


そのためには、自分のプログラミング能力と、調査能力を把握しておかなければならない。調査能力については、ネットの「検索力」も重要だが、周囲の人や掲示板等への「質問力」なども影響する。


そして、もっと重要なのは、探そうとしている処理のニーズ(一般性と言ってもいい)を見極めることだ。多くの人が必要としそうな処理ならすぐに見つかるが、限られた人しか必要としないようなものは見つからない。当り前のことだが、その境界がうまく見極められない人もいる。


自分で判断がつかない時は、制限時間を決めて探してみて、時間内に見つからなければ自作する、という方法を取ることもできる。



次に、品質の判断が必要である。見つけたプログラムが信頼できるかどうか、ということである。ソースコードの記述内容の確認や動作を確認するのはもちろんだが、他の人がどの程度利用しているか、その評価はどうか、といった利用実績に関する情報は大きな判断材料となる。


また、配布元の Web サイトにメンテナンス情報やサポート掲示板などがあれば、その情報が参考になる。そういったものがなくても、作者が技術的な内容の文章を公開しているようなら、(たとえそれが必要としているプログラムとは関係のない情報であっても)その内容から、ある程度、技術レベルの判断ができるだろう。



「車輪の再発明」は、新しいプログラミング言語を使う場面でも起こりうる。最近は、言語の標準機能が充実しすぎて、その全てを把握することが困難になってきているからだ。「こういう機能ぐらい、標準で付いてるだろう」といった見当をつけることができなければ、標準の機能まで自作してしまいかねないのである。


この問題については、事前にその言語のリファレンス等にざっと目を通しておくと、かなり改善する。詳細な仕様まで覚える必要はなく、「そういえば、こういう機能は標準で用意されていたような・・・」という程度に思い出せれば十分だ。詳細は、本当に必要になった時に調べればよい。


インターネットやオンラインヘルプは必要な情報をピンポイントで調べるには向いている。しかし、どんな機能があるのかという観点で全体を眺めておきたいような場合には、本の形の方が向いている。新しい言語を学ぶ場合には、標準ライブラリ等の機能を網羅したリファレンス系の書籍が一冊あるといいだろう。









頭を使って探せ
ソースコードの盗み方
簡単コピー・プログラミングの罠
プログラミングの入門書は何が良いか?




Boost C++Librariesプログラミング 第2版
稲葉 一浩
秀和システム (2007/07)
売り上げランキング: 22671
おすすめ度の平均: 4.0
4 boostを初めて使う方、既に使用している方どちらも持っていて損はありません


Jakarta Commons クックブック―Javaプロジェクト必須のレシピ集
ティモシー・M. オブライエン Timothy M. O’Brien 長瀬 嘉秀 テクノロジックアート
オライリージャパン (2005/08)
売り上げランキング: 140918
おすすめ度の平均: 4.5
4 分かりやすい
4 まずは目次を見てから
5 「ツチブタ」本として、広く読まれてほしい一冊です
AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2008年01月06日(日)

スキルアップのためにラップを剥がしてみる

テーマ:プログラマの心得

仕事で会計関連のバッチ処理を設計しているところなのだが、機能のほとんどが数値を操作するだけのいわゆる業務ロジック(ビジネスロジック)なので、ちっとも面白くない。そういえば、WEB+DB PRESS Vol.38 の特集に、「"業務ロジックしか書きたくない人" のための書かない技術」というタイトルを見て、違和感を感じた記憶がある。


もちろん、このタイトルの意味は理解している。「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似たようなものになりがちなので、ある程度は汎用的な仕組みでの対応が可能だ。システム開発の効率化を考えるとき、業務ロジック以外の部分の汎用性を高めて「書く量」を減らすというのは重要なことである。そういう意味で、「業務ロジックしか書きたくない」というのは自然な話である。


しかし、純粋な意味で「書きたいか、書きたくないか」と問われれば、私は業務ロジックをあまり書きたいとは思わない。ほとんどの場合、顧客の業務内容に興味は沸かないのである(もちろん例外はあるが)。むしろ、業務ロジック以外の部分を書くほうが面白い。例えば、そのシステム専用のアプリケーション・フレームワークや共通ライブラリを作ったりするようなことである。開発プロジェクトの中で、そういう仕事をするメンバーを「共通チーム」と呼んだりするが、そういったチームとして働く時の方が楽しい。



ある程度大きな規模のシステム開発では、「共通チーム」が専用のフレームワークを作り(あるいは既存のものを拡張し)、他のメンバーはその仕組みの中で動作する業務ロジックを書いていく、という形をとることが多いだろう。


つまり、多くのプログラマにとって、フレームワークは使うもの(使われるもの?)であり、作るものではない。以前、「簡単フレームワーク・プログラミングの罠 」にも書いたが、このことは、プロジェクトの効率化という意味では好ましくとも、プログラマのスキルアップという意味では好ましくない。


業務ロジックだけを書いていたのでは、多くのシステムで必要なはずの基礎的な技術が身につかないからだ。例えば、データベースへの接続方法が分からないとか、適切な文字コードの変換方法が分からないといったことが起こる。ずっと業務ロジックだけを書いて生きていければいいのかもしれないが、現場ではそれ以上のことが求められることも多く、あわてて勉強するような人もいる。



コンピュータの世界は、問題を簡単にするための仕組みが積み重なって層を成しているように見える。ある「層」は、下の層にある複雑な問題を隠蔽する(プログラマ流に言えば「ラップ(Wrap)」する)ことで、機能を簡単に利用できるようにしている。業務ロジックだけを書く人が、フレームワークの中身を知る必要がないのと同じように、フレームワークを書く人も、言語の処理系(コンパイラやインタプリタ、VM など)の実装内容まで知る必要はない。こうした階層構造は、アプリケーションから OS、ハードウェアの領域に至るまで、幾重にも積み重なっている。技術者が効率的に分業できる仕組みになっているというわけである。


複雑化した現在のコンピュータについて、一人の人間が全ての階層について理解するのは難しい。しかし、自分のスキルを今以上に伸ばそうと思うなら、自分が今立っている「層」のひとつ下ぐらいは覗いてみることも必要だろう。端的に言えば、自分がいつも呼び出している「共通関数」のソースコードを読んでみることである。


それを面白いと感じないなら、なかなかできないことではあるが。








■関連記事
簡単フレームワーク・プログラミングの罠
頭を使うために頭を使う時代
最低限の道具でどこまでできるか
面白いプログラムを作ろう
嬉しいこと




WEB+DB PRESS Vol.38
WEB+DB PRESS Vol.38
posted with amazlet on 08.01.06
WEB+DB PRESS編集部
技術評論社 (2007/04/24)
売り上げランキング: 128319


開発の現場 特別版 vol.001 The 実装技術!
SE編集部
翔泳社 (2007/03/17)
売り上げランキング: 57633
おすすめ度の平均: 3.0
3 総集編

AD
いいね!した人  |  コメント(5)  |  リブログ(0)
2007年11月26日(月)

えいやぁと眉を引く話

テーマ:プログラマの心得

「えいやぁ」という言葉がある。単なる掛け声ではなく、「思い切って」とか「勢いにまかせて」といった意味のいわゆる「オトナ語」だ。「えいやぁで決めちゃいましょう」といった具合に使われる。「ほぼ日刊イトイ新聞」の「オトナ語の謎。」では、「えいやっ」と紹介されているが、私の周りでは、どういうわけか、その意味とは裏腹に「えいやぁ」と勢いなく発音される場合が多い気がする。

実際にどう使われるかというと、例えば、開発工数の見積(あるいはスケジューリング)をするようなときだ。開発工数なんてやってみなきゃわからないというのが現実なので、結局のところ、えいやぁと気合で決めてしまう。あるいは、ユーザー要件が決まらないとき。無理やり期限を設定してプレッシャーをかけ、顧客の責任者にえいやぁと決めてもらったりする。



こういうと、いいかげんな印象を受けるかもしれないが、この「えいやぁ」というのは、ある程度必要なものである。「えいやぁ」ができないプロジェクトでは、決めなければならないことがいつまでも決まらない。「もう、どっちでもいいから誰か決めてくれよ」と言いたくなるような状況が多発するのである。


もちろん、皆が「誰かが・・・」と思っているからそうなるのだ。誰も決定したことに対する責任を取りたくないのである。自分が決めてしまって、あとで問題が起こったら困るというわけだ。



SE で言えば、仕様を全てお客さんに決めてもらわないと、気がすまないという人がいる。お客さんに細かい質問をするのだが、お客さんからは「そんなのどうでもいいから、好きなようにしてくれ」と言われたりする。


もちろん、システムを受託開発する場合、最終的な仕様の決定権は顧客側にある。しかし、明らかに顧客にとってこだわりのなさそうな問題は、開発者の「おすすめの仕様」で進めていかなければ、効率が悪い。顧客には、ユーザー・レビューやユーザー・テストなどの際に、まとめて確認してもらえばよいことである。



例えば、理髪店では、いつも「眉の下を剃るかどうか」を聞かれる(つまり、マブタのことなのだが、なぜかいつもそのように表現される)。しかし、「眉の上を剃るかどうか」を聞かれたことはない。眉の上については、理髪師が勝手に剃ることを決定しているが、ほとんどの客はそれで文句は言わないだろう。


この眉の上と下を分ける境界(つまり眉そのものか・・・)をどこに引くかということ、つまり、顧客に決めてもらうべきことと、自分で「えいやぁ」と決めてしまってよいこととの境界を見極めることが重要なのである。


開発者として経験を積んでいけば、ある程度は常識的な境界は分かってくる。しかし、顧客によって、「おまかせタイプ」だったり、「こだわりタイプ」だったりと、大きく違ってくるので、簡単にはいかない。このあたり、顧客の顔をよく見ながら、その都度考えていくしかないのである。







■関連記事
気の利いたプログラムは顧客満足度を上げ、開発工数を下げる
やってみなきゃわからないという現実
普通の言葉
情報求む
YAGNI ~ 予想でモノを作るな
外見も重視してください




要求定義のチェックポイント427
本園 明史
翔泳社 (2004/10/21)
売り上げランキング: 20898
おすすめ度の平均: 4.0
3 過ぎたるは及ばざるがごとし
4 初めての顧客、初めての業界で、どのようにして要求を聞きだすか悩んでいる時に!
5 これは使えるチェックポイント


オトナ語の謎。 (新潮文庫)
糸井 重里 ほぼ日刊イトイ新聞
新潮社 (2005/03/29)
売り上げランキング: 10258
おすすめ度の平均: 4.5
4 あるある(笑)
4 ほくそ笑む
4 ウヒヒヒヒ

AD
いいね!した人  |  コメント(2)  |  リブログ(0)
2007年06月12日(火)

プログラミングを始めようとして何度も挫折した人へ

テーマ:プログラマの心得

少し前になるが、はてな匿名ダイアリーで「プログラミングを始めようとして何度も挫折した」という人の投稿を読んだ(yasuhoの隠れ家さん経由)。色々な意味で考えさせられる話である。


才能以前なんだろうな。必死さが足りないって言われた。でも必死になるってどういう事なのか全然判らない。


元記事のトラックバックでも指摘されているが、この人は「プログラミングをしたい」とは思っているようだが、「プログラムを作りたい」と思っているようには見えない。例えば、「日常の単純作業を自動化するためのプログラムを作りたい」とか、「ゲームを作って友達に見せたい」とか、そういった動機がなければ、プログラミングは身につかないものだ(※1)。


「必死さが足りない」というのは、そういう「動機の薄さ」についての指摘だろう。しかし、「動機」は誰も与えてくれないし、本を読んでも書いていない。自分の中から出てくるものである(「面白いプログラムを作ろう」も参照)。



何がわからないのかもわからない。基礎の問題とか出して貰っても判らない。用語や文法みたいなレベルで既に躓くというか。なんというか、「言葉」って何で言葉って言うの?みたいな変な疑問ばかり湧いてきて進まないんだよね。


「用語や文法みたいなレベル」といった言葉が出てくるのは、勉強の進め方が間違っている証拠である。ちょうど受験が優先される日本の英語教育と同じだ。英語もプログラミングも、理論より実践が重要なのである。プログラミングを学ぶには、とにかく「実際にプログラムを作る」という経験を積むことが重要だ(「プログラミングは体で覚えろ」も参照)。


上達が早いプログラマは、事前に文法を学ぼうとはしない(家電などを使う場合に、慣れた人ほど「取説」を読まないのと同じである)。とりあえず自分が作りたいプログラムを作ろうとして、途中で分からないことが出てきたら、その都度調べる。このため、「何がわからないのかもわからない」などという状況はありえないのだ。そうこうしているうちに、自然と力がついてくる。



文法も、例えば1+1=2という式があったとして、なぜイコールがこの位置なのかとかくだらない事がずっと気になってしまいます。コロンが付いてたりとか括弧がどうだとか。


音楽家が作曲をする時に「ト音記号はなんでこんな変な形をしているのか」などということは考えないだろう。作曲には関係ないからだ。プログラマもプログラミング言語の「イコールの位置」や「コロン」や「括弧」に、意味を求めたりはしない。そういうことを考えるのは、プログラミング言語の研究者だとか、新しいプログラミング言語を開発しようとしている人の仕事であって、プログラマの仕事ではない。


プログラミング言語はプログラムを作るための道具にすぎない。つまり、プログラマを剣士に例えれば、プログラミング言語は刀である。言語の文法にこだわるのは、剣士になるために刀鍛冶の修行をするようなものだ。全く無関係ではないかもしれないが、進むべき方向を誤っている(※2)。それでも、どうしても刀の構造が気になるという人は、剣士ではなく刀工になるべきだ。



プログラマの仕事はプログラムを作ることである。それを見失ったまま、プログラミング言語をいくら勉強したところで、プログラマにはなれない。





※1
職業プログラマだと依頼されたものを作ることになるのだが、それでも、最初に勉強するときは自分の好きなものを作るべきだ(就職する前にプログラミングを経験すべきというのが私のいつもの主張である)。


※2
弘法筆を選ばずと言うが、有能なプログラマほど言語の違いにはこだわらないものだ(「Javaなんて知りません」も参照)。




新版 明解C言語 入門編
柴田望洋
ソフトバンククリエイティブ (2004/08/28)
売り上げランキング: 7708
おすすめ度の平均: 4.0
4 素人には厳しい ですが、 初心者には適した書籍かと思います
4 Cを学ぶならこれ!
5 K&Rのプログラミング言語Cの真の翻訳書?


なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング
小森 裕介
技術評論社 (2004/12)
売り上げランキング: 14278
おすすめ度の平均: 5.0
5 オブジェクト指向の使用法を学べる
5 オブジェクト指向がなぜいいのか、どのように書いたらいいのか、単純明快に示してくれます
2 タイトルに偽りあり
いいね!した人  |  コメント(18)  |  リブログ(0)
2007年03月11日(日)

本来の目的を思い出そう

テーマ:プログラマの心得
面倒くさいこと 」に書いたように、繰り返し行うような単純作業はコンピュータにやらせた方が効率的だ。プログラムを作る時間が掛かったとしても、長期的にみて利益が大きいならそうすべきである。

しかし、逆に、人間がやった方が効率的な仕事までコンピュータにやらせようとして、失敗することも少なくない。苦労してデータを入力しても、それに見合うだけの恩恵を与えてくれないようなシステムを見かけたことがないだろうか。

コンピュータに限らず、道具というものは、適した所に適した形で使わなければ効果がない。「システム化」といっても、何でもかんでも電子化してコンピュータで管理すればいいというものではないのである。

「システム化」というと、業務の一部をコンピュータ・システム(機械系)に移すことが目的であるかのように聞こえる。しかし、本来の目的は、業務を改善することである。機械系だけではなく、人間系を含めた広い意味での「システム」を再構築しなければ、その目的を果たせない場合も多い。


本来の目的が見失われてしまうという状況は、この業界ではよく見かける(もっとも、他の業界でもそうかもしれないが)。

例えば、プログラミングに集中しすぎたプログラマが、本来の「要件」を忘れてしまうことがある。技術を追求しすぎて、そのシステムに必要のない機能を作りこんでしまったり、過剰な性能を追求してしまったりするのだ。もちろん、ソフトウェアの機能が多く、高性能だというのは良いことだ。しかし、過剰な実装のために費やした作業時間は、本来なら別のことに使えたはずであり、そういう意味では損失である。

SEO(検索エンジン最適化)の場面でも、そうした状況が見られる。本来は「サイトを多くの人に使ってもらうこと」が目的のはずなのに、「検索エンジンの上位に表示されること」が目的であるかのように錯覚されることがあるのだ。そうなると、コンテンツ(サイトの内容)の充実に使うべき労力を、小手先の SEO ばかりに使ってしまう(※)。

あるいは、情報セキュリティに関しても見受けられる。本来、「情報漏洩を防ぐこと」が目的のはずなのに、「社内ルール」のようなものを守ることが目的になってしまうことがある。ルールが完璧ならそれでもいいのだが、中途半端だと危険だ。例えば、「コンピュータにはログイン・パスワードを設定すること」というルールがあるとしよう。しかし、そのパスワードを付箋に書いてモニターに貼っていたのでは意味がない。確かに、ルールは守っているのかもしれないが、本来の目的からすると意味がない。


このように、本来の目的が見失われてしまうと、無駄な労力を使うことになったり、無用な危険を招くこともある。特に、技術者が注意したいのは、どうしても技術寄りの視点にとらわれてしまいがちなことだ。目の前の技術的な問題に取り組んでいると、ついつい視野が狭くなってしまう。自分がやっていることの本来の目的は何かということを、時々、意識的に思い出すようにしたいものである。





※検索エンジンが目指しているのは、「検索者にとって有用なサイトを見つけてあげること」だろう。彼らはそのためにランキング等の仕組み作り、改良を続けている。つまり、SEO の王道があるとすれば、「有用なサイトにする」ということなのである。



■関連記事
デザイナーの屈辱
YAGNI ~ 予想でモノを作るな
うちの社員は信用できません



IT失敗学の研究―30のプロジェクト破綻例に学ぶ
不条理なコンピュータ研究会 日経コンピュータ
日経BP社 (2006/02)
売り上げランキング: 22896
おすすめ度の平均: 4.5
4 システム構築の世界は難しいのだが・・・
4 システム開発者自身を映し出す「鏡」
4 すべてのプロジェクトは大なり小なり不条理な側面を持っている


ザ・ゴール ― 企業の究極の目的とは何か
エリヤフ ゴールドラット 三本木 亮
ダイヤモンド社 (2001/05/18)
売り上げランキング: 2395
おすすめ度の平均: 4.5
4 値段以上の価値が宿る本
4 日本の製造業の凄さを再認識
5 小説でTOC理論(経営工学の制約理論)を学ぶ

いいね!した人  |  コメント(7)  |  リブログ(0)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。