SSブログ

書籍『The Go Programming Language』(5) [golang]

The Go Programming Language (Addison-Wesley Professional Computing Series)

The Go Programming Language (Addison-Wesley Professional Computing Series)

  • 作者: Alan Donovan, Brian Kernighan
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2015/11/09
  • メディア: ペーパーバック

この本の出版が明らかになった今年3月には8月発売とされていましたが、3か月遅れの11月発売です。すでに印刷に入っているのではないかと思いますので、もう延期されることはありません。

この本は、英語の原稿段階で本全体をレビューした本としては、私にとって5冊目になります。今回は、約4か月のレビューでしたが、私自身も学ぶことが多かったです。本の謝辞(Acknowledgments)に自分の名前を見るのは、正直、嬉しいものです。

通常、謝辞はレビュー対象にならず、最後の最後に筆者(達)が書くことが多いです。そのため、最終版の本を見るまで、誰がレビューしたのかは分からないです。この本の謝辞を見ると、いかに多くの人達が関わったが分かります。Java関連の著名人もいたりして、ちょっとびっくりします。

この本の日本語版は、来年の春になるのではないかと思います。

リファクタリングの勧め [プログラマー現役続行]

最近、コードレビューをしていて感じていることを、15年前に記事として書いていました。その記事は、「リファクタリングの勧め」(「Java PRESS Vol.12」、2000年5月、技術評論社)です。以下は、15年前に書いた内容をそのまま再現しています。

Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2012/03/09
  • メディア: Kindle版

みなさんは、「リファクタリング(Refactoring)」という言葉を聞かれたことがありますか?私自身は、リファクタリングを意識するようになったのは、 Martin Fowlerの『Refactoring』注1を1999年の夏に読んでからです。それまでは、言葉としては他の書籍にも現れていたのでしょうが、貝体的に何を言っているのか深く考えることなく読んでいたのだと思います。今回は、私自身のフログラミングの経験を振り返り、Martin Fowlerの本の内容を簡単に紹介したいと思います。

プログラミング経験

私が初めてプログラミングを覚えたのは、1978年4月に九州工業大学情報工学科に入学して、プログラミングのコースで習ったFORTRANでした。単科大学であったため、一年生からプログラミングを含む専門科目がありました。大学および大学院での6年間を通して、FORTRAN、Pascal、PL/I、APL、Z80アセンブリ言語、Forth等を使ってプログラミングを行い、社会人になってから今日までに、C、Mesa、 C++、Javaでフログラミングを行ってきました。社会人になってから仕事としてソフトウェア開発に従事してきたのですが、一方で、自分に必要なツールも開発してきました。

プログラムの読みやすさ

開発が遅れていたあるプロジェクトのソフトウェアのソースコードの一部を見る機会があったのですが、プログラミングの経験が10年以上ある人が書いたとは信じられないような、プログラムの読みやすさや保守性はあまり考慮していないソースコードでした。同じような例、つまり、プログラミングの経験年数がある人が書いているにもかかわらず、デザインの悪い、読みにくいソースコードを見かけることは多いです。

1999年に、延べ250人以上のソフトウェアエンジニアに対してコードレビューに関するガイダンスを実施し、その中で次のような質問をしてきました。
  1. 今まで、「自分が書いているコードを他の人が読んで理解できるか」を意識してプログラミングをしてきましたか?
  2. 今まで、他人が書いたコードのパグ修正や保守作業で、プロクラムが読みにくいために苦労したことはありますか?
1.で「はい」と答えた人は1割以下で、2.で「はい」と答えた人は9割以上でした。つまり、 自分では他人が続めるかどうか気にしないでプログラミングしているにもかかわらず、他人のプログラムが読めなくて苦労したと回答する人がほとんどだったのです。

私自身を振り返ってみますと、最初から読みやすく、変更が容易なソースコードを書けたのではありません。特に、製品向けに開発したコードは、「動作するJことが優先であり、読みやすさや保守性は、プロジェクトとして注意を払うことがない場合がほとんとでした。一般に多くのソフトウェアエンジニアは、仕事でのプログラミング経験しかない場合が多いと思います。その結果、「自分が理解できて、動作すればよい」として、動作しているプログラムを書き直した経験が少ない人が、ほとんどではないでしょうか。

