New Programmer's Survival Manual

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup (Pragmatic Programmers)

http://pragprog.com/book/jcdeg/new-programmer-s-survival-manual
http://yshibata.blog.so-net.ne.jp/2011-11-22
ためしに買って斜め読みしてみた．

結論からいうと，プログラマが知るべき97のことと同様に，プログラミング初心者や，IT系のマネージャー（≒プログラミング初心者）が一度は目を通しておくと良い良書だと思う．「プログラマが知るべき97のこと」に比べると，より具体的で実践的な感じだ．むしろプログラミング作法に近いか．性質が異なるので「あっちを読んでいるから，こっちは読まなくていい」ということはないだろう．ただし中級以上の人にとっては，あんまり得るものはなさそうな気はする．

まだ和訳は出てないようだけど，和訳が望まれる本の一つだ．*1そういうこともあって，この本をここで紹介しておく．どこかの出版社や，翻訳家や，或いは勉強熱心なプログラミング初心者の目にとまることを期待しよう．

追記：日本語版も近日発売．

プログラマのためのサバイバルマニュアル

http://www.oreilly.co.jp/books/9784873115719/

これは個別の言語やプログラミングテクニックとはちょっと違う，小さなことから大きなことまで熟練者が持つ種々雑多なノウハウやTIPSを，先輩から後輩に語り継いでいくような感じの本かな．どちらかというとプログラミングそのものより，その周辺を扱っている．もしあなたの職場に経験豊富で優秀なプログラマがいれば*2，OJTの最中に3年くらいかけて手取り足取りじっくりと口伝で教えるようなことが書いてある．たとえば「エディタを使いこなせ」とか「テストのカバレッジ１００％なんて意味ない」とか「複数の言語を学ぶことにはこういうメリットがある」とか．

気が向いたら追記するかも．

Tips 1: Beat Up Your Code

要するに「プログラムなんて動けばいい」の否定のようだ．

You must beat up your code, and the product as a whole, before it goes out to customers.

The customer, after all, beat up your product. They'll use it in ways you don't anticipate. They'll use it for extended periods of time. They'll use it in environments you didn't test in. The question you must consider is this; how many bugs do you want your customer to find?

The more you beat up your code right now, before it gets into customers' hands, the more bugs you'll flush out, and the fewer you'll leave for the customer.

(概要，以下も同じ)
「あなたは客へ手渡す前に，自分の書いたコードを叩きのめさなければならない．

客は，けっきょくはあなたのコードを叩きのめすのだ．彼らはそれをあなたが予期しなかった形で，より長い期間，あなたがテストしていなかった環境で使うのだ．あなたが考えなければならない質問はこうだ： あなたはいったい何個のバグを，お客に見つけて欲しいと思ってるのか？

あなたが客にコードを手渡す前に，自分のコードを今叩きのめせば叩きのめすほど，あなたはより多くのバグを洗い出せ，お客にはより少ないバグしか残さずにすむのだ．」

Tips 2: Insist on Correctness

In toy programs it's easy to tell the difference between correct and incorrect. Does factorial(n) return the correct number? That's easy to check: one number goes in, and another number comes out. But in big programs, there are potentially many inputs- not just function parameters, but also state within the system - and many outputs or other side effects. That's not so easy to check.

「オモチャのプログラムでは正常動作と異常動作の区別はたやすい．factorial(n)は正しい数値を返しているか？それをチェックするのは簡単だ：一つの数値が入力され，別の数値が出力される．しかし大きなプログラムでは，関数の引数だけでなくシステムの内部状態も含む多数の入力が存在し，そして多数の出力や副作用が存在する．これらのチェックは（オモチャのプログラムと違って）容易ではない．」*3

Less than 100 percent coverage means you have some cases that are not tested. Junior programmers will assume that the converse is true: when they hit 100 percent coverage, they have enough tests. However, that's not true: 100 percent coverage absolutely does not mean that all cases are covered.
(中略)
Don't lulled into complacency by 100 percent coverage: it means nothing about the quality of your code or your tests. Writing good tests, just like writing good application code, requires thought, diligence, and good judgment.

