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

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) 

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

1978年4月、大学一年生で初めてのプログラミングをFortranで学びました。それから、今月末で丸41年が過ぎたことになります。今と違って当時は、プログラミングは大学の計算機センターに行かなとできませんでした。当時の九州工業大学の計算機センターは、幸いパンチカードではなく、TSSTime Sharing Systemの端末を使ってプログラミングできました。でも、自分の学科(情報工学科)のさまざまなコースの演習は違っていました。

コンパイラの授業では、パンチカードを使ってPL/Iでプログラミングしました。パンチ室が3階で、計算機室が4階だったので、自分が書いたコンパイラのコードである7百枚ぐらいのパンチカード(つまり、700行のソースコード)を持って3階と4階を行ったり来たりして、デバッグして完成させました。

CPUの内部を学習する授業では、APLで動作が記述されている英語の教科書でした、その授業の最終課題は当時の情報処理技術者試験のアセンブリ言語をAPLで書けるようにする一種のDSLの作成でした。APLには130個以上の演算子があり、計算機センターのAPL端末で苦労しながら演算子を探して課題を仕上げました。

「コア」メモリの計算機を使った実験演習もありました。アセンブリ言語でプログラミングするのですが、プログラムは手書きで紙に書きます。そして、それを手作業で変換して(人間アセンブラー)16進数の機械語にして、手書きで紙に書きます。その紙に書かれた16進数の機械語をコアメモリの計算機のパネルスイッチを使って、2進数で1命令ずつ手作業で入力するものでした。

大学4年から大学院修士課程の2年生までは、HOLENETと呼んでいたローカルネットワークシステムをハードウェアの作成から通信プロトコルの作成までを行い、8ビットCPUである、Z-80のアセンブリ言語でプログラミングしていました。

41年の間、さまざまなソフトウェア開発に従事し、一人のソフトウェアエンジニアという立場だけではなく、開発のマネージャや開発部門の部門長などを経験してきました。そして、今は、一人のソフトウェアエンジニアとしてソフトウェア開発に従事して、Go言語で毎日開発しています。昨年6月にメルペイ社へ入社以来、開発に従事してきたあるマイクロサービスも本番運用され始めます。私にとっては、人生で初めてのウェブサービスです。

この41年間を振り返ってみると、特定の技術知識とは別に、以下のことが重要だと思います。
  • 新たなプログラミング言語への取り組み
  • コンピュータ・サイエンスの基礎
  • 継続的な学習習慣
  • きちんとしたAPI仕様の作成能力
  • よみやすいコードを書く能力
  • テスト駆動開発の実践
  • テスト設計能力
  • 若手人材を育成していく能力
  • 教育を行う能力
  • 文書作成能力
  • 英語能力
そして、今日技術的知識として知っておく必要があるのは、以下のものであり、現在の私に不足している部分です。
  • ウェブ関連の技術
  • DB/SQL関連の技術
過去の私のブログの内容や拙著『プログラマー”まだまだ”現役続行』と内容が重なる部分はあるかと思いますが、上記の項目について、振り返ってみて思うことを、これから書いていこうと思います。


スポンサーリンク





コメント(0) 

『A Philosophy of Software Design』 [本]

A Philosophy of Software Design (English Edition)

A Philosophy of Software Design (English Edition)

  • 出版社/メーカー: Yaknyam Press, Palo Alto, CA
  • 発売日: 2019/01/22
  • メディア: Kindle版

この本は、ソフトウェアの複雑さ(complexity)を減らすために、ソフトウェアエンジニアが日々の開発で注意を払うべきことが述べられています。その多くのは、さまざまな書籍で述べられている基本的な事柄です。しかし、それらの基本的な事柄は、習得するのが容易ではないものが多いです。

たとえば、『リーダブルコード』を読むだけで読みやすいコードが書けるようになるのではなかったり、『Effective Java』を読むだけできちんとしたAPI設計ができるようにならなかったりするのと同じです。読んで学んだことを意識して実践し、当たり前となるまで繰り返していく必要があります。

