So-net無料ブログ作成
前の10件 | -

Kindle版『Effective Java 第3版』 [Effective Java 第3版]

Effective Java 第3版

Effective Java 第3版

  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: Kindle版

出版当初は、電子版としてDRMフリーではありませんが、PDF版がリリースされていました。Kindle版についても新たにリリースされました。ただし、以下の制約があります。
  • リフローではなく固定レイアウトで、文字列のハイライトや検索、辞書の参照、引用などの機能が使えない
  • 紙の本の第1刷と内容は同じであり、紙の本で見つかっている誤りは修正されていない(正誤表はこちらです)。



スポンサーリンク




コメント(0) 

FORTRANから始まって41年(10) [プログラマー現役続行]

教育を行う能力

能力というよりも、ソフトウェアエンジニアとして経験した方がよいのが、技術教育です。教えることの長所はいくつかあります。
  • 教えるためには、技術を理解する必要がある
  • 教えることで、技術を理解できる
当然のことながら、ある技術を教えるためには、自分自身で理解する必要があります。一方で、受講生からの質問に答えるために、深く考えたり、調べたりたりすることで、教えている技術を深く知ることになります。

現在、私自身が行っている技術教育は、Go言語研修『Effective Java 第3版』研修です。以前は、Java言語研修も行っていましたが、現在は行っていません。富士ゼロックス情報システムおよびリコーに勤務していた頃は、以下のような教育も行ってきました。
  • ソフトウェアエンジニアの心得
  • A Quick Tour of C++
  • テスト駆動開発
  • 書籍『プログラミング作法』の第1章と第2章
  • デザインパターンや設計原則
各内容の説明は省略しますが、私自身は、技術教育担当の組織に属していたわけではなく、ソフトウェア開発組織に属していることがほとんどでした。

技術教育で難しいこと

技術教育の中で難しいのでは、受講生からの質問に適切に答えることです。つまり、以下のことを行える必要があります。
  1. 聞かれた質問から、本当は何を知りたくて質問しているかを引き出すこと
  2. 質問者および他の受講生の技術的知識がどこまであって、どこから説明するのが良いかを考えること
Java言語研修やGo言語研修では、事前にテキストの指定された範囲を読んで疑問点を質問表に記入してもらうのですが、本当は何を知りたいのかについては、研修当日に質問者に聞かないと分からないことが多いです。

質問の意図が理解できたとしたら、どのように説明すれば理解してもらえるかを、その場で考える必要があります。そのためには、説明の基礎となる知識を質問者や他の受講生が知っているのかをまず聞くこともあります。たとえば、「O表記(O Notation)が分かりますか?」、「CPUとメモリはどのように接続されていますか?」、「スタックとは何ですか?」とかの質問をすることがあります。それは、質問に対する回答を理解するために必要だからです。

そして、よくあるのが、質問の回答を説明する前に私自身が質問をすることで、話が脱線することです。たとえば、Go言語ではゴルーチンのスタックが自動的に伸長するのですが、それに関する質問を受けると、「スタックとは何ですか?」「スタックにはどのような情報が保存されるのですか」「他の言語ではスレッドのスタックの大きさはどのくらいですか?」「他の言語ではスタックサイズが固定長なのはなぜですか」などと聞き返してから、私が発した質問に対する回答の説明を始めてしまうからです。一通り説明が終わってからGo言語に戻ると、「スタックが伸長することがどれだけ画期的か」という話題に戻る訳です。


スポンサーリンク





コメント(0) 

FORTRANから始まって41年(9) [プログラマー現役続行]

若手人材を育成していく能力

私自身は、37歳になるまで若手の人材を育成することには、ほとんど関心を持っていませんでした。どちらかと言うと、「レベルが低いエンジニアにプログラミングさせるな」という考えが強かったです。私自身の考えが変わったのは、日本オラクルに転職してからです(「40代最後の年」)。