「１００％未満のカバレッジ(網羅率)はテスト漏れのケースがあることを意味している．未熟なプログラマーはその逆が真であると勘違いする．もしカバレッジが１００％になれば，テストは完璧なのだと．しかしカバレッジ100%は全てのケースを網羅していることは全く意味していない．
(中略)
１００％カバレッジで自己満足に陥るべからず．それはコード品質や優れたテストコードを全く意味しない．他のアプリを書くのと同様に，良いテストを書くには熟考と，勤勉と，優れた判断力が必要なのだ．」

• developerWorks「コード品質を追求する: カバレッジ・レポートに騙されないために」： http://www.ibm.com/developerworks/jp/java/library/j-cq01316/

Tips 9: Optimize Your Environment

The integrated development environment(IDE) has its advantage; primarily, it's easy to use. Don't let an IDE limit your exploration , however. Discrete tools, like Vim for text editing, have staying power among programmers because they're tremendously powerful.

「IDEはメリットは簡単に使えることだ．しかしIDEの限界を自分の限界にするな．テキストエディタにおけるVimのような独立したツールは，極めて強力なために根強い人気を誇る．」

• http://d.hatena.ne.jp/JavaBlack/20120218/p1
• http://d.hatena.ne.jp/JavaBlack/20110506/p2

Tip 10: Speak Your Language Fluently

A language - or any skill for that matter - takes about 10,000 hours of dedicated practice to reach true competency.(中略) This works out to about ten years for most people.

「一つの言語を使いこなせるようになるのに約10年かかる．」*4

There are a couple of ways to learn idiomatic programming:

• First, if there's a greate book on the language, by all means start there.
• Second, find open source projects written in the language and study them.

「その言語のイディオムを学ぶ方法には二つある．一つはその言語の名著があれば，まずはそれを勉強しろ．二つ目は，その言語で書かれたオープンソースを探して，それを勉強しろ．」

Tip 27: Get with the Project

Waterfall Project Management
(中略)
This style works well when the tasks are well-known and there isn't a lot of risk in the time estimates. In other fields of engineering, for example, building a road, the road engineers have a good idea of what they need to do and how long it takes. Likewise, if your team writes software to do customer billing and it already supports five methods of billing, adding another would be a project well-suited to waterfall management

「ウォーターフォール プロジェクトマネジメント
(中略)
このスタイルは，タスクがよく知られていて，時間の見積もりにリスクがあまり存在しない時に上手く働く．工学の他の分野，例えば道路建設のようなものでは，道路技術者は何をすべきか，その工期がどのくらいかについて良く理解している．同様に，あなたのチームが顧客の仕様書*5についてソフトウエアを書いていて，既にそのうち5つの機能を実装し，そこに一つの機能を追加するような場合は，ウォーターフォールが上手く適合する．」

Waterfall has a couple key vulnerabilities, too: first, when new invention is involved, it's impossible to tell at the outset of the project what tasks will be required or how long they’ll take. Programmers must resort to guessing, and the compounded effect of hundreds of guesses is a huge wild-ass guess. At best.

「ウォーターフォールは二つの弱点がある：最初に，新しい発明が含まれる時には，プロジェクトの開始時にどんなタスクが必要になり，それにどのくらいの時間が必要になるか述べること不可能になる．プログラマーは憶測*6という手段に頼ることになるが，何百もの憶測の複合効果は，せいぜい巨大な「いかれた」憶測*7にしかならない．」

In a waterfall project, you’ll be given some chunk of the project requirements and then asked the following:

• What tasks does it take to meet the requirements?
• How long will each of them take?

The totally honest answer to both questions is, “I don't know .” But your project manager won't take that one.

「ウォーターフォールプロジェクトで，あなたがプロジェクトの要求より幾つかの塊を投げられて，以下の質問をされたとしよう．

• 要求に合うようにするにはどんなタスクが必要か．
• それらにはどのくらいの時間がかかるか．

これらの質問に対する，完全に誠実な答は「分からない」だ．しかしプロジェクトマネージャはその答を認めないだろう．」（ちょい意訳）

... orz

