So-net無料ブログ作成

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) 

テスト駆動開発の経験(6) [プログラマー現役続行]

4年ほど前に「テスト駆動開発の経験」と題して記事を書いています。
1978年に大学でプログラミングを始めてから、(「テスト駆動開発の経験(1)」に書いてあるように)2003年まで、私自身はテスト駆動開発を経験したことがありませんでした。

1990年代までのソフトウェア業界では、自動実行するテストを書いて資産として残していく習慣はありませんでした。手作業によるテストと目視確認というのが普通に行われていたのがソフトウェアのテストでした。テストコードが書かれたとしても、テストコードを手作業で実行し、目視確認が終わったら捨てるということが行われていました。実際、同じようなことを、Martin Fowler、Robert Martin、Joshua Blochが、それぞれ『リファクタリング』、『Clean Code』、『Coders at Work プログラミングの技をめぐる探求』の中で述べています。

テスト駆動開発は、それ以前のソフトウェア開発とはやり方が異なっていたために、地道に意識した努力を行っていく必要がありました。主なものを列挙すると以下の通りです。
  • 「テストファースト」で先にテストコードを書く習慣。そのためには、事前にAPIをきちんと設計する習慣
  • 不具合が発生した場合に、必ず再現テストを書いてから修正する習慣
  • CIが失敗していたら、その調査に最優先で取り組む習慣
2003年に始めたテスト駆動開発は、対象が(コピー、プリンター、FAXなどが搭載されている)デジタル複合機のコントローラソフトウェアであり、処理が非常に複雑なソフトウェアでした。私の経験から、デジタル複合機で最も複雑な実装は、コピーやプリントを行っているときの「割り込み」機能です。そして、「割り込み」は今日ではおそらく誰も使わない機能です。

メルペイ社でbackendエンジニアとして行っているソフトウェア開発は、もちろんテスト駆動開発で行っています。私自身、それ以外の手法は考えられません。今から考えると、1990年代まで、手作業でテストを行っていたことが信じられない感じです。

コメント(0) 

総閲覧数が累計で700万を超えました [総閲覧数]

スクリーンショット 2019-01-18 6.09.41.png
総閲覧数が700万を超えました。600万から700万は13か月でした。ブログを始めたのが2004年12月13日からですので、ほぼ14年が経過したことになります。

コメント(1)