読みやすいコードを書くことの重要性については多くの本に取り上げられています。代表的な本としては、Steve McConnellの『Code Complete』注2があります。最近の本では、Brian KernighanとRob Pikeの『The Practice of Programming』注3があり、最初の一章をプログラミングスタイルに費やして,読みやすさの必要性を説いています.

プログラムを書き直す

「他のソフトウエアエンジニアと私自身とで、何が異なっていたのか」と考えたことがあります。そのとき気づいたのは、社会人になってから、自分自身の開発環境を改蓄するために多くのツールを自分自身で開発し社内に配布してきたことです。さらに、単なるツールの開発だけであれば、それほど珍しくはないかもしれませんが、同じツールを何度も書き直してきた経験が異なっていたと思っています。

新しいプログラミング手法を学んだらそれを適用して書き直したり、機能を追加する際にデザイン変更を行ったほうが追加が容易と判断した場合には,動作しているコードを捨ててでもデザインを変更したりしてきました。仕事で開発したソフトウェアでも、ある程度はこのような修正は行った終験はありますが、ツールでの経験が圧倒的に多かったと思います。

自分て作成したツールでも全体で数万行にもなると、とても隅々まで記憶しておくことはできません。ときどきエンハンスやパグ修正を行い、さらに何年も保守をしなければならないので、自分自身でも読めない、理解できない、エンハンスが困難なコードであっては困るのです。したがって、エンハンスやパグ修正を行う都度、自分自身の理解を助けるために、プログラムのデザインを変更して改良を行いました。このような書き直しにより、プログラムが読みやすくなり、パグの修正や機能の追加が容易になっていったのです。また、私自身は、このようなツールの作成と書き直し作業で実に多くの事柄を学んできました。たとえば, C言語でsetjmp/longjmpライブラリはツールでしか使用したことはありません。おそらく.動作しているプログラムを何度も何度も書き直す経験をしているソフトウエアエンジニアは少ないと思われます。

Don’t Live with Broken Windows

そのような経験が少ないためか、多くのソフトウェアエンジニアは、プログラムのデザインをどのように変更すれば良くなるかについての知識そのものを持っていなかったりします。英文月刊誌『Java Report』のEditor's NoteでDwight Deugoは、「Refactoring and Optimization」注4と題してその中で次の通り述べています。
リファクタリングと最適化は、しばしば忘れられてしまいますが、重要な活動です。忘れられるには理由があります。開発者から私が聞く理由は、「時間がない」です。しかし、私はその理由を信じてはいません。本当の理由は、「知識がない」からです。もし、どこが悪く、どうすれば良くなるか、どうすればもっと保守が容易になるか、どうすればもっと早く動作するかをあなたか知っていれば、そのように修正するでしょう。そうではありませんか?
つまり、知識がないためにプログラムを良くすることができないと言っているのです。

「悪いデザイン、間違った決定、ひどいコードをそのままにしておくと、さらにそのプログラムは悪くなっていく」とAndrew HuntとDavid Thomasは、その著書『Pragmatic Programmer』注5の中で述べています。建物や路上の車の窓ガラスが割られて、それを修理することなく放置しておくと、さらに窓ガラスが割られて、状況が悪くなると述べています。

同様に、どんなにきちんと設計/コーディングされたソフトウェアでも、一旦誰かが悪いデザ’インやひどいコードを入れはじめたら、そのソフトウェアはどんどん悪くなっていくので、そのような悪いデザインやコードを見つけたら、無視することなく修正するのがプログラマの心得だと説いています。つまり、「Don’t Live with Broken WindowsJ (窓ガラスが割れたままに放置しておくな)と言っているのです。

◇ ◇ ◇

みなさんは、時間がないという理由で、妥協しながら、読みにくい、悪いデザインのコードを書いた経験はありませんか注6。ソフトウェアの機能を拡張する際に、割れた窓ガラスで増築するのではなく、すでに割れた窓ガラスを新しい窓ガラスと取り替える方法を知って、その上で増築する必要があります。そのためには、取り替える方法を知っていなければなりません。そのような方法を書籍としてまとめたのが、Martin Fowlerの『Refactoring』です。

(・・・書籍『Refactoring』の紹介部分は省略・・・)

