So-net無料ブログ作成
プログラマー現役続行 ブログトップ
前の10件 | -

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

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

フレームワークとして企業内における昇格時の昇格レポート(昇格論文)を例として挙げます。昇格レポートのフレームワークに関しては企業の特色が出てきます。たとえば、私が一番長く勤務した富士ゼロックス(および富士ゼロックス情報システム)では、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) 

『プログラマー現役続行』から11年 [プログラマー現役続行]

プログラマー現役続行 (技評SE新書)

プログラマー現役続行 (技評SE新書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2007/09
  • メディア: 新書

技術評論社の雑誌に書いた複数の記事をもとに、加筆・修正し、再構成して書籍にまとめて出版したのが2007年9月です。私がまだ47歳のときです。当時は富士ゼロックス情報システムで、開発部の部長をしながら同時に毎日C++でマルチスレッドプログラミングを行っていました。

「現役続行に必要な七つの力」として次の項目を挙げて解説しています。
  1. 論理思考力
  2. 読みやすいコードを書く力
  3. 継続学習力
  4. コンピュータサイエンスの基礎力
  5. 朝型力
  6. コミュニケーション力
  7. 英語力
現在は59歳で、今年の11月には60歳になります。1978年4月に九州工業大学情報工学科へ入学して、初めてコンピュータに触れ、Fortranでプログラミングを学んでから40年の歳月が流れました。

今日、上記の7つの力に追加するとしたら、「健康力」かもしれません。つまり、健康であることです。この歳になってくると、体の色々なところに問題が発生します。私自身も2018年は、体がガタガタという状態でした。痛風、両肩同時の五十肩、それに腰部脊柱管狭窄症と大変な一年でした。まだ、体はもとに戻っている訳ではありませんが、かなりよくなってはいます。

2017年8月にリコーを退職してからは、日々の仕事は自分でプログラミングを行うソフトウェア開発が中心となっています。メルペイでも、あるマイクロサービスの開発をGo言語で毎日行っています。ただ、『プログラマー現役続行』を書いた頃と比べると、かなり規則正しい生活を送っています。その頃は次のような生活を送っていました。
  • 残業や休日出勤してのプログラミング(開発部の部長でしたが、自分でもかなりプログラミングしていました)。
  • 週に数回の飲み会(とにかく部下とよく飲みに行っていました)
今は、全く違って
  • 残業せずに勤務時間内にできるだけ高い生産性を意識しながらプログラミングしています
  • 仕事の後の飲み会は不参加です
通勤時間が長いため7時30分頃に出社して、16時過ぎに退社しているのですが、それでも朝、家を出てから帰宅するまでに約13時間が経過しています。したがって、残業することはほとんどありません。仕事の後の飲み会は、だいたい19時か19時30分から開始なので、出席していたら、帰宅は翌日の時間になってしまうため、原則不参加です。金曜日に行っている技術教育(Go言語研修『Effective Java 第3版』研修)の後の懇親会や横浜Go読書会の後の懇親会は参加するので、全く飲んでいない訳ではありません。

今年はこの生活パターンを送りながら、仕事でプログラミングしながら健康で60歳を迎えられればと思っています。ちなみに、定年は65歳です。

コメント(0) 

書籍『Kubernetes in Action』 [プログラマー現役続行]

Kubernetes in Action

Kubernetes in Action

  • 作者: Marko Luksa
  • 出版社/メーカー: Manning Publications
  • 発売日: 2018/01/20
  • メディア: ペーパーバック

メルペイで5か月が過ぎました」でも書きましたが、今年の6月にメルペイ社に入社して読み始めたのが『Kubernetes in Action』です。メルペイ社では、Go言語を用いてマイクロサービスで開発していますが、各マイクロサービスはKubernetes上のPodとして動作します。

基盤としてKubernetesを使っているとはいえ、細かな設定などはSREチームが行っているので、細かな仕様を知っている必要はないのかもしれません。しかし、やはり使っている技術はきちんと学ぶのが基本ですので、どの本がよいかをAmazon.comで調べてこの本を選びました。ただし、出版元のManning PublicationsからPDF版を購入しました。

この本は大きく、3部から構成されています。
Part 1 Overview
Part 2 Core Concepts
Part 3 Beyond the Basics
Part 1は、導入部分であり概要が説明されています。Part 2では基本的な事柄が説明されています。Part 3は、どのような仕組みで動作しているかや、さまざまなリソースのチューニングなどが説明されています。

実際にテキストの指示に従って、Google Cloud Platform上にクラスタを構築しながら、手を動かして読み進めて理解を深めることができます。私自身は普段の開発に必要なさまざまなツールの設定はこの本の指示に従って行いましたし、日々の開発に必要とするKubernetesの知識もこの本で学びました。普段手に取って簡単に参照できるように、紙の本を会社で購入したのですが、紙の本は図が白黒なので、読むのにはPDFの方がよいかと思います。

前職のソラミツ社ではgRPCを用いた開発は多少しましたが、Backendのサービス開発は初めてと言ってもよいです。Fortranでプログラミングを初めて学んでから40年が過ぎましたが、ソフトウェアにはエンドレスに新たな技術が登場します。そのため、学び続けるのと、実際に作り続けることが必要な領域だと思います、

コメント(0) 

悪い癖、間違った思考・行動パターン [プログラマー現役続行]

私自身は、メンバーの業績評価を伴わないリーダーとしての立場から、メンバーの業績評価を伴うマネージャとしての立場、さらに開発部の部長という立場までさまざまな経験をしながら、ソフトウェア開発組織を作り上げることをどこかで意識してきました。働いてきたソフトウェア開発組織のほとんどは、毎年、新卒新人が入社して、彼ら彼女らを育成していくことが必要な組織でした。そのような経験をまとめたのが「ソフトウェア開発組織が持つべきカルチャー」です。そうは言っても、意識していたのは30代後半以降です。20代と30代前半は、そのような意識もなくソフトウェアを開発していました。

そして、私自身、ソフトウェアエンジニアとしてのさまざまな悪い癖は、自分自身で気付いて直してきました。当たり前だと思ってやっていたことが、後に、bad practiceと分かることがありますが、その場合には意識して直してきました。

しかし、私自身が長い年月を経て習得してきたことを、新卒新人に同じ年月をかけて習得させるのは非効率ですし、ひょっとしたら全く習得しないかもしれません。そのために、新卒新人の頃から変な癖や間違った思考・行動パターンにならないように指導してきました。

ソフトウェアエンジニアの変な癖やまた違った思考・行動パターンは、いつ身に付くかというと、新卒新人で入社した最初の会社です。それと同時によい習慣や正しい思考・行動パターンが身に付くもの最初の会社です。とくに前者の場合、一度身に付いてしまうと、組織を変わってもなかなか変えることが難しくなるのではないかと思います。

コメント(0) 

副業 [プログラマー現役続行]

最近は、企業が副業を解禁するしないという話題が目立つようになりました。今働いているメルペイ社では副業は禁止されていません。私自身は、技術雑誌の記事の執筆、技術書籍の翻訳、技術書の執筆などを2000年から副業としてやってきました。現在は、技術書籍の翻訳と企業向けの技術教育が中心です。

最初に副業を始めたのは富士ゼロックス情報システム社に勤務している頃で、就業規定に明確に兼業禁止規定がありました。しかし、技術系の活動に関しては、毎回社内で申請処理をする必要がありましたが、認められていました。

2008年9月にリコーへ転職したのですが、就業規則を何度読み返しても「兼業禁止規定」は書かれていませんでした。それでも、技術書の翻訳で社内申請をしようとしたのですが、当時の室長に「入社前からやっている活動であり、そのことは承知して採用しているし、申請するとそれを審査するために無駄に社内の工数が取られるので申請しなくてよい」と言われました。それ以来、リコー内では何も申請することなく、技術書の翻訳本を出したり、自分の本を出したりしていました。

リコーに勤務していた間には、頻度は年に1回程度でしたが新卒新人向けの技術教育を2社ほど他社向けにやっていました。1社は土曜日で、もう1社は有給休暇を取得してやっていました。これらは、最初だけ社内の申請を行いました。

2017年8月末で8年間勤めたリコーを早期退職しました。年齢的にも58歳に近くなっていたので、週4日勤務という条件でソラミツで働き始めました。それは、金曜日は個人で技術教育やコンサルティングなどの副業をする日に当てたかったためです。企業向け技術教育となるとどうしても平日ということになります。

今の若い人達は、ソフトウェア開発で副業をしている人も多いようです。私が20代から30代の頃は、そのような副業は不可能な時代でした。ソフトウェアを開発するには、会社に行かないとできなかった時代ですので、平日の夜とか休日にプログラミングの副業は無理でした。

今日のベンチャー企業やスタートアップ企業では、ソースコードコントロールやCIツールなどの多くがクラウドベースになっているため、自宅でもソフトウェアを開発できる時代になっています。

私の30代に同じ環境があってもソフトウェア開発での副業は無理だったかもしれません。当時は、朝7時に出社して12時間近く会社でソフトウェア開発をして、そして飲み会という日々だったからです。そして、休日出勤しない限り、土日にプログラミングすることはなかったので、休みには体を休めることができました。副業でお金をもらってソフトウェア開発をするには、若くても体調管理をしっかりとする必要があるかと思います。

コメント(0) 

デバッグを支える知識(3) [プログラマー現役続行]

以前、「デバッグを支える知識」として次の記事を書いています。
また、デバッグの科学的手法を「デバッグの科学的手法」で述べていますが、再度『ビューティフルコード』の第28章から引用すると以下の通りです。
1. プログラムの失敗を観察する
2. 観察と矛盾しない失敗の原因についての仮説を立てる
3. 仮説を使って予想する
4. 予想を実験でテストして、さらに観察する
 a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする
 b. 満たさないなら、別の仮説を立てる
5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。
この「仮説」を立てるために必要なのが「知識」です。バグに直面したときには、仮説を立てるために必要な知識が不足していても、今日ではある程度ネットで調べて補えます。しかし、本質的な知識の欠如は、デバッグを阻みます。

メルペイ社で働き始めて、私にとってはGCP(Google Cloud Platorm)やKubernetesは初めての経験です。そもそもAWSもほとんどやったことがないです。結果として数時間ではなく、数日の単位で行き詰まったデバッグが今までに3件ありました。3件とも解決はしましたが、最近経験した3件目は、ほぼ完全に行き詰まった状態で、それまでの状況を再度整理して社内のSlackで流したら、「○○をやってみたら」という返事があり、それで解決しました。
※ 1996年9月に日本オラクルに入ってからデータベースを勉強した経験に似ています。

解決してしまえば、現象を説明できる原因、それにもらった助言の意味を理解できたのですが、私自身は、現象から原因への仮説を立てるのがほぼ行き詰まっている状態でした。このような経験により仮説を立てるための知識が少し増えたことになりますが、やはり、1時間で解決したかった種類の不具合でした。

コメント(0) 

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

2018年6月1日にメルペイ社に入社(メルカリから出向の形態)して働き始めて5か月が過ぎました。

【仕事】メルペイが提供するサービスを構成するバックエンドのマイクロサービスの1つの開発を担当しています。開発言語はGo言語です。マイクロサービスが提供するAPIはgRPCベースですので、提供する機能の仕様をprotoファイルに書く作業をしばらく行っていました(「API仕様を書く」)。

最初から最終版のAPI仕様を書くことは不可能ですが、最初の仕様ができあがったので、テスト方法の検討と実装です。私が担当しているマイクロサービスは複数のマイクロサービスに依存しているので、どのようにe2eテストコードを書くかを検討しました。要件としては、以下の項目を最初に考えました。
  • 担当するマイクロサービスを起動して、gRPCを本当に呼び出してテストできること
  • 依存するマイクロサービスのgRPCを本当に呼び出すこと
  • 依存するマイクロサービスの振る舞いを、テストコードに記述できること(RPCが呼び出されたら、返すレスポンスをテストコードで記述できること)
  • テストを実行したら、担当するマイクロサービスのカバレッジが取れること
  • このe2eテストをCIで実行できること
これらの要件を満たす方法を検討・実装した後は、担当するマイクロサービスが提供する機能を実装したり、必要に応じたAPI仕様の修正したりといった開発業務を行っています。また、開発環境にデプロイされた後に、外部から疎通テストを行うテストの開発も行っています。

【学習】長年、デジタル複合機のコントローラソフトウェア開発に従事していて、組み込み系がほとんどだったので、使っているクラウド技術は全く初めてのものばかりです。基盤としてはKubernetesを使っているので、読むべき本をAmazonで自分なりに調べて、『Kubernetes in Action』を選びました。読みながら実際に手を動かして学習してきました(まだ全部は読み終えていません)。本に従って、開発環境を整備したり、Google CloudにKubenetesを設定しながら学習することできます。

Kubernetes in Action

Kubernetes in Action

  • 作者: Marko Luksa
  • 出版社/メーカー: Manning Publications
  • 発売日: 2018/01/20
  • メディア: ペーパーバック

【勤務時間】基本的に7時30分頃に出社して、16時過ぎには退社します。通勤時間は、往復で4時間を超えています。16時過ぎには退社するので、19時過ぎに行われることが多い各種イベント(社内向け、社外向け)に出席することはありません。

【副業】副業をそのものは禁止されていませんが、メルペイ社に入社前から行っていた以下の副業は続けています。
  • 技術書の翻訳
  • 講演や技術教育
技術教育に関しては、今年はリクルートテクノロジーズ社向けの「Go言語研修」が主です。『Effective Java 第3版』の翻訳原稿を用いたJava研修の補講もやりました。今後は、企業向けの「『Effective Java 第3版』研修」も予定しています。

コメント(0) 

ロック(ミューテックス)の再入可能性 [プログラマー現役続行]

Go言語で提供されているsync.Mutexは、再入可能(re-entrant)ではありません。それについては、『プログラミング言語Go』(p,306)には次のように書かれています。
Go のミューテックスが再入可能ではないことには正当な理由があります。ミューテックスの目的は、共有された変数のある種の不変式がプログラム実行中の重要な時点で維持されているのを保証することです。不変式の一つは、「共有された変数へアクセスするゴルーチンが存在しない」*2ですが、ミューテックスが保護しているデータ構造に特有の追加の不変式が存在するかもしれません。一つのゴルーチンがミューテックスロックを獲得したときには、そのゴルーチンは不変式が維持されていると想定するでしょう。ロックを保持している間に共有された変数が更新され、一時的に不変式が破られるかもしれません。しかし、ロックを解放するときには、秩序が回復されて不変式が再び維持されていることを保証しなければなりません。再入可能なミューテックスは他のゴルーチンが共有された変数へアクセスしていないことを保証するでしょうが、それらの変数の追加の不変式を保護することはできません。
*2 訳注:ゴルーチンがミューテックスロックを獲得する前の時点とそのロックを解放した時点で「共有された変数へアクセスするゴルーチンが存在しない」という意味です。この段落は、ミューテックスロックが獲得されていない場合の不変式について言及しています。
一方、Javaのオブジェクトのロック(モニター)は、再入可能です。つまり、同じスレッドが同じロックを複数回獲得できます。

私自身がマルチスレッドプログラミングを本格的に行ったのは、Solaris 2.3を用いていたFuji Xerox DocuStation IM 200の開発です。当時、Solaris 2.3で提供されていたC言語用のスレッドライブラリ(POSIX Threadが登場する前です)は、再入可能なロックは提供していませんでした。そのためデッドロックが発生すると、場合によってはC++のメンバー関数の分割を行ったものです。privateのロックを獲得しないメンバー関数と、ロックを獲得してprivateのメンバー関数を呼ぶpublicの公開用のメンバー関数へと分割します。この分割については、上記の『プログラミング言語Go』にも書かれています。

IM 200が商品化された後の1996年にJavaを学び始めた時に、ロックが再入可能だというのは非常に魅力的に思えました。Javaの影響を受けて、2000年に設計したC++用のスレッドライブラリ(「clibと呼ばれるライブラリー開発の思い出」)では、再入可能なロックを提供するCSynchronizerというクラスを用意しました。そのライブラリを用いた最初の商品開発では、オブジェクトを介してスレッド間で同期するという設計は行われていませんでしたので、再入可能であることはそれほど利点がありませんでした。

2003年から2009年に従事したコントローラソフトウェア開発では、clibを用いてマルチスレッドプログラミングをかなり行ったのですが、再入可能であるために起きる問題に悩まされて、マルチスレッドプログラミングの難しさを痛感したものです。幸い、その開発は完全なテスト駆動開発でしたので、「マルチスレッドプログラミングにおける重要な4要件」を満たしており、様々な問題を解決する経験を積むことができました。このソフトウェア開発で経験した問題は、『Effective Java 第3版』でJoshua Blochが述べていることそのものでした。
再入可能ロックは、マルチスレッドのオブジェクト指向プログラムの作成を単純化しますが、活性エラーを安全性エラーに変える可能性があります。

『Effective Java 第3版』(p.319)

活性エラーはデッドロックとして表面化しますが、安全性エラーはコードが動作しているように見えるが正しく動作していないという問題を引き起こします。特に競合状態(race condition)により引き起こされる問題は、現象の再現性も低く、調査が非常に難しいことが多いです。

2013年7月から2015年5月まで行ったコントローラソフトウェア開発は、私にとっては4回目のコントローラソフトウェア開発でしたが、マルチスレッドプログラミングの複雑さをGo言語のゴルーチンとチャネルで軽減できないかの検証も狙っていました。しかし、やはりデジタル複合機のコントローラソフトウェアは複雑であり、デッドロックはよく発生しましたし、競合状態も発生しました。幸い、Go言語には競合検出機能が提供されているので、その点は助かりました。

現在、従事しているソフトウェア開発では、再入可能性が問題となるような複雑なソフトウェア開発は行っていません。その点では、4回のデジタル複合機のコントローラソフトウェア開発は、私に貴重な経験を与えてくれたと言えます。

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

  • 作者: Alan A.A. Donovan
  • 出版社/メーカー: 丸善出版
  • 発売日: 2016/06/20
  • メディア: 単行本(ソフトカバー)

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)


コメント(0) 
前の10件 | - プログラマー現役続行 ブログトップ