SSブログ

書籍『リーダブルコード』 [献本]

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者: Dustin Boswell
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)

この本が出版された時に、出版社から献本されたのですが、最近やっと読みました。

お薦めです!★★★★★

読みやすい理解しやすいコードを書くことの重要性は、拙著『プログラマー”まだまだ”現役続行』でも述べていますが、この本は上手くまとまっています。

『プログラミング作法』の第1章「スタイル」をさらに分かりやすく解説した感じの内容です。それに加えて、『実装パターン』『Clean Code アジャイルソフトウェア達人の技』でも重要だと述べられている事柄のいくつかが、本書では上手く分かりやすく説明されています。

付録『あわせて読みたい』では、定番とも言える書籍が列挙されています。特に「高品質のコードを書くための書籍」として挙げられている書籍は、『リーダブルコード』を読み終えたら、必ず読んでもらいたい本ばかりです。

本書に書かれている内容を、無意識に実践できるようになるまで、意識して実践することで、みなさんが書くコードは読みやすくなると思います。

第18期「プログラミング言語Java」コースを開講 [プログラミング言語Java教育]

私にとって通算18期目になる「プログラミング言語Java」コースを社内向けに今日から開始します。第18期は、12名でスタートです。参加者のうち、今年4月に入社してきた新卒新人が7名です。

今年4月に開始した第16期と第17期もコース途中ですので、第18期を入れると、しばらくは3コースが同時に進行することになります。

あれからすでに10年 [時の流れ]

『Software Craftsmanship』を読んだのは、10年前の2002年3月です。

Software Craftsmanship: The New Imperative

Software Craftsmanship: The New Imperative

  • 作者: Pete McBreen
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2001/08/23
  • メディア: ペーパーバック

この本を読んだのをきっかに、もう一度、開発の現場に戻りたいと思い、私にとって2度目となる米国駐在を受け入れました。妻と二人で米国に向かったのが2002年8月20日です。42歳でした。

しかし、二ヶ月もせずにプロジェクトは中止となり、2002年11月の今頃は、特に日本から指示される仕事もなく、毎日会社に行っては、私が仕様を作成したC++用のライブラリのプログラマーズガイドを作成していました。翌年の1月末に帰国するまで、このプログラマーズガイドの執筆以外の作業を行った記憶はないです。

2002年11月には、妻と二人で西海岸を訪れて、その時初めて、Joshua BlochやNeal Gafterに会って話をしました。その時の写真が『プログラマー”まだまだ”現役続行』に掲載されている写真(p.47)です。

開発の現場に戻るということは、帰国後6年間従事したプロジェクトで実現したのですが、最近4年間は満足できるような開発が自分自身ではできていない状況です。

継続インテグレーションは強みではなくなった(2) [プログラマー現役続行]

短期間で、たとえば、1週間である機能を既存のシステムに追加するプロトタイプを行う場合、テスト駆動開発や継続的インテグレーションが実践されていることは、どこまでプロトタイプできるかに大きな影響を与えます。

継続的インテグレーションにより、開発者は常にビルドできる状態でプロトタイプに専念できる訳ですし、プロトタイプが終わったと宣言した時点でサーバによるビルドもできている訳です。自動テストが整備されていれば、ある機能のプロトタイプにより、他の部分が問題を起こさないかを早い段階で確認することができます。

もし、どちらも行われないとしたら、プロトタイプを行った開発者のPCでしかビルドできなかったり、システム全体をテストすると様々な問題が見つかったりします。プロトタイプであっても、さらに機能を拡張するために開発者を追加することは十分に考えられます。その場合に、プロトタイプを行った開発者のPCにしか環境がなったりすると、開発者を一名追加することさえ困難となります。

テスト駆動開発や継続的インテグレーションは、ラピッドプロトタイピングをサポートするものであり、阻害するものではありません。

その上で重要なのは、そのような環境が整備された上で、創造的なプロトタイピングをきちんと行える優秀なエンジニアを集めるか育てておくことです。どんな技術領域でも、そこの技術の基本知識を学習して、さらに技術を自在に正しく使えるようになって初めて、ラピッドプロトタイピングができるのです。

継続インテグレーションは強みではなくなった [プログラマー現役続行]

Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。

それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1

※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境を用意してサポートしてくれる部門がある方が良い訳です。

実践することは、いわゆる「作業」をコンピュータ化することであり、その分、エンジニアは創造的な活動に注力することが可能となります。きちんとしたレビューによるコード品質や設計品質の向上に費やしたり、自動テスト品質向上のための様々な工夫を行う活動に費やしたりすることが可能となります。

従来の(1990年代終わりぐらいまでの)ソフトウェア開発では、「作業」と「創造的な活動」がどちらも人の手で行われていることが多く、「作業」に起因する遅れが「創造的な活動」の時間を圧迫することも起きていました※2。言い換えると、「作業」部分をコンピュータ化することで、その開発組織はより「創造的な活動」に注力できることになります。技術力が高いとか低いとかは、この創造的な活動の内容や結果を指して言うのであり、継続的インテグレーションを行っていることを指したりはしません。

「作業」を今もって人の手による作業として行っているようなソフトウェア開発組織にとっては、冒頭に述べた事柄を実践しないことが、今日では「弱み」となります。

※2 たとえば、手作業によるリリースビルドでは、「良いと言うまで(ビルドが成功するまで)、帰宅しないこと」と指示されたりすることがよくあります。


スポンサーリンク





GDDフォンをSIP電話化 [その他]

2009年にもらったGDDフォンをSIP電話として使用できるように、FUSION IP-Phone SMARTに申し込みました。

FUSION IP-Phone SMART
http://www.fusioncom.co.jp/kojin/smart/

GDDフォンはAndroid 1.5ですが、SipDroid(http://sipdroid.org/)は対応しているため利用可能です。これで、いざという時は、GDDフォンで電話をかけることができます。月額基本料金は0円なので、実際に電話をかけない限り、費用は発生しないようです。