若手の人材、特に新卒新人で入社してきた若手のエンジニアに対しては、最初の数年できちんと育成する必要があります。それは、単に目の前の開発業務ができるようにさせるという意味ではありません。今回、この一連の記事で書いている基礎知識の習得や、さまざまな習慣や能力の獲得を行うように指導する必要があります。

したがって、「若手を育成する能力」というのは、ある程度ソフトウェア開発の経験を積んでから伸ばすように思われますが、実際には2年目からある程度経験を積むことが可能です。つまり、最初の1年での経験をもとに指導を行うというものです。ただし、「きちんと」指導できる範囲は狭いと思います。そのため、本人も成長過程であることを認識しておく必要があります。

育成をあきらめることもある

一人のソフトウェアエンジニアとしては、上司が自分を育成してくれると期待するのは間違っています。自分自身の成長は、自分自身の努力の結果であり、上司はその成長のための努力を後押ししてくれたり、サポートしてくれたり、指導してくれたりするだけです。矛盾しているようですが、一方でソフトウェアエンジニアとしては、若手を育成していくことも求められます(「ソフトウェア・スキル・インデックス」)。

しかし、現実には育成をあきらめる場合もあります。以下のような場合です。
  1. 若手に対して、さまざまな指導や教育を行った結果として、伸びる見込みがないと判断した場合
  2. 学習することをやめってしまった中堅のエンジニアの場合
1.に該当するケースはめったにありませんが、残念ながら私自身が途中で育成を断念したことが2回あります。半年以上の指導や教育を行った結果として断念するのですが、その後の対処は難しいです。その若手の面倒を誰かがみることで開発チーム全体の生産性が低下してしまう状況なので、開発チームから外す必要があります。

講演や教育で「新たな技術を学習しない中堅エンジニアはどうやったら変わってもらえるでしょうか?」と質問されることが多いのですが、私の回答は上記の2.に該当します。つまり、「あきらめる」ということです(詳しくは、「ソフトウェアエンジニアの成長カーブ」を参照してください)。


スポンサーリンク





nice!(0)  コメント(0) 

FORTRANから始まって41年(8) [プログラマー現役続行]

テスト設計能力

今までの41年間を振り返って、十分に学習して実践できていないと思うのは、ソフトウェアのテスト設計です。もちろん、テスト駆動開発を行っていますので、テストコードを書いていないということはありません。

ソフトウェアのテスト設計は、品質工学的な視点を持って行う必要があるのですが、あまりきちんと学んで実践して来なかったというのが正直なところです。組み合わせ爆発を回避して効率よくテストを行うということに関しては、Hayst法がありますが、それもきちんと経験・実践することなく今日に至っています。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

  • 作者: 吉澤 正孝/秋山浩一/仙石太郎
  • 出版社/メーカー: 日科技連出版社
  • 発売日: 2007/07/26
  • メディア: 単行本

書いたコードの品質を担保するために、経験のある先輩にレビューしてもらうように、テスト設計もきちんと経験がある専門家に指導を受けるのが、自己流になるのを避けるのによいと思っています。

10年以上前のことですが、当時マルチスレッドプログラミングによる複雑なシステムをテスト駆動開発で開発していたのですが、テスト設計として正しいのか、何か問題がないかという視点で助言をもらうために、私が部門長だった開発部で、秋山さん(上記の本の共著者)に指導を受けたことがあります。そして、行っているテストを説明したら、テスト設計が間違っているし、使うべきテスト設計手法が違っているという指摘を受けたことがあります。そして、指導に従ってテストを修正したらバグが見つかったという経験があります。

障害分析

テスト設計に加えて、障害を分析する活動も重要です。障害ごとなぜ発生したのかを分析して、どのような原因で発生している障害が多いかを整理して、対策を検討する必要があります。

障害分析というと、プロジェクトが終わった後に、振り返り的に行う組織が多いと思います。しかし、そのような障害分析では、効果的な改善はできないことが多いです。主な理由は以下の通りです。
  • 障害の真の原因を知るには、障害対応した担当者からヒアリングする必要があるが、以前に行った障害対応なので、担当者が思い出せないことがある。
  • 担当者は次のプロジェクトにすでに従事しており、障害分析のために時間を割り当てることができない。
