名前重要 | プログラマが知るべき97のこと
名前重要著者: Matz ネイテイブ・アメリカンの信仰に「すべての人物・事物には真の名前があり、その名前を知るものはそれを支配することができる」というものがあるのだそうです。ですから、彼らは自分の真の名前を秘密にして、家族など本当に信頼できる人にしか打ち明けないのだそうです。そして、対外的にはあだ名を用意してそちらを使うということです。そういえばアニメ化もされたU・K・ル=グウィンの「ゲド戦記」でも同じ設定が用いられていましたね。「ゲド」というのは主人公の真の名前なので物語中にほとんど登場せず、物語の中では彼は一貫して「ハイタカ」と呼ばれていました。 さて、プログラミングの世界において、この信仰はある程度真実ではないかと感じることがたびたびあります。つまり、事物の名前には、理屈では説明しきれない不思議なパワーがあるような気がするのです。 たとえば、私が開発しているRubyも、名前のパワーを
Noといえることの大事さ | プログラマが知るべき97のこと
Noといえることの大事さ著者: 宮川 達彦 自分でつくったソフトウェアを公開し、利用してもらうことはとてもうれしいものです。利用しているユーザからのフィードバックに耳を傾けることはソフトウェアをよりよいものにしていくためにもとても重要なことです。 一方、ソフトウェアのデザインにおける究極の美しさはシンプルさにあると言われます。有名なUNIX哲学では”Write program that do one thing and do it well”(1つのことをうまくやるプログラムを書け)といわれるように、複数の機能をつめ込まず、単一の機能をもったプログラムを組み合わせて使うことが美とされます。 ここにギャップが生じます。ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。実際にそうした機能
育ちのよいコード | プログラマが知るべき97のこと
育ちのよいコード著者: 森田 創 高凝集と疎結合が優れた設計の指標だと教わったとき、戸惑ったのを覚えています。あるコードがどのくらい指標を満たしているのか、私達は判断できるのでしょうか。 巨大な関数や相互依存など、凝集や結合のまずさを示す「匂い」があるのはたしかです。鼻をつまみたくなるソフトウェアは誰にも覚えがあるでしょう。けれど一見清潔なコードをみたときも、それが本当にうまい抽象なのか不安に思うことはありませんか。 そんな時は少し視点を変え、コードの生い立ちに目を向けましょう。コードのレポジトリをチェックアウトし、それまでにチェックインされた変更、パッチをよく調べるのです。そのパッチはひとかたまりの「+」行からできていましたか?つまりパッチ単位の変更がファイルをまたがず、1つのファイルの同じ場所にまとまっていましたか? 条件にあうパッチが多いなら、凝縮や結合の指標には期待が持てそうです。
不具合にテストを書いて立ち向かう | プログラマが知るべき97のこと
不具合にテストを書いて立ち向かう著者: 和田 卓人 テストを行っている品質保証チームや、実際にシステムを使つでいる不具合が報告されたとき、あなたはどう思いますか?悲しんだりよ恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるというのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、1つの不具合修正が3つの新たな不具合を生んでしまうということになりがちです。 テスト駆動開発(TDD :Test Driven Development)とは、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。しかし不具合の発生とは、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか? やはりテストを書いて立ち向かつてゆくのです。私はテスト駆動開発を数年間実践してくる中で、心がけ
見知らぬ人ともうまくやるには | プログラマが知るべき97のこと
見知らぬ人ともうまくやるには著者: 小飼 弾 バグには2種類しかありません。1つは、出来るはずのことが出来ないこと。もう1つは、出来てはならないことが出来てしまうこと。そんなこと言われるまでもない?しかしプログラマという人種は前者には十分な注意を払っても、後者には前者ほど注意を払わない生き物のように思われます。 SQLインジ、エクションにCSRF…いわゆる脆弱性というのはすべて後者に属するバグで、しかも必ずサービスが始まってから顕在化します。こうした脆弱性が後を絶たないのは、プログラマが出来なかったことを出来るようにすることには一生懸命でも、そこで力つきてしまって、出来てはならないことが本当に出来ないかをチェックをするだけの余裕がないことの現れかもしれません。 これを防ぐには一体どうしたらよいのでしょうか? 私はLLEvalというWebサービスを提供しています。任意のコードを実行するという
快適な環境を追求する | プログラマが知るべき97のこと
快適な環境を追求する著者: 舘野 祐一 あなたは1日のうち、一体どれぐらいの時間をコーディングに費やしますか?1時間の人もいるでしょうし、10時間の人もいるでしょう。ほほ毎日続けるとしたら、一生でどれぐらいの時間をコーディングすることでしょうか。 私たちはコーディングをしている時、コードを書く以外にも様々なことを行っています。エディタを操作する・ビルドする・テストを走らせる・ドキュメントを閲覧する・必要なライブラリをインストールする・キーボードを叩く・画面を見る・椅子に座る、などなど細かく挙げるときりがありません。 たとえばエディタを操作することを考えてみましょう。エディタ上であるメソッドが定義されているソースを開きたいため毎回毎回いちいちgrepを駆使して該当ファイルを見つけて開く、なんて経験ありませんか?エディタ自体に簡単に目的のソースを開ける機能があるかもしれませんし、探せば誰かが有
ルーチンワークをフローのきっかけに | プログラマが知るべき97のこと
ルーチンワークをフローのきっかけに著者: 宮川 達彦 ソフトウェア・エンジニアやプログラマはよくアーティストに例えられます。ある人は2時間だけのコーディングで、他の人の8時間分の成果をあげることができます。また、コードの長さは必ずしもその品質やデザインの美しさ、メンテナンス性の高きには比例しません。あるプログラマが朝9時に出社し、夕方6時に退社するとしても、その問ランチをのぞいた8時間、つねにターミナルやエディタを開いてコーディングしつづける、というのはむしろ稀な部類でしょう。 周りの妨げがなくコーディングに没頭している状態を「フロー状態」と呼びますが、このフロー状態に何の苦労もなく突入できるエンジニアを本当の達人プログラマと呼ぶのかもしれません。何しろ、フローに入るための邪魔や誘惑が多すぎます。受信箱にたまった未読メール、RSSフィードリーダーにたまったニュース、頻繁にポップアップするメ
ロールプレイングゲーム | プログラマが知るべき97のこと
ロールプレイングゲーム著者: 関 将俊 ここでは私が実践している、ちょっと良いプログラマになるためのコツを紹介します。まるで「理想のプログラマ」のように仕事をするための簡単なアイデアです。チームでプログラミングするお仕事に就かれているみなさんが、このアイデアで昨日よりも気分よく過ごせるようになれば幸いです。 多くの達人が「理想のプログラマ」とはどういうものか、よいプログラマのあるべき姿、立ち振る舞いを説いてきました。おそらく、みなさんも達人たちが理想のプログラマについて書いた文章を読まれたのではないでしょうか。そして達人たちの示す理想のプログラマ像を想像してそんな人物になろうとしましたよね。みなさんは実際にそうなれたでしょうか。その振る舞いを実践するのはちょっと難しかったりしませんでしたか。 「理想のプログラマ」といった「理想の何か」になるために、本来の自分を変えて別な自分になる必要があり
命を吹き込む魔法 | プログラマが知るべき97のこと
命を吹き込む魔法著者: 森田 創 あなたのプロジェクトにコードネームはありますか?製品名でも、契約書の題目でもなく、あなたのチームが使うコードネームです。コードネームがないならつけてみましょう。誰も文句はいいません。 製品名のような「正式な名前」があるのに、なぜコードネームが必要なのでしょうか。それは普段から口にする名前こそが私達プログラマにとって「本当の名前」だからです。契約上の名前だけを持つプロジェクトが「開発一課でやってるやつ」あるいは「A社向け」などその場限りの指示語で呼ばれるのを耳にしたことはありませんか?リリースの直前まで製品名が決まらなかったことは?呼び名もないプロジェクトやソフトウェアをどう愛せるというのでしょう。プロジェクトに指示語やラベルではない本当の名前を与えるのが、コードネームの役割です。 プロジェクトが始まったらコードネームを決めましょう。決めてどんどん使いましょ
テストは正確に、具体的に
先にも書いたとおり、ユニットテストにおいては、実装コードの「偶然の仕様」への合致を確認するのではなく、コードの動きが本来の要求に合っているかを確認することが大切です。だからと言って、それを言い訳にテストが暖昧なものになるようでは因ります。テストはあくまで正確で厳密なものでなくてはなりません。 ここでは理解しやすいよう、あえて古典的な例をあげて説明してみましょう。ソート処理のコードをテストするという例です。今の時代に、業務の中でソートアルゴリズムの実装を求められるプログラマはあまりいないでしょう。しかし、ソートなら馴染み深く、ともかくどういう処理なのかを誰しもが知っている(少なくとも知っていると信じている)ので都合がいいのです。ただ、馴染みがあるだけに、自分の思い込みに気づきにくいというのも確かですが。 ソート処理のコードをテストする場合、「テストで何を確認するのか」とプログラマに尋ねたとす
良いプログラマになるには | プログラマが知るべき97のこと
良いプログラマになるには著者: Pete Goodlife 良いプログラマは良いコードを書き、良くないプログラマは…そうでないコードを書く、そんなことは何もシャーロック・ホームズでなくてもわかることでしょう。良くないプログラマの書くコードはまるで怪物のようです。周囲の人間は、その修正のためにあとで大変な苦労をさせられます。読者はみな当然、良いコードを書きたい、良いプログラマでありたい、と望んでいるでしょう。 良いコードは何の根拠もなく勝手に生まれたりはしません。今週はたまたま星回りが良いから良いコードができた、などということはないのです。コードを良くするには、そうすべく相当な努力をしなくてはなりません。良いコードを書きたいと心の底から願い、努力をした人だけが本当に良いコードを書けるのです。 ただ技術が優れているというだけでは良いコードは書けません。素晴らしいアルゴリズムを考え出せる知性を持
冗長なログは眠りを妨げる | プログラマが知るべき97のこと
冗長なログは眠りを妨げる著者: Johannes Brodwall 開発中のシステム、あるいは製品としてすでに稼働中のシステムがあるとします。そのシステムに、すぐに目につく問題があるとすれば、それはまず「ログが汚い」ということではないでしょうか。思い当たることがある人も多いでしょう。たとえば、あるWebページをごく普通に見ていて、リンクを1つクリックしただけなのに、システムの提供する唯一のログに大量のメッセージが記録されている、というようなことがあるのです。ログの情報があまりに大量だと、ログが無いのと同じくらい役に立ちません。 私たちプログラマが開発するシステムは、開発が終われば、その後は誰か別の人が使うことになります。プログラマとしては、開発したシステムはできるだけ長く残って欲しい、長く使われ、その間ずっとユーザの役に立つ存在であって欲しいと望むのが普通でしょう。しかし、システムが製品と
正しいアルゴリズムとデータ構造を選ぶ | プログラマが知るべき97のこと
正しいアルゴリズムとデータ構造を選ぶ著者: Jan Christiaan "JC" van Winkel 多数の支店を持つ大銀行が窓口業務のために新しいコンピュータを導入しました。しかし、その処理はあまりに遅く、日々不満が募っていました。まだオンラインバンクなどはない頃で、ATMも現在のように広く使われるようになる前の話です。銀行を直接訪れて手続きをする人が今よりはるかに多く、コンピュータが遅いとたちまち長蛇の列ができてしまいました。いら立った銀行はついには、「このままだと契約を破棄する」とコンピュータのベンダを脅し始めました。 ベンダは、遅延の原因を突き止めるべく、パフォーマンス解析とチューニングのスペシャリストを銀行に送り込みました。それでわかったのは、端末上で動くあるプログラムが、1つでCPUキャパシティのほとんどすべてを消費していたということです。プロファイリングツールを使い、その
1人より2人 | プログラマが知るべき97のこと
1人より2人著者: Adrian Wible プログラミングには、じっくり物を考えることが必要、じっくり物を考えるには1人になる必要がある…。プログラミングは1人でする作業、というステレオタイプはそこから生まれたのでしょう。 しかし最近では、プログラミング作業の進め方は変わってきています。「一匹狼」風の方法ではなく、複数人で協力して進めるという方法が主流になってきているのです。協力して作業をする方が、品質も生産性も、自分の仕事に対する満足度も上がると私は思います。プログラマどうしの連携を緊密にするのはもちろんですが、プログラマでない人たち、たとえばビジネスアナリスト、システムアナリスト、QA担当者、ユーザなどとの関係も密にすべきです。 つまり、プログラマはもはや、技術が優れているだけでは十分でないということです。他人との連携でより大きな成果が上げられるようでなくてはならないのです。 ここで
コード分析ツールを利用する | プログラマが知るべき97のこと
コード分析ツールを利用する著者: Sarah Mount プログラマの中には、「テストがいかに重要か」を、プログラミングを始めた頃から頭にたたき込まれてきた人が多いでしょう。近年では、ユニットテストやテスト駆動開発、アジャイル開発などが広く行われるようになり、開発サイクルのあらゆるフェーズでテストを最大限活用するという考え方を受け入れる人も増えました。しかし、テストがいかに重要と言っても、それがコードの品質を高める唯一の方法というわけではありません。他にも方法は数多くあるのです。 はるかな昔、まだCが「新しい言語」だった頃、CPU時間と記憶容量はとても貴重なものでした。このため最初期のCコンパイラでは、コードを読み取る回数を減らすためにセマンティクス分析の一部が省略されていました。つまり、コンパイル時にはバグの検出があまりできなかったのです。その埋め合わせとして、Stephen Johns
面倒でも自動化できることは自動化する | プログラマが知るべき97のこと
面倒でも自動化できることは自動化する著者: Cay Horstmann こんなプログラマがいました。モジュールのコードの行数を数えるように指示されたのですが、その時、コードをワードプロセッサの画面にコピー&ペーストしました。ワードプロセッサのカウント機能を使って行数を数えたわけです。次の週も、また次の週も同じように行数を数えました。これは良い方法とは言えません。 こんなプロジェクトもありました。そのプロジェクトでは、デプロイの度に煩雑で手間のかかる作業をしていました。コード署名の後、その結果をサーバに移動するなどの作業を、マウスを何度もクリックして行う必要がありました。ある時、誰かがスクリプトを書いて自動化しました。最終テストが行われる問、そのスクリプトは何百回も実行されました。予想を上回る使用頻度でした。これはとても良い方法でした。 自動化できそうな作業があっても、わざわざ何度も同じ手作
シングルトンパターンの誘惑に負けない | プログラマが知るべき97のこと
シングルトンパターンの誘惑に負けない著者: Sam Saariste シングルトン(Singleton)パターンは多くの問題の解決に役立つパターンです。このパターンでは、クラスのインスタンスは必ず1つしか生成されません。そのインスタンスは使用前に必ず初期化されます。そしてシングルトンをグローバルアクセスポイントとすることで、設計をシンプルにできます。こう書いていくと良いことずくめのようですが、この「古典的な」デザインパターンに何か短所はあるのでしょうか 実はたくさんあります。それはよく考えてみるとわかります。確かにシングルトンパターンは魅力的なのですが、私の経験では、このパターンには利点よりも弊害の方が多いと言えます。まずテストの妨げになります。そして保守性の点でも不利です。残念ながらその事実は広く知られているとは言えないため、多くのプログラマを窓きつけているのです。つい使いたい誘惑にから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E5%81%B6%E7%84%B6%E3%81%AE%E4%BB%95%E6%A7%98%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E6%9C%AC%E7%89%A9%E3%81%AE%E4%BB%95%E6%A7%98%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83
シンプルさは捨てることによって得られる
http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%81%B8%E3%81%AE%E9%81%93%E3%81%AF%E5%9C%B0%E9%9B%B7%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A7%E6%95%B7%E3%81