試験公開中

このエントリーをはてなブックマークに追加

Developer's Code 本物のプログラマがしていること

KADOKAWA/アスキー・メディアワークス

1,120円+税

本物のプログラマが成功するために何をしているのか? IT業界の第一線で活躍するプログラマが自ら人柱となって得た教訓・体験をまとめた珠玉のエッセイ集。

※本書は同名タイトルの書籍(ISBN:978-4-04-886772-6)の電子書籍版になります。

関連サイト

出版社による関連ページが公開されています。

内容紹介

僕の名前はカー・ワイ・チャン。開発者だ。デザイナーもやってる。シカゴにあるWe Are Mammothの共同創設者でもある。僕らは、いろいろなクライアントに応えてアプリケーションを作っている。自分たちで使うためのWebベースのソフトウェアもいくつか作っている。まあ、これについてはまたあとで。

この本には、この業界で僕自身が人柱となって得た、教訓や意見、失敗が詰まっている。いろいろと体験してきたプログラマなら、この本で紹介する話と似たことを自分でも体験しているかもしれない。そんな話を通して、僕らは一緒に笑ったり、元気を出したり、悲鳴をあげたりできるだろう。旅を始めたばかりの新人のみなさんには、この業界での最初の数年間、この本を役立てていただけたらと思う。

この15 年で、数え切れないほどの教訓が得られた。この本で紹介するのはこんなことだ。

  • この業界で昔から使われてきた開発プロセス、ロール定義の多くがいまではもう時代にそぐわないのはなぜか。そして、それらを嗅ぎわける方法
  • ペットプロジェクトに「ノー」という理由。そして、生産的であるためには柔軟なスケジュールが欠かせない理由
  • 僕らの生産性を大きく高めるような職場環境とはどんなものか。生産性を大きく低下させる職場環境とはどんなものか
  • コード生成を開発プロセスに自然な形で組み入れる方法。そうすることで、迅速なコード生成以外にどのようなメリットが得られるか>
  • 意見が合わないクライアントと仕事をする一番よい方法。ソフトウェアの新規変更をすぐになかったものにしてしまう、猛り狂ったカスタマーの御し方
  • 給料を大きく上げることや、古くからの言い伝え「従業員は大事な資産です」では、よりよい技術仕事が実現しない理由
  • ソフトウェアが、それ自体のメリットに見合わないほど複雑になりつつあることを知る方法
  • よい先生となって、将来の世代の開発者へ僕らが持っている知識を伝えるための方法

この本は、あらゆる種類の開発者に向けたものだ。ただし、コードの話はほとんど出てこないよ。C#、Ruby、Python、PHP、Java、JavaScript、ActionScript。どの言語でプログラミングをしているかはあんまり関係ない。データベースの仕事をしてる? サーバーサイドのコードを書いてる? スクリプト言語でインターフェイスを作っている? それもどうでもいい。この本では、マークアップとかオブジェクトとか、そんな話じゃなく、プロの開発者を取り巻くあらゆるものについての話をしよう。

といっても、プログラミングの話がまったく出てこないわけでもない。コードについてもいくらかは話が出てくるだろう。でも、コードの話をするときには、技術的な観点からではなく、もっと総論的な話をする。ベストプラクティスやデザインパターンを延々と書き連ねたりはしないつもりだ。それについてはすばらしい本がやまほどあるからね。それらについては、折々で話をしていこう。

現代のホンモノのプログラマがどんなことをして、この業界で成功を収めているのか。それがこの本のテーマだ。(「イントロダクション」より抜粋)

書誌情報

  • 著者: Ka Wai Cheung, 新丈径(翻訳)
  • 発行日:
  • 最終更新日: 2012-09-10
  • バージョン: 1.0.0
  • ページ数: 176ページ(A5PDF版換算)
  • 対応フォーマット: PDF, EPUB
  • 出版社: KADOKAWA/アスキー・メディアワークス

対象読者