障害分析は、開発中に始める必要があります。そして、開発組織(あるいは、開発チームやグループ)自身が行う必要があります。そうでなければ、上記の問題で、きちんとした障害分析ができないし、対策の検討を行い、開発中に対策の実施までを行って効果を見るというサイクルを回すことができません。障害分析は、プロジェクトの最初から行う必要はありません。障害がある程度の数、発生してから始めてよいです。そして、実際に分析を始めると、分析に必要な情報が不足していることに気づくことがあり、次に障害が発生したときに追加の情報を収集して分析に加えるというサイクルになります。

残念ながらこのように障害分析を行っている開発組織は少ないと思います。障害分析もきちんとできるようになるまでは、それなりのレビューや指導を受ける必要があります。幸い、私自身は、10年以上前に、上記の書籍の共著者である吉澤さん(現在は、品質工学会の副会長)から指導を受ける機会があり、私が部門長をしていた開発部で一年ほど指導を受けていました。

nice!(0)  コメント(0) 

FORTRANから始まって41年(7) [プログラマー現役続行]

テスト駆動開発の実践

開発対象のソフトウェアのテストを自動テストで行うテスト駆動開発の経験については、過去にまとめて書いています(「テスト駆動開発の経験(6)」「不具合が発生した場合、必ず再現テストを書く」)。

「テスト駆動開発」という言葉が登場したのが、41年間の経験の後半に入ってからです。そして、本格的にテスト駆動開発を行うようになったのが、2003年からです。それだけ、ソフトウェアを手作業でテストする時代を長く経験したことになります。そして、2003年から経験したテスト駆動開発は、単に自動でテストするというだけでなく、テスト対象がマルチプロセス構成で、各プロセスがマルチスレッドで構成されているという非常に複雑なシステムでした。

テスト駆動開発を経験・実践することは、簡単なようでも、実は所属している開発組織によっては困難な場合があります。テスト駆動開発を実践していない開発組織では、すべてのテストが手動による目視確認になります。そして、そのような開発組織では、開発しているソフトウェアは製品やサービスのソフトウェアだけのこと多いです。そして、手作業でテストをするため、開発全体のコストがそれなりに高かったりします。

このような開発組織では、追加の自動テストコードを書いて、それらが動作するような何らかのフレームワークを作成したり、既存のレガシーコードを自動テスト可能になるように修正したりすることは、「余分な追加の開発コスト」とみなされて、却下されたりします。このような開発組織では、テスト駆動開発を実践して経験を積むことは困難な場合が多いです。テスト駆動開発を導入することをマネージャや開発部門のトップ(場合によっては年配のエンジニア)に対して説得しようとして、納得されずに徒労に終わってしまうことも多いのではないでしょうか。

私個人は、私自身が部門長という権限を持っている立場の時にテスト駆動開発を推進し、実際に自分で経験できました。しかし、若い人達がテスト駆動開発の経験を積むための近道は、「きちんとテスト駆動開発をしている開発組織で働くこと」です。

しかし、テスト駆動開発といっても、単に単体テストを書いているだけでインテグレーションテストは書かれていないとか、何らかのモックライブラリを使いすぎて意味のないホワイトボックステストだらけになっているような組織があったりもしますので、注意が必要です。

また、「マルチスレッドプログラミングにおける重要な4要件」で述べているような要件が求められるテスト駆動開発を行っている開発組織を見つけてそこで働くことは非常に難しいと思います。なぜなら、そこまで必要なソフトウェア開発を行っている組織が少ないと思うからです。たとえば、現在メルペイ社でbackendエンジニアとしてマイクロサービスを開発していますが、「マルチスレッドプログラミングにおける重要な4要件」が求められるような複雑なソフトウェア開発ではありません。これは、おそらく多くのウェブサービス開発に当てはまると思います。

コメント(0) 

FORTRANから始まって41年(6) [プログラマー現役続行]

読みやすいコードを書く能力

