サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
すべきことは常に明確に著者: Dan Bergh Johnsson たとえば、私が3人のプログラマの肩を叩いて、「今、どんな仕事をしているんですか」と尋ねたとしましょう。すると1人は、「ああ、今、このメソッドのリファクタリングをしているところですよ」と答えました。もう1人は「このWebアクションにパラメータをいくつか追加しているところです」と答えました。そしてもう1人は「このユーザストーリを扱っています」と答えました。 この場合、最初の2人は細部にばかりとらわれていて、3人目のプログラマだけが大局を見ている、自分の仕事の目的がよくわかっている、そういうふうにも見えます。しかし、3人に作業の具体的内容と所要時間を聞いてみると、様子がまったく違ってきたのです。最初の2人は、自分がいま取り組んで、いる作業の内容を完全に把握していました。作業ではどのファイルについて何をするのか、何時間で完了する予
ハードワークは報われない著者: Olve Maudal プログラマという仕事は、時に、懸命に働いても意味がない、ということかあります。長時間オフィスにいれば、プロジェクトに多大な貢献をしているような錯覚に陥ることもあゐし、同僚たちもそう思ってくれることがあります。しかし事実はまったく逆で、自分の働く時間や労力を減らせば減らすほど、プロジェクトへの貢献は大きくなると言えるのです。ときには、頑張って働くよりも、働かずに済む努力をした方が、はるかに大きな貢献ができることもあります。神経を集中させる時間、製品を産み出すのに使う時間が週に30時間を超えるようなら「自分は働き過ぎだ」と考えるべきでしょう。自分のかけている労力を減らすことを検討する必要があります。もっと効率的に働く方法、少ない労力と時間で多くを生み出す方法を探さなくてはならないということです。 一見してこれは直感に反する話なので、異を唱
DRY原則著者: Steve Smith DRY(Don’t Repeat Your Self:繰り返しを避けること)原則は、プログラミングに関して守るべきとされている原則の中でも特に重要なものと言っていいでしょう。これは、Andy HuntとDave Thomasが、著書「達人プログラマ」の中で提唱した原則です。よく知られたソフトウェア開発のベストプラクティスやデザインパターンの中にも、基本的にな考え方がこの原則と同じものがたくさんあります。開発者は、アプリケーションの中に何らかの「重複」があれば、また、重複が起きそうであれば、それを察知する必要があります。そして、適切なプラクティスや抽象化によってそれを排除する必要があるのです。そのための方法を学べば、よりきれいなコードを書けるようになるはずです。 重複は無駄であるアプリケーションを構成するコードはすべて、保守を必要とします。どのコード
ドメイン特化言語著者: Michael Hunger チェスプレイヤー、幼稚園の先生、保険の外交員など、どの分野にも言えることですが、専門家というのは、日常生活で使われる言葉とは全く違った言葉を使うものです。いわゆる「ドメイン特化言語(DSL: Domain Specific Language)」が存在するのはそのためです。分野(ドメイン)には、それぞれ固有の事象があり、固有の事象を表す特殊な語彙があるので、DSLによってその語彙に対応するというわけです。 DSLは、ある分野に固有の語彙や語法を使用して事象を表現できるよう作られたプログラミング言語です。この言語を使えば、コードは当該分野の専門家にとって読みやすく理解しやすくなります。その言語を使うことで、専門家自身が自らコードを書くこともできれば理想でしょう。DSLの中でも特に古くから存在するのは、ソフトウェア開発者や科学者をターゲットと
1万時間の訓練著者: Jon Jagger 「集中的訓練 (Deliberate practice:DP)」という言葉があります。集中的訓練は、ただ課題をこなすだけのものではありません。「課題のための課題」、課題を終わらせるためだけに課題をやっているのだとしたら、それはまったく集中的訓練とは呼べないでしょう。 集中的訓練の目的は、あくまで自らの能力を高めることにあります。いわゆる「スキル」や「テクニック」を身につけることが目的なのです。集中的訓練において重要なのが「反復」です。身につけたい能力をいくつかの小さな要素に分割し、その一つ一つについて反復訓練をし、習熟度を高めていきます。つまり「反復の反復」が必要になる、ということです。ゆっくりと、能力全体の習熟度を望ましいレベルにまで引き上げていきます。集中的訓練の目的は習熟度を上げることであり、個々の課題、作業をこなし、完了することではないの
インストールやデプロイに関わる作業というものはどうしても後回しにされ、プロジェクトの終了間際になってから始めることになりがちです。インストールツールを書く作業を丸投げされたリリースマネージャが、その作業を「必要悪」として考えている、などということも珍しくありません。レビューやデモで、デプロイやインストールが一応正しくできていることを確認はするのですが、そのための環境が単なる「間に合わせ」で、適切なものでないことも多いのです。これでは、チームのメンパーは、デプロイのプロセスやデフロイ先の環境などに関してまったく学ぶことができませんし、改善したいときには手遅れということになってしまうでしょう。 インストール/デプロイ作業こそが、顧客がはじめて製品に触れる機会です。この作中自体は簡単なものかもしれませんが、信頼できる(少なくともデバッグしやすい)本番環境を作り上げるための第一歩です。顧客が実際に
優れたAPI の設計の重要性、そして難しさについては、これまで多くのことが語られてきました。最初から適切なAPIを作ることは難しく、しかし後からAPIに変更を加えることはもっと難しい。まるで子育てのような難しさ、と言っていいでしょう。経験を積んだプログラマならほぼ皆知っていることでしょうが、優れたAPIとは、まず抽象度がどこをとっても一様であり、その上で、整合性、対称性を備えているものです。優れたAPIはプログラミング言語のボキャブラリーを充実させ、言語に豊かな表現力を与えるものでもあります。しかし、そうした原則を十分に意識していたとしても、適切なAPIができるとは限りません。甘い物は身体に必要だが食べ過ぎると成長によくない、というのと同様に、原則にとらわれすぎるとかえって悪い結果を招くことがあるのです。 こう書いただけだと暖昧でよくわからないと思いますので、具体例をあげることにしましょう
コードレビューは一般的に「実施すべきもの」とされています。なぜでしょうか。コードの質を上げ、欠陥を減らすためでしょう。しかし、目的はそれだけとは限りません。 プログラマの中には、コードレビューを毛嫌いする人が多くいます。おそらく過去に、コードレビューでなにか嫌な経験をしたことがあるのでしょう。全コードが社会規定のレビューを担当するのはだいたいアーキテクトやリードデベロッパです。「アーキテクトがすべてをレビューする」というプラクティスです。そうすることが企業の「ソフトウェア開発工程マニュアル」などで規定されていれば、プログラマはその規定にしたがう他ありません。 そのような厳しく堅苦しいレビューが必要な企業も中にはあります。しかし、大半の企業ではそうではありません。どうしても非生産的になってしまうからです。この種のレビューを実施すると、レビューを受けている側は、まるで自分が軍法会議にでもかけら
もう何年も前のことですが、私は以前、COBOLを使ったシステム開発に関わっていたことがあります。そのシステムでは、十分な理由がない限りインデントを変更してはならない、という規則になっていました。誰かが余分なインデントを入れてしまったために、システムに以上が起きたということが以前あったためです。この規則は、適切なコードレイアウトにしないとコードの意味が誤解されやすい場合にも、例外なく守らなければならないことになっていました。その結果実際に誤解を招くことがよくあったので、私達は常に不安に苛まれ、慎重にコードを読んでいました。この規則はプログラマにとって大きな足かせになっていたし、それによるコストも大変なものだったろうと思います。 プログラマは仕事の時間を、実際にコードをタイプすることよりも、コードを探すことと読むことに費やしている、そんな調査結果もあるようです。修正すべき箇所はないか、あるとす
想像してみてください。ある朝目覚めた時、建設業の世界に世紀の大革命が起きていたとしたら。信じがたいほど仕事が速く、コストの安いロボットたちがすべての作業をしてくれるようになっていたとしたら。ロボットたちは素材をなにもないところから合成できる上、働くためのエネルギーコストもほぼゼロです。そしてなにか不具合があっても自分で自分を修理できます。更に素晴らしいのは、正確な図面をこちらで用意する必要がないということです。おおまかな青写真さえ渡しておけば、ロボットたちはそれを元に人間の介入なしに作業ができるのです。つまり建設コストを無視できるほど小さく出来るよいうことです。 もしそんなことが起きたら、建設業者にどれほどの影響が及ぼすかはすぐにわかるでしょう。影響は実際の建設を行う施工業者だけにとどまりません。さらに「上流」にも影響は及ぶでしょう。施工のコストがゼロに近くなった時、建築士、設計士と呼ばれ
ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです(このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています)。 これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュールを改善する努力を続けたとしたら、その結果どういうことが起きると
美はシンプルさに宿る著者: Jørn Ølmheim 1つのプラトンの言葉を引用します。ソフトウェア開発に携わる人ならばぜひ知っておくべき言葉、常に心に留めておくべき言葉だと思います。 「文章にしろ、和音にしろ、リズムにしろ、美しく、優雅なもの優れたものはすべて、シンプルである」 この言葉には、ソフトウェア開発において大事にすべきことが見事に要約されていると思います。 プログラマがコードを書くときに留意すべきことはいくつかありますが、まとめればだいたい次のようになるでしょう。 可読性保守性開発効率(言葉で表現するのが難しい)美しさプラトンの言葉が教えてくれるのは、シンプルであることを心がければ、上のすべてが達成されるということです。 4つ目の「美しさ」とは何でしょうか。コードが美しいとはどういう意味7日は、曖昧で、なかなか明確にはわかりません。美しいかどうかは、どうしても主観的な判断になり
コーディング規約を自動化する著者: Filip van Leanen あなたも見たことがある光景かもしれませんが、新しいプロジェクトが立ち上がる時というのは、みんな「抱負」を持つものです。ああも使用、こうもしよう、と希望に燃えるのです。そういう抱負は、多くの場合ドキュメントにまとめられます。たとえば「このプロジェクトでは、一定の規約に従ってコーディングをする」ということが決定され、その規約がドキュメントにまとめられたりするのです。キックオフミーティングでは、プロジェクトリーダーがドキュメントの内容を承認し、プロジェクトのメンバーの多く、時には全員が、その規約を守ることに賛成します。しかし、いざプロジェクトが開始されると、こうした最初の抱負は徐々に顧みられなくなっていきます。そしてプロジェクト完了時には、規約など全く無視された無秩序なコードが、なぜそうなったのか誰にも理由がわからないまま、納
「プログラマが知るべき97のこと」 出版社: オライリージャパン 発行: 2010年12月 発行 言語: 日本語 ISBN-10: 4873114799 ISBN-13: 978-4873114798 Kevlin Henney編、和田 卓人 監修、夏目 大 訳 原書:97 Things Every Programmer Should Know 購入Amazon.co.jp: プログラマが知るべき97のこと: 和田 卓人, Kevlin Henney, 夏目 大: 本使用許可個々のエッセイはクリエイティブ・コモンズ表示3.0の条件の下で、自由に使用することが出来ます。 詳しくは以下のリンクをご覧ください。Creative Commons — 表示 3.0 アメリカ合衆国 — CC BY 3.0 US
シングルトンパターンの誘惑に負けない著者: Sam Saariste シングルトン(Singleton)パターンは多くの問題の解決に役立つパターンです。このパターンでは、クラスのインスタンスは必ず1つしか生成されません。そのインスタンスは使用前に必ず初期化されます。そしてシングルトンをグローバルアクセスポイントとすることで、設計をシンプルにできます。こう書いていくと良いことずくめのようですが、この「古典的な」デザインパターンに何か短所はあるのでしょうか 実はたくさんあります。それはよく考えてみるとわかります。確かにシングルトンパターンは魅力的なのですが、私の経験では、このパターンには利点よりも弊害の方が多いと言えます。まずテストの妨げになります。そして保守性の点でも不利です。残念ながらその事実は広く知られているとは言えないため、多くのプログラマを窓きつけているのです。つい使いたい誘惑にから
リファクタリングの際に注意すべきこと著者: Rajith Attapattu 私達プログラマには必ず、既存のコードの「リファクタリング」が必要になる時がやってきます。ただ、リファクタリングをする前にいくつか考えてほしいことがあります。次に書くようなことに注意すれば、自分を含め、開発に関わる全ての人の時間と労力を大幅に節約できるでしょう。 リファクタリングするにあたってはじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。既存のコード、テストを十分に検証しなけ
良いプログラマになるには著者: Pete Goodlife 良いプログラマは良いコードを書き、良くないプログラマは…そうでないコードを書く、そんなことは何もシャーロック・ホームズでなくてもわかることでしょう。良くないプログラマの書くコードはまるで怪物のようです。周囲の人間は、その修正のためにあとで大変な苦労をさせられます。読者はみな当然、良いコードを書きたい、良いプログラマでありたい、と望んでいるでしょう。 良いコードは何の根拠もなく勝手に生まれたりはしません。今週はたまたま星回りが良いから良いコードができた、などということはないのです。コードを良くするには、そうすべく相当な努力をしなくてはなりません。良いコードを書きたいと心の底から願い、努力をした人だけが本当に良いコードを書けるのです。 ただ技術が優れているというだけでは良いコードは書けません。素晴らしいアルゴリズムを考え出せる知性を持
ソフトウェア開発のプロジェクトでは、よほど小規模なプロジェクトは別にして、必ず人と人とが共に仕事をすることになります。研究などでは稀にソフトウェアを作ることそのものが目的ということもありますが、ほとんどのソフトウェアは、誰かの目標達成を手助けするために書かれます。つまり、人は、人とともに、そして人のためにソフトウェアを書くというわけです。ソフトウェア開発は「人のビジネス」なのです。それにもかかわらず、プログラマが人との関わりについて教育を受けることは、残念なことにほとんどありません。幸い役立つ学問分野もあるので目を向けてみることにしましょう。 たとえば、ルートヴィヒ・ウィトゲンシュタインは「哲学探究」などの著書の中で、「私たちが互いに話をする際には言語を使うが、私たちの頭の中にある思考や発想、画像などが、そのまま言語に変換されて他人の頭に送られるわけではない」という主旨のことを言っています
学び続ける姿勢著者: Clint Shank いま私たちは実に面白い時代に生きています。ソフトウェア開発を仕事にする人は世界中に存在しています。自分と同じくらいの能力を持った人は、どこにでも、いくらでもいる、そう実感することも多いのではないでしょうか。そういう状況で自分の市場競争力を維持するためには、「学び続ける姿勢」がとても重要です。学ぶことを止めれば、早晩、恐竜のように滅びてしまうことになるでしょう。ずっと同じ仕事にしがみついていると、いずれ必要とされなくなる日が来ます。自分の仕事が、よりコストの安い誰かにアウトソースされることもありえます。 学び続ける、と言うのは簡単ですが、具体的にはどうすればいいのでしょうか。社員のスキルセット拡大のために費用を負担してトレーニングを受けさせてくれる気前のいい会社もありますが、社員のトレーニングのためにわざわざ時間やお金を使うことは一切しない、とい
他人よりまず自分を疑う著者: Allan Kelly プログラマというものは(つまりわたしたちは)自分の書いたコードに何か誤りがあるとは、なかなか考えようとしない人種です。現に問題が起きていても、それが自分のせいだと思うことは滅多になく、「きっとコンパイラのせいだろう」などと思ったりします。 しかし実際には、コンパイラやインタプリタ、OS、アプリケーションサーバ、データベース、メモリマネージャなど、システムソフトウェアのバグで問題が発生するということは、極めて稀なのです(ほぼないと言っていいでしょう)。もちろんシステムソフトウェアにもバグはあるものですが、責任を押し付けたがる人が期待するよりは、はるかに少ないと言えます。 私が「本当にコンパイラのバグが問題の原因だった」というけいけんをしたのはたった1度だけで、ループ変数の最適化に関わるバグでした。それよりも、コンパイラあるいはOSのバグの
分別のある行動著者: Seb Rose 何をするにせよ、常に分別を忘れてはならない。自分のしたことがどういう結果を生むか、よく考えるのだ。 作者不明どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者のほうが魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結果、修正が不可能になってしまうことも多いのです。この
Paul Lee(通称Hoppy)は、私の同僚の中でも、プログラミングのことに関しては最高のエキスパートで、皆の尊敬を集めています。先日も少し困ったことがあったので、Hoppy のデスクまで、言って「ちょっとコードを見てもらえないだろうか」と頼みました。 「いいよ」Hoppyはそう答えました。「じゃあ、椅子を出してそこに座って」そう言われて私は、彼の後ろに築き上げられたコーラの空き缶のピラミッドを壊さないよう、慎重に椅子を引っ張り出しました。 「どのコード?」 私は、問題になっている関数の名前と、その関数のコードが収められているファイルの名前を告げました。 「じゃあ、その関数を見てみようよ」Hoppyはそう言って、置いてあったK&Rをどけると、キーボードを私の前に移動させました。 「IDEはどこ?」Hoppyは、IDEを使っておらず、エディタで作業しているようでしたが、そのエディタは私に使
[出典] プログラマが知るべき97のこと 当サイトはオライリー・ジャパンによる公式なサイトではありません。 個々のエッセイは「CC-by-3.0-US」によってライセンスされています。
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中!すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する(あなたはユーザではない)コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
このページを最初にブックマークしてみませんか?
『プログラマが知るべき97のこと』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く