この本を読んで、その内容を実践してみようと思うのか、もう当たり前に行っていることだと思うかは、読み手の経験によって変わってくると思います。この本の中で、私自身は意識して実践しているが、多くのソフトウェアエンジニアができていないと思うことが「Chapter 15 Write The Comments First」です。副題として、「Use Comments As Part Of The Design Process」と書かれています。その導入部分には、次のように書かれています。
Many developers put off writing documentation until the end of the development process, after coding and unit testing are complete. This is one of the surest ways to produce poor quality documentation. The best time to write comments is at the beginning of the process, as you write the code. Writing the comments first makes documentation part of the design process. Not only does this produce better documentation, but it also produces better designs and it makes the process of writing document more enjoyable.
Chapter 15, “Write the Comments First”
John Ousterhout, “A Philosophy of Software Design

API仕様を書く」でも書いていますが、最初に仕様を書くことは、それが当たり前になるまで意識して自分で自分自身を訓練するか、指導してもらうかのどちらかでない限り、身に付かない習慣だと思います。

私が知る限り、残念ながら、この本は日本語へは翻訳されないようです。

コメント(0) 

プログラミング言語のバイブル本と言語仕様 [プログラマー現役続行]

技術書に掲載されているサンプルコードを読んだり、オープンソースのソースコードを読んだりしているときに、「あれ、このような書き方ができるのかな?」と疑問に思える書き方を目にすることがあると思います。そのような場合、そのプログラミング言語のいわゆるバイブル本か、公式の言語仕様を調べて、書き方が許されることを確認する必要があります。

言語仕様は分かりにくいために、最初はバイブル本を調べます。Go言語の場合、『プログラミング言語Go』です。そこにも記載が見当たらない場合には、言語仕様「The Go Programming Language Specification」を調べることになります。この書き方はメモリモデルに関して問題はないのかなと疑問に思った場合、メモリモデルに関しても、『プログラミング言語Go』にある程度書いてありますが、詳細は「The Go Memory Model」に書かれていますので参照することになります。

※ メモリモデルは、言語仕様の一部と考えるべきです。Java言語の場合、公式の『The Java Language Specification』の「17.4 Memory Model」に記述されています。

今日では、あるプログラミング言語を学ぶために、どの本がその言語のバイブル本であるかを調べて、バイブル本から学習を始める人が少なくなっているような気がします。その結果、手元にバイブル本はなく、もっぱらネット検索で得た知識だけでプログラミングしている人が増えているのではないでしょうか。

結果として、ある書き方ができるか否かを調べるのはもっぱらネット検索だけであり、英語が読めなければ、日本語になっていない言語仕様を調べることはないでしょう。あるいは、ネットの情報だけに頼ってしまい言語仕様やメモリモデルを間違って解釈してしまうかもしれません。

一般にバイブル本には最低限これだけは知っていて欲しいことが書かれていますが、すべての言語仕様が網羅されるわけではありません。したがって、バイブル本は読んでおいて、必要なときに言語仕様(やメモリモデル)を調べる習慣を身に付けることは遠回りのようですが、優秀なソフトウェアエンジニアになるための近道だと思います。

コメント(1) 

書籍『入門 監視』 [本]

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者: Mike Julian
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

私自身は、backendのサービスを開発し、それが実際にデプロイされるのを経験するのはメルペイでの開発が初めてです。監視というのは以前には経験していないため、本書を読みました。

原著は、『Practical Monitoring』ですが、日本語版ではタイトルが『入門 監視』となっています。残念ながら、監視の経験不足からくるのだと思うのですが、本書の後半は、内容がピンとこない項目が多かったです。

細かな詳細は省きますが、以下の章から構成されています。
  • 1 章 監視のアンチパターン
  • 2 章 監視のデザインパターン
  • 3 章 アラート、オンコール、インシデント管理
  • 4 章 統計入門
  • 5 章 ビジネスを監視する
  • 6 章 フロントエンド監視
  • 7 章 アプリケーション監視
  • 8 章 サーバ監視
  • 9 章 ネットワーク監視
  • 10 章 セキュリティ監視
  • 11 章 監視アセスメントの実行
  • 付録A 手順書の例:Demo App
  • 付録B 可用性表
  • 付録C 実践 監視SaaS