大学時代、読みやすいコードを書くことの重要性は残念ながら教えてもらってはいないです。私自身も読みやすさに意識して注意を払い始めたのは、いつの頃かは思い出せないですが、おそらく『Code Complete』の初版や『Practice of Programming』を読んだ頃だと思います。

CODE COMPLETE (Microsoft Programming S.)

CODE COMPLETE (Microsoft Programming S.)

  • 作者: Steve McConnell
  • 出版社/メーカー: 日経BP社
  • 発売日: 1998/04/04
  • メディア: ペーパーバック

Practice of Programming, The (Addison-Wesley Professional Computing Series)

Practice of Programming, The (Addison-Wesley Professional Computing Series)

  • 作者: Brian W. Pike, Rob Kernighan
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 1999/02/04
  • メディア: ペーパーバック

読みやすいコードを書くことに関しては、「継続した学習(3)」で書いていますので、そちらを参照してください。

コメント(0) 

FORTRANから始まって41年(5) [プログラマー現役続行]

きちんとしたAPI仕様の作成能力

API仕様を書く」でも述べていますが、振り返ってみると、ソフトウェアエンジニアとしては、プログラミングできることに加えて、書いているソフトウェアのAPI仕様をきちんと書く能力を身に付けることも重要です。

きちんとAPI仕様を書く際には、次の視点が求められます。
  1. そのソフトウェアを使う人達が提供される機能を理解し、間違いなく正しく使えるかという視点
  2. 将来保守する人達の理解を助けるという視点
1. は機能の説明だけでなく、防御的プログラミングの視点を盛り込んだ仕様が書かれている必要があります。2. は説明するまでもなく、将来保守する人達が仕様を理解できる必要があります。

仕様が書かれていない場合、作られたソフトウェアは技術的負債となります。そのようなソフトウェアの仕様を理解するには、実装のコードを読んで理解する必要があります。ライブラリやマイクロサービスのAPIであれば、不正なパラメータを伴う呼び出しがどのようなエラーを返してくるかを理解するために、実装のコードを読んで理解する必要があります。そして、時間をかけて理解したことは、実は間違っているかもしれまん。

実装を読んでコードを理解したとしても、しばらくすると忘れてしまい、再度コードを読む必要があるかもしれません。もっと悪いのは、仕様に書かれていないために、いつの間にか、返って来るエラーの種類が増えていたりすることもあります。

返済が非常に困難な技術的負債

技術的負債の中で返済するのが極端に難しいのが、「API仕様が全く書かれていないソフトウェアのAPI仕様を書くこと」です。これは技術的に難しいというのではなく、担当者の能力的に難しい部類の技術的負債です。
  • API仕様をきちんと書く訓練を積んで来なかったため、そもそも技術的負債であると認識していない。
  • 結果として、API仕様を書くモチベーションが担当者にないため、負債を返済するのは苦痛であり、本人の中では優先順位が低い。その結果、「時間が取れたら」と言い訳しても、本人の中では優先順位が低いため、決して「時間を取らない」という結果になる。
  • 「技術的負債を返済したい」とエンジニアが言ったとしても、悪い設計の変更やひどいコードの修正だけが技術的負債の返済だと思っている人が多い。API仕様書は本人にとっては優先順位が低いことから、技術的負債の対象になっていなかったり、対象となっていても優先順位が低いため、結果として返済されることはない。
開発の最初からきちんとAPI仕様を書くことは、ソフトウェアエンジニアが身に付けるべき習慣であるべきです。最初に書いていれば、開発中に必要に応じて修正することは容易です。

2009年9月にリコーに転職して以来、さまざまなソフトウェア開発の現場でAPI仕様のレビューをしてきましたが、きちんとAPI仕様を書いている人達に会ったことはほとんどありません。

コメント(0) 

FORTRANから始まって41年(4) [プログラマー現役続行]

継続的な学習習慣

ソフトウェア技術は、発展し続けているため、非常に興味が尽きない領域です。そのために継続して学習を続ける必要があります。継続的な学習習慣の重要性については、何度も述べている(継続的学習)ので、ここでは別の視点で話をします。