こういうことは良くある．困ったマネージャーだと，リスクのない「つまらない」プロジェクトの見積もりと，リスキーな機能を含む「革新的な」プロジェクトの見積もりが全く本質的に異なるものであることが，なぜか理解できないらしい．

Tip 30: Identify Corporate Antipatterns

The Mythical Man-Month

The Mythical Man-Month [Bro95] by Fred Brooks is a famous book in the high-tech world. It seems like everyone has read it. It seems like everyone has forgotten it, too.
(中略)
Fred Brooks, however, asserts that adding programmers to a late project makes the project later.

The problem is that programming in a team requires a great deal of communication and coordination.

The Mythical Man-Month: Essays on Software Engineering

「人月の神話

Fred Brooksの『人月の神話』はハイテク界で有名な本である．全ての人がそれを読んでいるようだが，同時に全ての人が忘れている本でもあるようだ．
(中略)
しかしながらFred Brooksは，「遅延したプロジェクトへのプログラマーの追加はプロジェクトをさらに遅延させる」と主張した．

問題はチームでのプログラミングに相当なコミュニケーションと調整を必要とすることだ．」

人月の神話

Tip 32: Never Stop Learning

My personal bellwether is watching recently published books - the paper kind - since publishers are looking for the same sweet spot. They want to keep their books on the leading edge but need a large enough audience to offset the cost of making a book.　Blogs aren't as reliable because you'll always find someone who will blog about anything, making it hard to tell the difference between critical mass and passing fads.

「新技術がブレイクするタイミングを知る上ではブログは書籍ほど信用できない．*8 出版社は利益が出るだけに十分な読者がいないと出版しないが，ブログはそうではないから．*9」

Broaden your thinking

The real magic is that digging into Scheme with SICP won't just make you a better Shceme programmer. Forcing yourself out of your comfort zone and reasoning about code in a different manner will improve your ability to reason about all code, not just Scheme.

「SICP*10でSchemeを掘り下げることの魔力は，よりよいSchemeプログラマーになるというだけではない．あなた自身をぬるま湯から引きずり出して異なる作法を持つコードについて論じることは，Schemeだけでなくあらゆるコードを論じる能力を向上させることに繋がる．」

自分の視野を広めるには，こういう本を読んでみるのもおすすめ．

７つの言語 ７つの世界

Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages (Pragmatic Programmers)

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement

http://pragprog.com/book/rwdata/seven-databases-in-seven-weeks

• http://d.hatena.ne.jp/JavaBlack/20070726/p1
• http://d.hatena.ne.jp/JavaBlack/20070726/p3

*1:もちろんプログラマたるもの英語は必須科目だけど，初心者がこの本をスラスラ読めるとは思えないから．英語としては簡単平易なんだと思うけど，外国人が正確に理解しようと思うと意外と難しい．

*2:日本企業だと望み薄だが

*3:階乗の検証なら，幾つかのサンプルに対しての戻り値を，「正解」と比較すればまあ問題ないだろう．
しかしたとえば「疑似乱数」の検証はどうするか？それを考えて貰えば，この問題の難しさが理解できるだろう．「疑似乱数が本当にランダムであること」を，あなたはどうやって検証しますか？

*4:複数の言語だともっとかかる．

*5:bill．請求書だったり手形だったり法案だったりコンテキストによって訳語が変わる．今回は意訳して「仕様書」にした．文意としては間違ってないと思う．

*6:意訳して「感」といった方が良かったかも．日本だとKKD法「感、経験、度胸」などとも言われることがある．

*7:wild-ass guessをどう訳すべきか悩んだ．assには人前では口にできないような卑俗な意味もあるので「壮絶なクソ予測」という解釈が一番正しいのかもしれない．

*8:とブログで書くのも，我ながらアレだなあ．ｗ
自分は金儲けのためにブログをやってるわけではないこともあって，そういう部分では正直でありたいと思ってる．一方で，アフィリエイト収入などは喜んで受け取りますよ．プログラマーなので，言うまでも無く生活は苦しいから．

*9:日本語書籍に関しては技術動向より数年遅れになるので，和書よりは洋書の出版動向を見た方が技術動向の把握にはより良いと思う．

*10:この本のこと．

計算機プログラムの構造と解釈

Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science)