「1 章 監視のアンチパターン」と「2 章 監視のデザインパターン」は、監視をする上で基本的に認識しておくべきことが書かれています。

残りの章は、全体的に個々の項目を深掘りしているというよりも浅く広く必要なことを述べているのですが、私自身は経験がないためかピンとこないものが多かったです。私のような全くの初心者は、監視の経験と知識がある人と一緒に読みながら、補足や解説をしてもらいながら読むと理解が深まるのではないかと思います。

コメント(0) 

メルペイで9か月が過ぎました [プログラマー現役続行]

前回の「メルペイで5か月が過ぎました」から4か月が過ぎました。10か月目に入ったわけですが、メルペイを含めた7社の中では5番目に長い勤務期間となります。

この4か月は、backendエンジニアとして、あるマイクロサービスの開発を担当しているので、そのAPI仕様の作成、テストコードの作成、機能実装、不具合の再現テストと修正(「不具合が発生した場合、必ず再現テストを書く」)、あるいは、API仕様の変更とそれに伴うテストコードや機能実装の修正といったソフトウェア開発を行っています。

2月に非接触決済サービス「iD」に対応したiOS/Androidアプリケーションがリリースされ、私も会社支給のiPhoneでスマホ決済を行っています(個人としては、今もガラケー)。今月には、「コード決済」のリリースが予定されています。このようなサービスの立ち上げ前から開発に関われたのは、幸運だったと思います。

振り返ってみると、1984年から社会人となって、これまでに関わった商品開発の多くで(日の目を見なかったプロジェクトも含めて)、それらの開発プロジェクトの当初から参加していることが多かったです。

メルペイでのサービス開発は今後も続きますが、今年は「プログラマーとして現役を続行」できそうです。

昨年の6月に入社した時の社員数は分かりませんが、それ以来、毎月社員が増えています。そして今も、さまざまなエンジニアリング領域で人材を募集しています

コメント(0) 

文書の指導(2) [プログラマー現役続行]

前回の記事「文書の指導」では、文書をチェックして修正させるためには、「部下と上司の関係の上で成り立つ行為」と述べていますが、社外へ公開する文書についても、チェックして修正させる部門や部署があるわけです。何もチェックされることなく、社外へ公表されることはないかと思います。

一方、昔と違って今日では、技術系のTech Blogを書くことを社員に推奨して、自社のサイトで公開する企業が多くなっています。そのような技術ブログの場合、どのようなチェック体制なのかは、企業によって異なっているのではないかと思います。たとえば、Tech Blogを公開する前に必ずビューを行う担当者や組織があったり、マネージャによるチェックおよび承認が必要であったり、本人任せになっていたりとさまざまだと思います。開発組織がフラットであれば、Slackの専用のチャネルを通して、誰ともなくレビュー依頼を出してレビューしてもらうのかもしれません。

私自身、一人のソフトウェアエンジニアとして、勤務時間はほぼプログラミングを行っています。富士ゼロックスグループやリコーで行っていたような、作成された文書をチェックして修正を指導する部下は持っていません。私自身は楽ですが、その一方で思うのは、まわりの若手のソフトウェアエンジニアの人達は、指導を受けて、文書を書くスキルを伸ばす機会が得られないまま年を重ねていくのではないかということです。同じことが、「API仕様を書く」で述べた事柄に関しても当てはまります。

コメント(0) 

文書の指導 [プログラマー現役続行]

ソフトウェアを開発する際には、プログラミングしてコードを書くことに加えて、さまざまな文書を書きます。文書を書く上で、読み手が理解できるか否かを考えることは重要なのですが、自分では理解できるだろうと思っても、実際には理解しにくことがあります。また、作成する文書によっては、書き方のフレームワークがあることがあります。

フレームワークとして企業内における昇格時の昇格レポート(昇格論文)を例として挙げます。昇格レポートのフレームワークに関しては企業の特色が出てきます。たとえば、私が一番長く勤務した富士ゼロックス(および富士ゼロックス情報システム)では、QCストーリ的な組み立てが求められていました。それは、以下のような骨格です。
  • 担当業務の説明
  • 課題(問題)は何か
  • 課題の原因を分析
  • 改善策の検討
  • 改善策の実施結果と効果
  • 残された課題に対する今後の方針