本の買いすぎに注意

新たなソフトウェア技術に興味を持って学習する、あるいは今使っている技術を深く知るために学習するときに、私自身は書籍を購入することがほとんどでした。技術書の電子版を購入できるようになったのはいつ頃だったか思い出せませんが、2009年ぐらいまでは紙の本を購入していました。

紙の本、電子版のどちらであっても、新たな技術を学び続ける上での問題点は、本を買いすぎることです。読むつもりで技術書を購入するのですが、結局ほとんど読まなかった技術書の数の方が、読んだ技術書の数よりも圧倒的に多かったと言えます。つまり、読まない本に多くのお金をつぎ込んだことになります。

どうしても積ん読になってしまうのは避けられない側面がありますが、もう少し何とかならなかったかなと思っています。技術書によっては、購入したときに読まないと、数年後には内容が古くなってしまうものも多く、結果として読まないで処分してしまうことになります。

また、紙の本を持っておいくためには物理的な空間を必要とします。そのため、ときどき書斎にある書籍を処分することになります。若い頃は将来読むだろうと思ってとっておくことが多かったです。しかし、60歳を目の前に控えて、今は「本当に将来読むのか?」と考えて、読まない本は処分するようにしています。もちろん、もう一度読まないと分かっているが処分しない本もあります(たとえば、今では入手できない学生時代の技術書、自分の本、サイン本などなど)。

みなさんも、買いすぎには注意してください。

今はどうしているか

メルペイに入社してからは、とりあえず日々の開発のために手元に置いておきたい本は会社で購入してもらっています(その結果、退職時に持ち帰る必要もありません)。英語の技術書に関しては、Safariに会社で契約してくれており、多くの技術書を読むことができます。

コメント(0) 

FORTRANから始まって41年(3) [プログラマー現役続行]

コンピュータ・サイエンスの基礎

九州工業大学 情報工学科でコンピュータ・サイエンスを学んだと言っても40年も前のことです。ハードウェアの基礎的な事柄、CPUの仕組み、コンパイラ、データ構造とアルゴリズムといったものを学びましたが、オペレーティングシステムについては何を学んだのかあまり記憶にありません。

※ 今日の九州工業大学には「工学部」(戸畑)や「情報工学部」(飯塚)などがありますが、当時は戸畑にしかキャンパスはなく、学部もありませんでした。当時の情報工学科に相当する学科は、現在の工学部にはありません。

日本では、大学でコンピュータ・サイエンスを学ぶことなく、プログラミング言語やウェブシステムの作り方を学んで、ソフトウェア業界に入ってくる人達が多いように感じます。その上で、何らかのシステムを開発する経験を積んだり、そのために必要な知識を学んだりするのでしょうが、コンピュータがどのように動作しているのかを全く知らない人達が多いのではないでしょうか。

たとえば、前職のソラミツ社では、面接(面談)で「macOSやWindows上ではさまざまアプリケーションが同時に多数動作しますが、マルチコアとは言え、CPUコアは数個しかないですよね。どうやって同時に多数のアプリケーションが動作しているのか説明してください」、「ハッシュテーブルを説明してください」、「スレッドとプロセスの違いを説明してください」、「O表記(O-notation)を説明してください」など聞いたりしていました。

このような質問に答えられなくても、ソフトウェア開発はできます。その結果、コンピュータ・サイエンスの基礎的な事柄を学ぶことなく、ソフトウェアの開発経験年数を積み上げることになります(「許される無知の範囲は開発経験年数に反比例する」)。

私自身は、すべての知識を大学で学んだ訳ではありません。社会人となってから学習したものも多いです。学習と言っても、独学というよりは勉強会という形式で行ってきたものが多いです。自分自身が学習するというよりも若い人達に学習してもらうという意味で過去に行った勉強会で使った書籍を紹介します。

ハードウェアに関する知識

Introduction to Computing Systems: From Bits & Gates to C & Beyond (Computer Engineering)