注1) Martin Fowler, 『Refactoring. lmproving the Design of Existing Code』, Addison-Wesley,1999, ISBN 0-201-48567-2
注2) Steve McConnell、『Code Complete: A Practical Handbook of of Software Construction』、Microsoft Press、1993、ISBN1-55615-4844。翻訳本『コードコンブリー卜』、ISBN 4-7561-0210-7、マイクロソフトプレス
注3) Brian W. Kernighan、Rob Pike、『The Practice of Programming』、Addison-Wesley、 1999、ISBN 0-201-61586-X
注4) 『Java Report』、Volume 5、Number l (2000年1月号)、SIGS Publications
注5)Andrew Hunt、David Thomas、『The Pragmatic Programmer: from iourneyman to master』、Addison-Wesley、1999、ISBN 0-201-61622-X
注6) 実際には、何が良いデザインかを知っていなければ、悪いデザインのコードを書いていると認識することはできませんが。

書籍『プログラミング原論』予約受付中 [本]

プログラミング原論

プログラミング原論

  • 作者: アレクサンダー ステパノフ
  • 出版社/メーカー: 東京電機大学出版局
  • 発売日: 2015/11/10
  • メディア: 単行本(ソフトカバー)

2010年にピアソン桐原から出版され、その後、絶版になった『プログラミング原論』が、東京電機大学出版局から再出版されます。再出版に際して、原著の正誤表をすべて反映しています。また、著者による「日本語版の読者へ」が新たに追加されています。

5年前に出版された『プログラミング原論』は、こちらです。

プログラミング原論

プログラミング原論

  • 作者: アレクサンダー ステパノフ
  • 出版社/メーカー: ピアソン桐原
  • 発売日: 2010/12/24
  • メディア: 単行本(ソフトカバー)


書籍『The Go Programming Language』(4) [golang]

The Go Programming Language (Addison-Wesley Professional Computing Series)

The Go Programming Language (Addison-Wesley Professional Computing Series)

  • 作者: Alan Donovan
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2015/11/23
  • メディア: ペーパーバック

発売まであと3か月を切りましたが、この英語版を使用した社内教育を検討しています。英語のテキストでの社内教育を実施したことはないですが、今の時代、そのくらい行ってもよいかと思っています。

プログラミング言語の社内教育をする場合、内容だけでなく、練習問題がどれだけあるかが重要となります。Java研修で使用している『プログラミング言語Java第4版』やJava 8研修の『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』では、100問以上の練習問題があり、受講生はプライベートの時間に練習問題のプログラミングに取り組みます。

では、このAlan DonovanとBrian Kernighanの共著である『The Go Programming Language』にはどれだけのプログラミングの練習問題があるかということになります。以下が、各章ごとの練習問題の数です。

Chapter 1 Tutorial (12問)
Chapter 2 Program Structure(5問)
Chapter 3 Basic Data Types(13問)
Chapter 4 Composite Types(14問)
Chapter 5 Functions(19問)
Chapter 6 Methods(5問)
Chapter 7 Interfaces(18問)
Chapter 8 Goroutines and Channels(15問)
Chapter 9 Concurrency with Shared Variables(6問)
Chapter 10 Packages and the Go Tool(4問)
Chapter 11 Testing(7問)
Chapter 12 Reflection(13問)
Chapter 13 Low-Level Programming(4問)

全部で135問であり、妥当な数の練習問題だと思います。ただし、やさしい問題もありますが、難しい問題も多いです。

教育コースを実施する上で、一番の問題は、受講生に求めるスキルレベルです。テキストの内容と練習問題を見ても、明らかにプログラミングの初心者向けではありません。何らかのオブジェクト指向プログラミング言語の知識や経験がない人には、難しいかもしれません。

社内研修を行うとしても、予習と練習問題のプログラミングは、すべてプライベートの時間に行うというJava研修と同じ形式になるでしょうから、そもそも、テキストが英語で、業務で使用していないプログラミング言語の研修にどれだけ応募者があるかは、ちょっと疑問です。

第23期Java研修を開講 [プログラミング言語Java教育]

私にとって、通算第23期になるJava研修を今日から開講します。研修の定員は12名なのですが、今回は受講生は11名です。ただし、今回は、2拠点(晴海、秋田)をインタラクティブ・ホワイトボード(http://www.ricoh.co.jp/iwb/)とUnified Communication System(http://www.ricoh.co.jp/ucs/)で常時接続しての研修となります。

残念ながら、Java 8ベースに衣替えすることなく、今回もテキストは、従来通りです。『プログラミング言語Java第4版』『Effective Java第2版』、それに、拙著『Java 2 Standard Edition Tiger』です。内容としては、Java 5.0ベースとなります。