職業としてプログラマをしている・してみたい・興味のある人、『Clean Code』『Clean Coder』『達人プログラマー』などが好きな人

著者について

Ka Wai Cheung

Ka Wai Cheungは開発者であり、デザイナーでもあり、またWe Are Mammothの共同創設者でもある。また、『Flash Application Design Solutions: The Flash Usability Handbook』の共著者でもある(本書原著サイトより)。

新丈径

目次

謝辞

イントロダクション

  • 21 世紀のプログラマって?
  • 身をもって得た教訓
  • この本は僕らについての本だ

第1章 メタファ

  • エッセイ1 メタファを信用しすぎるな
  • エッセイ2 しっかりと計画を立ててから作ろう
  • エッセイ3 ローンチとは最初のリリースでしかない
  • エッセイ4「象牙の塔」のアーキテクトは神話
  • エッセイ5 古いコードは投げ捨てろ
  • エッセイ6 専門化よりも多様性
  • エッセイ7 メタファのせいで、もっとよい方法が見えなくなる

第2章 モチベーション

  • エッセイ8 楽しいことは仕事のなかにある
  • エッセイ9 始めたいところから始めよう
  • エッセイ10 完璧になろうとするな
  • エッセイ11 プログラミングをストップする
  • エッセイ12 アサイチで自分の仕事をテストしよう
  • エッセイ13 寝室では働かない
  • エッセイ14 第一印象は第一印象でしかない
  • エッセイ15 ローンチの精神的な価値
  • エッセイ16 議論をしよう

第3章 生産性

  • エッセイ17 ペットプロジェクトには「ノー」といおう
  • エッセイ18 すべての変動要素に制約を加えよう
  • エッセイ19 作業工程からは詳細を省こう
  • エッセイ20 毎日、自分のプロダクトの2 か所を改善しよう
  • エッセイ21 よい作業環境にお金をかけよう
  • エッセイ22 個人的なTo-Do リストを管理しよう
  • エッセイ23 チームで「オフタイム」を作ろう
  • エッセイ24 小さく、自律したチームで働こう
  • エッセイ25 生産性から「我々」を排除せよ

第4章 複雑さ

  • エッセイ26 ダメな複雑さの匂いを嗅ぎ分けろ
  • エッセイ27 シンプルさのパラドックス
  • エッセイ28 Pickup stick ゲーム的な複雑さ
  • エッセイ29 複雑さを表に出すな
  • エッセイ30「コーディングが難しい」と「使うのも難しい」
  • エッセイ31 リファクタリングするべきときを理解しよう
  • エッセイ32 プログラミングのリズムを作ろう

第5章 教育

  • エッセイ33 教育とコーディングは違う
  • エッセイ34「知識の呪い」に気をつけよう
  • エッセイ35 わかりやすい例を使おう
  • エッセイ36 シンプルにするためにウソをつこう
  • エッセイ37 自律的な思考を促そう

第6章 クライアント

  • エッセイ38 手ごわいクライアントはどこにでもいる
  • エッセイ39 ソフトウェアは魔法のブラックボックスじゃないってわかってもらおう
  • エッセイ40 アプリケーションの目標を決めよう
  • エッセイ41 熱狂的になろう。信念を持とう
  • エッセイ42 人を許そう。みんなに好かれる人物になろう
  • エッセイ43 時間だけが価値じゃない
  • エッセイ44 プロジェクトマネージャをリスペクトしよう

第7章 コード

  • エッセイ45 コードを書くのは最後の手段
  • エッセイ46 プラグインするだけで幸せになれる文化
  • エッセイ47 コードは究極の下っ端開発者
  • エッセイ48 人の仕事とロボットの仕事は分けよう
  • エッセイ49 コアでコードを生成する
  • エッセイ50 自分で作らないといけないとき

第8章 プライド

  • 僕らはマーケティングの問題を抱えている
  • 料理業界からの教訓

付録A 参考文献

訳者あとがき

Home 書籍一覧 Developer's Code 本物のプログラマがしていること ▲ ページトップへ戻る