Introduction to Computing Systems: From Bits & Gates to C & Beyond (Computer Engineering)

  • 作者: Yale N. Patt
  • 出版社/メーカー: McGraw-Hill Education
  • 発売日: 2003/08/05
  • メディア: ハードカバー
この本は、トランジスターから始まって、前半はCPUの仕組みを学ぶ内容となっており、後半はC言語がどのようにコンパイルされて実行されるのかを解説しています。富士ゼロックス情報システムに勤務していたときに、新卒新人に強制的に勉強会を行った本で、読み終えるのに2年を要しました。日本語には翻訳されていません。今年、第3版が出版される予定です。

この本の勉強会は2年も要したので1回しか開催していないのですが、当時私が属する事業部(富士ゼロックス情報システム)に配属された新卒新人全員に、英語の本ですが必須で学習させました。

コンピュータの構成と設計 第4版 上 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

コンピュータの構成と設計 第4版 上 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

  • 作者: デイビッド・A・パターソン
  • 出版社/メーカー: 日経BP社
  • 発売日: 2011/11/17
  • メディア: 単行本

コンピュータの構成と設計 第4版 下 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

コンピュータの構成と設計 第4版 下 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

  • 作者: デイビッド・A・パターソン
  • 出版社/メーカー: 日経BP社
  • 発売日: 2011/11/17
  • メディア: 単行本

