サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
超人の神話著者: Ryan Brush ソフトウェア業界で長く仕事をしている人なら、一度はこんな質問を受けたことがあるのではないで、しょうか。 XYZという例外が発生したんですが、何が問題なんでしょうか? こういう質問をする人が、スタックトレースやエラーログを提示してくれたり、問題の起きた状況について、詳しく説明してくれたりすることはまずありません。あなたを、自分とは別世界の人間だと考え、十分な情報を与えられなくても、少し話を聞いただけで問題を解決できると思っているのかもしれません。超人だから何でもすぐにわかる、と思っているのかもしれません。 ソフトウェアのことをよく知らない人が、こういう質問をするのは仕方のないことでしょう。彼らにとって、コンピュータを自在に操るのは魔法に近いことだからです。しかし、問題なのは、実はプログラマが同士の質問をすることも珍しくない、ということです。たとえば、設
ユーザが何をするかを観察する(あなたはユーザではない)著者: Giles Colborne 私達はどうしても、誰もが自分と同じようなものの見方や考え方をするはずと思っていしまいがちです。しかし実際には、ものの見方や考え方はひとによって大きく違っています。こういう誤った思い込みのことを心理学では「偽の合意効果」とよびます。自分と考え方や行動が違っている人を見た時、私たちは(多くの場合は無意識に)、そういう人たちを、なにか問題のある人、というふうに評価してしまいがちです。 ユーザの身になって考えるということがなかなか出来ないプログラマが多いですが、その理由もこの「先入観」にあると言っていいでしょう。ユーザはプログラマのようには物を考えません。そもそも、プログラマに比べてコンピューターを使う時間が圧倒的に少ないのです。また、コンピューターが中でどう動いてるのかを知らないし、知りたいとも思いません
技術的例外とビジネス例外を明確に区別する著者: Dan Bergh Johnsson プログラムの実行時に起きる問題には、大きく分けて2つの原因があります。1つは技術的な原因です。これは、発生するとアプリケーションの実行そのものが続けられなくなるような問題のことです。もう1つの原因はビジネスロジックで、これは簡単に言えば、ユーザがアプリケーションの使い方を誤らせないために(わざと)発生させる問題です。「モダンな」プログラミング言語、LISP、Java、Smalltalk、C#などは、この2種類の問題の発生を通知するために「例外(Exception)」を使用します。しかし、2種類の問題は本質的に大きく異なるものなので、混同しないように常に注意する必要があります。両者を同じ例外階層構造を使って表現することは混乱の元になりますし、ましてや同じ例外クラスで表現するのはもってのほかです。 プログラム
関数型プログラミングを学ぶことの重要性著者: Edward Garson 最近プログラミングコミュニティでは、再び関数型プログラミングへの関心が高まっています。その理由としては、業界全体でマルチコアへの移行が進んでいる、ということもあるでしょう。移行によって生じる新たな課題への対処に、関数型パラダイムの保つ特性がうまく合致することが明らかになってきたからです。たしかにそれも重要な理由です。しかし、仮にそれだけなら、私がここでわざわざ「あなたも関数型プログラミングを学ぶべき」という文章を書くこともなかったと思います。 関数型プログラミングのパラダイムを十分に学べば、その知識、技術は、マルチコアへの対応以外にも幅広く役立つでしょう。まず、自分の書くコードの品質を大きく高めることができます。重要なのは、「参照透過性(referential transparency)」が向上するということです。
誰にとっての「利便性」か著者: Gregor Hohpe 優れたAPI の設計の重要性、そして難しさについては、これまで多くのことが語られてきました。最初から適切なAPIを作ることは難しく、しかし後からAPIに変更を加えることはもっと難しい。まるで子育てのような難しさ、と言っていいでしょう。経験を積んだプログラマならほぼ皆知っていることでしょうが、優れたAPIとは、まず抽象度がどこをとっても一様であり、その上で、整合性、対称性を備えているものです。優れたAPIはプログラミング言語のボキャブラリーを充実させ、言語に豊かな表現力を与えるものでもあります。しかし、そうした原則を十分に意識していたとしても、適切なAPIができるとは限りません。甘い物は身体に必要だが食べ過ぎると成長によくない、というのと同様に、原則にとらわれすぎるとかえって悪い結果を招くことがあるのです。 こう書いただけだと暖昧でよ
ハードワークは報われない著者: Olve Maudal プログラマという仕事は、時に、懸命に働いても意味がない、ということかあります。長時間オフィスにいれば、プロジェクトに多大な貢献をしているような錯覚に陥ることもあゐし、同僚たちもそう思ってくれることがあります。しかし事実はまったく逆で、自分の働く時間や労力を減らせば減らすほど、プロジェクトへの貢献は大きくなると言えるのです。ときには、頑張って働くよりも、働かずに済む努力をした方が、はるかに大きな貢献ができることもあります。神経を集中させる時間、製品を産み出すのに使う時間が週に30時間を超えるようなら「自分は働き過ぎだ」と考えるべきでしょう。自分のかけている労力を減らすことを検討する必要があります。もっと効率的に働く方法、少ない労力と時間で多くを生み出す方法を探さなくてはならないということです。 一見してこれは直感に反する話なので、異を唱
共有は慎重に著者: Udi Dahan それは私が社会に出て最初に関わったプロジェクトでのことでした。まだ大学を出たてで、自分の能力を証明したくてしょうがなかった頃です。毎晩夜遅くまで会社に残り、既存のコードを読んで色々なことを学んでいました。そして私は初めて仕事を任された時、担当部分の作業にこれまで自分の学んできたことをどうしても実践してみたくなったのです。それは、コメントを入れること、ログをとること、そして、内容が似通っているコードを出来るだけライブラリ化することでした。しかし、意気揚々と臨んだコードレビューで私は思い知らされることになります。コードの再利用を容易に促進すると、かえってひんしゅくを買ってしまうのだ、ということを。 どうしてそういうことになったのでしょうか。だいがくでは「再利用」を優れたソフトウェア開発プロジェクトの象徴として教わってきました。どんな論文や教科書を読んでも
リファクタリングの際に注意すべきこと著者: Rajith Attapattu 私達プログラマには必ず、既存のコードの「リファクタリング」が必要になる時がやってきます。ただ、リファクタリングをする前にいくつか考えてほしいことがあります。次に書くようなことに注意すれば、自分を含め、開発に関わる全ての人の時間と労力を大幅に節約できるでしょう。 リファクタリングするにあたってはじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。既存のコード、テストを十分に検証しなけ
学び続ける姿勢著者: Clint Shank いま私たちは実に面白い時代に生きています。ソフトウェア開発を仕事にする人は世界中に存在しています。自分と同じくらいの能力を持った人は、どこにでも、いくらでもいる、そう実感することも多いのではないでしょうか。そういう状況で自分の市場競争力を維持するためには、「学び続ける姿勢」がとても重要です。学ぶことを止めれば、早晩、恐竜のように滅びてしまうことになるでしょう。ずっと同じ仕事にしがみついていると、いずれ必要とされなくなる日が来ます。自分の仕事が、よりコストの安い誰かにアウトソースされることもありえます。 学び続ける、と言うのは簡単ですが、具体的にはどうすればいいのでしょうか。社員のスキルセット拡大のために費用を負担してトレーニングを受けさせてくれる気前のいい会社もありますが、社員のトレーニングのためにわざわざ時間やお金を使うことは一切しない、とい
Noといえることの大事さ著者: 宮川 達彦 自分でつくったソフトウェアを公開し、利用してもらうことはとてもうれしいものです。利用しているユーザからのフィードバックに耳を傾けることはソフトウェアをよりよいものにしていくためにもとても重要なことです。 一方、ソフトウェアのデザインにおける究極の美しさはシンプルさにあると言われます。有名なUNIX哲学では”Write program that do one thing and do it well”(1つのことをうまくやるプログラムを書け)といわれるように、複数の機能をつめ込まず、単一の機能をもったプログラムを組み合わせて使うことが美とされます。 ここにギャップが生じます。ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。実際にそうした機能
ドメイン特化言語著者: Michael Hunger チェスプレイヤー、幼稚園の先生、保険の外交員など、どの分野にも言えることですが、専門家というのは、日常生活で使われる言葉とは全く違った言葉を使うものです。いわゆる「ドメイン特化言語(DSL: Domain Specific Language)」が存在するのはそのためです。分野(ドメイン)には、それぞれ固有の事象があり、固有の事象を表す特殊な語彙があるので、DSLによってその語彙に対応するというわけです。 DSLは、ある分野に固有の語彙や語法を使用して事象を表現できるよう作られたプログラミング言語です。この言語を使えば、コードは当該分野の専門家にとって読みやすく理解しやすくなります。その言語を使うことで、専門家自身が自らコードを書くこともできれば理想でしょう。DSLの中でも特に古くから存在するのは、ソフトウェア開発者や科学者をターゲットと
ドメインの言葉を使ったコード著者: Dan North たとえば、コードベースの中に、次のようなコードが見つかったとします。 if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) {...} このコードを見ても、何をやりたいコードなのかをすぐには理解できずに思わず頭をかきむしる・・・。そういう人が多いのではないでしょうか。どうもtraderオブジェクトからIDを取得して、そのIDを使って「MapのMap」からMapを取得しているようではあります。その「内側」のMapにportfolioオブジェクトのIDが存在しているかを確認しているようです。portfolioIdsByTraderIdの宣言部分が次のようになっているのを見れば、もっと頭をかきむしりたくなるでしょう。
[出典] プログラマが知るべき97のこと 当サイトはオライリー・ジャパンによる公式なサイトではありません。 個々のエッセイは「CC-by-3.0-US」によってライセンスされています。
シングルトンパターンの誘惑に負けない著者: Sam Saariste シングルトン(Singleton)パターンは多くの問題の解決に役立つパターンです。このパターンでは、クラスのインスタンスは必ず1つしか生成されません。そのインスタンスは使用前に必ず初期化されます。そしてシングルトンをグローバルアクセスポイントとすることで、設計をシンプルにできます。こう書いていくと良いことずくめのようですが、この「古典的な」デザインパターンに何か短所はあるのでしょうか 実はたくさんあります。それはよく考えてみるとわかります。確かにシングルトンパターンは魅力的なのですが、私の経験では、このパターンには利点よりも弊害の方が多いと言えます。まずテストの妨げになります。そして保守性の点でも不利です。残念ながらその事実は広く知られているとは言えないため、多くのプログラマを窓きつけているのです。つい使いたい誘惑にから
分別のある行動著者: Seb Rose 何をするにせよ、常に分別を忘れてはならない。自分のしたことがどういう結果を生むか、よく考えるのだ。 作者不明どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者のほうが魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結果、修正が不可能になってしまうことも多いのです。この
単一責任原則著者: Robert C. Martin 「変更する理由が同じものは集める、変更する理由が違うものは分ける。」良いデザインの基本原則を1つあげるとすればこれでしょう。 この原則は「単一責任原則 (Single Responsibility Principle :SR P)」と呼ばれています。これはつまり、1つのサブシステムやモジュール、クラス、関数などに、変更する理由が2つ以上あるようではいけない、ということです。1つ典型的な例をあげましょう。ビジネス ルール、レポート、データベースに関わるメソッドを持つクラスの例です。 public class Employee { public Money calculatePay() ... public String reportHours() ... public void save() ... } 3つのメソッドが1つのクラスに集め
DRY原則著者: Steve Smith DRY(Don’t Repeat Your Self:繰り返しを避けること)原則は、プログラミングに関して守るべきとされている原則の中でも特に重要なものと言っていいでしょう。これは、Andy HuntとDave Thomasが、著書「達人プログラマ」の中で提唱した原則です。よく知られたソフトウェア開発のベストプラクティスやデザインパターンの中にも、基本的にな考え方がこの原則と同じものがたくさんあります。開発者は、アプリケーションの中に何らかの「重複」があれば、また、重複が起きそうであれば、それを察知する必要があります。そして、適切なプラクティスや抽象化によってそれを排除する必要があるのです。そのための方法を学べば、よりきれいなコードを書けるようになるはずです。 重複は無駄であるアプリケーションを構成するコードはすべて、保守を必要とします。どのコード
名前重要著者: Matz ネイテイブ・アメリカンの信仰に「すべての人物・事物には真の名前があり、その名前を知るものはそれを支配することができる」というものがあるのだそうです。ですから、彼らは自分の真の名前を秘密にして、家族など本当に信頼できる人にしか打ち明けないのだそうです。そして、対外的にはあだ名を用意してそちらを使うということです。そういえばアニメ化もされたU・K・ル=グウィンの「ゲド戦記」でも同じ設定が用いられていましたね。「ゲド」というのは主人公の真の名前なので物語中にほとんど登場せず、物語の中では彼は一貫して「ハイタカ」と呼ばれていました。 さて、プログラミングの世界において、この信仰はある程度真実ではないかと感じることがたびたびあります。つまり、事物の名前には、理屈では説明しきれない不思議なパワーがあるような気がするのです。 たとえば、私が開発しているRubyも、名前のパワーを
ボーイスカウト・ルール著者: Robert C. Martin ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです(このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています)。 これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュー
ロールプレイングゲーム著者: 関 将俊 ここでは私が実践している、ちょっと良いプログラマになるためのコツを紹介します。まるで「理想のプログラマ」のように仕事をするための簡単なアイデアです。チームでプログラミングするお仕事に就かれているみなさんが、このアイデアで昨日よりも気分よく過ごせるようになれば幸いです。 多くの達人が「理想のプログラマ」とはどういうものか、よいプログラマのあるべき姿、立ち振る舞いを説いてきました。おそらく、みなさんも達人たちが理想のプログラマについて書いた文章を読まれたのではないでしょうか。そして達人たちの示す理想のプログラマ像を想像してそんな人物になろうとしましたよね。みなさんは実際にそうなれたでしょうか。その振る舞いを実践するのはちょっと難しかったりしませんでしたか。 「理想のプログラマ」といった「理想の何か」になるために、本来の自分を変えて別な自分になる必要があり
ルーチンワークをフローのきっかけに著者: 宮川 達彦 ソフトウェア・エンジニアやプログラマはよくアーティストに例えられます。ある人は2時間だけのコーディングで、他の人の8時間分の成果をあげることができます。また、コードの長さは必ずしもその品質やデザインの美しさ、メンテナンス性の高きには比例しません。あるプログラマが朝9時に出社し、夕方6時に退社するとしても、その問ランチをのぞいた8時間、つねにターミナルやエディタを開いてコーディングしつづける、というのはむしろ稀な部類でしょう。 周りの妨げがなくコーディングに没頭している状態を「フロー状態」と呼びますが、このフロー状態に何の苦労もなく突入できるエンジニアを本当の達人プログラマと呼ぶのかもしれません。何しろ、フローに入るための邪魔や誘惑が多すぎます。受信箱にたまった未読メール、RSSフィードリーダーにたまったニュース、頻繁にポップアップするメ
命を吹き込む魔法著者: 森田 創 あなたのプロジェクトにコードネームはありますか?製品名でも、契約書の題目でもなく、あなたのチームが使うコードネームです。コードネームがないならつけてみましょう。誰も文句はいいません。 製品名のような「正式な名前」があるのに、なぜコードネームが必要なのでしょうか。それは普段から口にする名前こそが私達プログラマにとって「本当の名前」だからです。契約上の名前だけを持つプロジェクトが「開発一課でやってるやつ」あるいは「A社向け」などその場限りの指示語で呼ばれるのを耳にしたことはありませんか?リリースの直前まで製品名が決まらなかったことは?呼び名もないプロジェクトやソフトウェアをどう愛せるというのでしょう。プロジェクトに指示語やラベルではない本当の名前を与えるのが、コードネームの役割です。 プロジェクトが始まったらコードネームを決めましょう。決めてどんどん使いましょ
先にも書いたとおり、ユニットテストにおいては、実装コードの「偶然の仕様」への合致を確認するのではなく、コードの動きが本来の要求に合っているかを確認することが大切です。だからと言って、それを言い訳にテストが暖昧なものになるようでは因ります。テストはあくまで正確で厳密なものでなくてはなりません。 ここでは理解しやすいよう、あえて古典的な例をあげて説明してみましょう。ソート処理のコードをテストするという例です。今の時代に、業務の中でソートアルゴリズムの実装を求められるプログラマはあまりいないでしょう。しかし、ソートなら馴染み深く、ともかくどういう処理なのかを誰しもが知っている(少なくとも知っていると信じている)ので都合がいいのです。ただ、馴染みがあるだけに、自分の思い込みに気づきにくいというのも確かですが。 ソート処理のコードをテストする場合、「テストで何を確認するのか」とプログラマに尋ねたとす
車輪の再発明の効用著者: Jason P. Sage 「前に作られたものがあるのなら、それを使えばいいじゃないか。車輪を再発明するなんてバカげてる……」 この言葉、人によって言い方は少しずつ違うでしょうが、聞いたことのある人は多いのではないでしょうか。仕事の現場でも、大学などでも頻繁に言われることだからです。しかしなぜでしょうか。「車輪の再発明」はどうしてそんなに忌み嫌われるのでしょうか。それはまず、新たにコードを書くより、既存のコードを流用する方が安全でコストが少なくて済むからです。既存のコードは、その多くが「正しく動作すると既に確認されたコード」です。厳しいテストによって品質を高められ、製品としても役立ってきた実績のあるコードが多いのです。既存の製品やコードベースに時間と労力を投資したのに、同様のものを再度作ってまた時間と労力を投資するのは無駄、という考えもあります。あえて車輪の再発明
次のページ
このページを最初にブックマークしてみませんか?
『プログラマが知るべき97のこと』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く