大枠はこのような感じで、課題は2つは書く必要がありました。そして、これらをA4の2ページに論理的にまとめる必要がありました。すべての昇格でこのようなレポートを書くことが求められていました。昇格の種類によっては面接も行われますし、レポートだけで判断される場合もあります。

当然、昇格ごとに、レポートを作成して、上司にチェックしてもらい、提出締切のギリギリまで修正を行うことになります。一方、上司の立場からすると、最初は部下に任せて書かせて、その後、さまざま指摘をしながら、何度も修正させます。

当時、このような昇格レポートの作成やチェック、それに審査は面倒だなと思っていました。しかし、振り返ってみると本人にとってはかなりよい文書作成のトレーニングになっていたと思います。そのことを痛感したのは、リコーに勤務していたときです。

リコーでは富士ゼロックスと異なり、昇格ごとにレポートを書く必要がなく、管理職になるまでに2回しかレポートを書かない人事制度になっていました。私自身は昇格の審査をしたことはありませんでしたが、事業部内で昇格の面接練習の面接官として、何度か昇格レポートを読んだことがあります。しかし、そのほとんどがQCストーリ的な論理建てがほとんどなく、私にとっては分かりにくいレポートが多かったです。

技術者であれば技術レポートを書くことも多いと思います。技術レポートも上司からチェックしてもらい、第三者が読んでも理解できるものにしていくことが重要です。チェックして修正させるのは、昇格レポートと同様に、「部下と上司の関係の上で成り立つ行為」ではないかと思います。私自身も、開発の部門長や開発グールプのリーダーをしているときは、技術レポートもかなり手直しさせていました。

私自身がいつもきちんとしたものを書けるわけではありませんが、文章を書く訓練ができていない若手のエンジニアが指導される機会もなく、年齢を重ねると、指導する側になることもなく成長しないのではないかと思います。Wikiに書く簡単なまとめから、さまざまな文書まで、第三者が読んで誤解なく理解できるかに関して指導を受けていく必要があると思います。そして、自分自身で一歩下がって、自分が書いた文章を第三者が理解できるかを意識して見直していく必要があります。

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

不具合が発生した場合、必ず再現テストを書く [プログラマー現役続行]

ソフトウェアを書いて、手作業でテストする手法とは異なり、テスト駆動開発ではいくつかの規律が求められます。その中で、「テスト駆動開発の経験(6)」で述べたことの一つが「不具合が発生した場合、必ず再現テストを書く」です。

不具合への対処は次のようなステップとなります。
  1. 不具合が発生した際に、その原因を調査します(「デバッグの科学的手法」)
  2. その不具合を再現させるテストを作成します(不具合が存在するために失敗するテストです)。
  3. テストが失敗するのを確認します。
  4. 不具合の原因を取り除いて修正します。
  5. テストが成功するのを確認します。
マルチスレッドプログラミングでは、原因の調査および再現テストを書くことが非常に困難な場合があります(「マルチスレッドプログラミングにおける重要な4要件」)。その場合の再現テストは、普通の再現テストとは異なる工夫が必要になります(詳細については別の機会に書きたいと思います)。

テスト駆動開発をしていても、原因が分かった時点で再現テストを書くことなくコードを修正する衝動にかられて、コードを修正してしまう開発者も多いのではないでしょうか。実際、再現テストのコードの量よりも、不具合の修正コードの量の方が圧倒的に少ない場合があります。

資産としてのテストを蓄積していくことはテスト駆動開発では重要であり、すべての蓄積されたテストを実行することで、テストがカバーしている範囲の機能が正しく動作しているという安心感が得られます。もちろん、テストに抜け漏れがあるから不具合が見つかるわけですから、新たに見つかった不具合に対して再現テストを書いてさらにテスト資産を蓄積するわけです。その場合、見つかった不具合の再現テストに加えて、類似の原因の不具合があることが分かれば、追加の再現テストも作成して、コードを修正することになります。

再現テストの作成をスキップしがちな場合、意識して再現テストを書く努力をして、「不具合が発生した場合、必ず再現テストを書く」習慣を身につける必要があります。

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