この2冊は、リコーに勤務していたときに、読書会として読んだ本です(「『コンピュータの構成と設計』勉強会終了しました」

オペレーティングシステム

Understanding the Linux Kernel: From I/O Ports to Process Management

Understanding the Linux Kernel: From I/O Ports to Process Management

  • 作者: Daniel P. Bovet
  • 出版社/メーカー: O'Reilly Media
  • 発売日: 2005/11/27
  • メディア: ペーパーバック

富士ゼロックス情報システムに勤務していたときに、月に1回土曜日に読書会を開催して読みました。読み終えるのに3年を要しました。

Linux Kernel Development (Developer's Library)

Linux Kernel Development (Developer's Library)

  • 作者: Robert Love
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2010/06/22
  • メディア: ペーパーバック

この本は、私自身は初版、第2版、第3版と読んだ本です。第2版は富士ゼロックス情報システムのとき、第3版はリコーのときに社内の読書会で読んでいます。日本語には翻訳されていません。

データ構造とアルゴリズム

プログラミング作法

プログラミング作法

  • 作者: Brian W. Kernighan
  • 出版社/メーカー: KADOKAWA
  • 発売日: 2017/01/30
  • メディア: 単行本

この本は、第2章の「アルゴリズムとデータ構造」をきちんと学んでもらうために、強制的に新卒新人に学ばせた本です。基本的に私が作成した「勉強会ノート」に沿って、そこに書かれている説明ポイントに解答してもらい、その解答をレビューして、解答が不十分であれば差し戻ししたりして学習してもらいました(「書籍『プログラミング作法』」)。

富士ゼロックス情報システムに勤務していたときは、私の部門に配属された新卒新人は(派遣の新人も含めて)、必ず学習させていました。また、リコーに勤務していたときは、2年間でしたが、私が属している開発本部に配属された新卒新人は、学習が必須とされていました。

いつ学ぶべきか

コンピュータ・サイエンスの基礎的な事柄は陳腐化しないので、今日では、できるだけ若い時学んでおくべきだと思います。そうすれば、その後のソフトウェアエンジニアとしてキャリアを積んでいくための基盤になります。

コメント(0) 

FORTRANから始まって41年(2) [プログラマー現役続行]

新たなプログラミング言語への取り組み

ソフトウェア業界は停滞することなく、常に発展してきました。さまざな問題を解決するために、さまざまなプログラミング言語が登場してきましたし、これからも登場してくると思います。登場するすべてのプログラミング言語に取り組み、スラスラとその言語でコードを書けるようになるのは難しいと思います。したがって、私を含めて、多くのソフトウェアエンジニアは、書いたことがあるとしても、スラスラと書ける言語とそうではない言語に分かれると思います。

スラスラと書ける言語は、日々のソフトウェア開発で使ってきた結果として、指が自然と動くということです。そして、日々のソフトウェア開発で使うプログラミング言語は、バイブル本(「プログラミング言語のバイブル本と言語仕様」)を通してきちんと学ぶべきです(あるいは自己学習すべきです)。その理由としては、以下のことが挙げられます。
  1. 毎日使っているプログラミング言語なので基礎知識があり、読むためのハードルが低い
  2. 毎日使っているといっても、実際のソフトウェア開発では、そのプログラミング言語の機能をすべて使うことはない(「業務を通した学習の落とし穴」)。バイブル本の学習を通して、自分が使っていない機能を学習できる。
  3. 毎日使っているプログラミング言語をバイブル本を通してきちんと学ぶことにより、他のプログラミング言語を学ぶ際に、きちんと学んだプログラミング言語との対比ができるようになる。
1. に関しては、説明する必要はないかと思いますが、基礎知識の量によっては、バイブル本の内容が難しかったり、あるいは知っていることだったりします。

2. に関しては、自分が知らない機能があることが多いです。たとえば、今日の多くのプログラミング言語にあるリフレクションですが、業務でリフレクションを使ったプログラミングをしたことがない人は、「リフレクション」という言葉やその機能を知らなかもしれません。『プログラミング言語Java第4版』や『プログラミング言語Go』などのバイブル本では、リフレクションにそれなりのページ数を割いて説明しています。逆に初心者本では扱われない機能です。

3. に関しては、一つのプログラミング言語をきちんと学ぶことで、他の言語の機能を理解する際に、すでに学んだ言語との対比ができることで、理解が容易になることがあります。

言語によって学習時間が異なる

バイブル本を学ぶといっても、言語によってはその学習に要する時間が変わってきます。Javaであれば、学習の最終目標が『Effective Java 第3版』の内容を全部理解することとすると、以下の書籍を全部読まないと理解できません。
これらの書籍の学習には練習問題にも真剣に取り組んで一年は要します(「Java研修」)。その意味で、初心者が『Effective Java 第3版』をいきなり読んで理解することはできません。

一方、『プログラミング言語Go』であれば、練習問題にも真剣に取り組んでも半年で終わります(「Go言語研修」)。ただし、130問以上ある練習問題の多くは、今日のウェブ技術(HTTP、JSON、Restful API、etc)をある程度知っていることが前提となっており、プログラミングの初心者には難しい内容となっています。

一度読んでも意外と覚えていない

新たなプログラミング言語を学ぶためにバイブル本を読んだとしても、一度読んだだけだと、その内容を意外と覚えていなかったり、あるいは忘れたりしています(ひょっとしたら私自身が歳をとったためなのかもしれませんが)。

たとえば、技術書を翻訳する場合、原著を読みながら日本語に訳していきます。そして、日本語訳を見直すために何度か読み直します。これだけでも、最低でも3、4回は読んでいることになります。さらに書籍によっては、翻訳前に原著の英語の草稿をレビューするために読んでいます。たとえば、『プログラミング言語Go』は、原著の英語の草稿をレビューするために2回読んで、気づいた点や誤りなどを著者達にフィードバックしています。これだけ読んでいても、社内で毎週月曜日に行っている読書会では、忘れていた内容を思い出すことがあります。

一度読んだ技術書をもう一度一人で読み直すのは難しいと思いますので、その場合には、社内(あるいは社外)で読書会を開催して読むとよいかと思います。

新たなプログラミング言語を学ぶときはバイブル本を読む

仕事で使うのではなく、趣味で使うのであれば、手っ取り早く初心者本やウェブの記事で新たなプログラミング言語を学んで試してみてもよいかと思います。しかし、仕事で使うプログラミング言語は、時間がかかっても、きちんとバイブル本を読むようにしてください。仕事で使う技術に関しては、きちんとした技術書で学ぶ習慣を身に付けないと、ソフトウェア開発を何年経験していても、中途半端なソフトウェアエンジニアになってしまいます。

コメント(0) 
前の10件 | -