API仕様を書く（まとめ）: 柴田 芳樹 (Yoshiki Shibata)
「API仕様を書く」として私自身の過去の経験を書いたものを読みやすく並べてみました。 API仕様を書く（1） API仕様を書く（2） API仕様を書く（3） API仕様を書く（4） API仕様を書く（5）ー gRPC protoファイル ー API仕様を書く（6）ー gRPC protoファイル（2） ー API仕様を書く（7） ちょうど同じような内容が『A Philosophy of Software Design』に書かれていました。 関連する章は、第12章「Why Write Comments? The Four Execuses」と第15章「Write The Comments First」です。第12章では、コメントを書かない理由として多くのソフトウェアエンジニアが挙げる理由について反証しています。第15章ではコメントを最初に書くことの有用性を説いています。ここでのコメントは、私
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
株式会社メルペイを退職します: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
バグの修正の前に再現テストを先に書く: 柴田 芳樹 (Yoshiki Shibata)
2003年以降、私自身のソフトウェア開発は、テスト駆動開発が基本です。ただ、私自身が開発せずに、指導やレビューを行ったテスト駆動開発もあります。 経験した中で大規模で技術的に複雑だったテスト駆動開発は、以下の二つです。 2003年2月から2009年8月：Linux/C++によるデジタル複合機コントローラソフトウェア 2013年7月から20015年5月：Linux/Goによるデジタル複合機コントローラソフトウェア 残念ながらどちらのプロジェクトも最終的なデジタル複合機製品とはなりませんでした。 コピー/スキャン/プリントなどの複合機※をテスト駆動開発でスクラッチから開発した経験やノウハウは、部分的にJaSST'18 Tokyoの招待講演とJaSST'19 Tokaiの特別講演で話しました。 ※ 今日のオフィスにある富士ゼロックスやリコーなどのデジタル複合機のソフトウェアは、ソースコードの量と
予約受付中『ベタープログラマ』（２）: 柴田 芳樹 (Yoshiki Shibata)
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック 作者: Pete Goodliffe出版社/メーカー: オライリージャパン発売日: 2017/12/15メディア: 単行本（ソフトカバー） 間もなく発売されますが、先日紹介した目次に加えて、アマゾンでは以下のように紹介されています。 プログラマとしてのキャリアをスタートすると、構文や設計を理解するだけでなく、その他の様々な事柄を理解し習得する必要があると気づきます。 本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。 はじめに、コード1行1行の書き方、デバッグやエラー処理、コードの改善方法など開発現場でのコーディングを取り上げます。 次にコードを単純に保つこと、コード変更やテスト、リリースなどソフトウェアを開発する際の考え方や心構えを扱い
通勤電車の書斎化（2）: 柴田 芳樹 (Yoshiki Shibata)
3年半前に「通勤電車の書斎化」を書いています。現在はどうなっているかというと、6社目となる現在の会社では、田園都市線（半蔵門線）で通勤するため、自宅の最寄り駅から始発（初電）の5時54分に乗車しています。 2駅で終点なので、そこで各駅停車に乗り換えます。この時間は確実に座れます。もっと遅い時間でも各駅停車には座れます。問題なのは、会社の最寄り駅までの間で、ノートPCを開いてどれだけ快適に作業ができる混み具合かということです。 田園都市線は混むことで有名ですが、遅い時間に乗車するとかなり混みます。そして、ノートPCを開いて作業ができるような状況ではなく、目の前の人がかなり近くまできます。つまり、座れても作業ができないのです。したがって、最寄り駅では始発に乗車します。そうすると、それほど混むこともなく、ノートPCを開いていても快適に作業できます。 電車内では、着脱式の覗き見防止フィルターを使っ
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
株式会社リコーを退職します（2）: 柴田 芳樹 (Yoshiki Shibata)
今日（2017年8月31日）がリコーへの最終出社日です。2009年9月1日にリコーへ入社してから、主に行ってきたことを簡単にまとめます。 【業務関連】所属した開発組織の業務として行ったものです。 技術教育：2010年に延べ500名以上のソフトウェアエンジニアに対して、「ソフトウェアエンジニアの心得」「テスト駆動開発」「C++」「API設計の基礎」などの教育を実施しました。しかし、「教育と場」でも書いたように、今から振り返ってみると、単に「教育をした」と「教育を受けた」ということだけが残り、私が教えた内容を実際の開発の現場で指導する人がいないため、開発組織としてのレベルアップにはならなかったと思います。 Jenkins導入：2010年10月から行ったものです。当時デジタル複合機内で動作するJavaの開発環境やインテグレーション環境は、私の視点からはあまりにもお粗末でした。それで、FXIS時代
株式会社リコーを退職します: 柴田 芳樹 (Yoshiki Shibata)
2009年9月から働き始めた株式会社リコーを8月31日付けで退職します。丸8年働いたことになります。現在57歳であり、定年退職までにはまだ2年と少しありますが、「セカンドキャリア制度」（早期退職制度のようなもの）の適用を受けて退職します。 8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。 翻訳本（8冊）：『アプレンティスシップ・パターン』『プログラミング原論』『Android SDK 開発クックブック』『プログラミング言語Goフレーズブック』『Objective‐C明解プログラミング』『APIデザインの極意』『Java SE 8 実践プログラミング』『プログラミング言語Go』 自著（2冊+α）：『ソフトウェア開発の名著を読む 【第二版】』『プログラマー”まだまだ”現役続行』『API設計�の基礎』 Jolt Award読書会
clibと呼ばれるライブラリー開発の思い出（１）: 柴田 芳樹 (Yoshiki Shibata)
2000年にclibと呼ばれるC++用のライブラリーを開発しました。それは、今でも富士ゼロックスのデジタル複合機で1000万行を超えるコントローラソフトウェア（＊）と呼ばれる制御ソフトウェアで使われているライブラリです。メモリ管理機構とマルチスレッドプログラミング機構を統合したようなC++のライブラリです。 （＊）http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html clibは、私がそのAPI仕様をすべて設計し、実装は他の優秀なエンジニア2名に行ってもらいました。API仕様には、防御的プログラミングも含めて、メモリ管理機構での細かな動作仕様も書いていました。 このライブラリに関して、忘れないうちに一連のブログ記事として書きたいと思います。しかし、記憶は嘘をつきます。したがって、事実とは異なった私の記憶の嘘が含まれているかもし
ソフトウェア開発組織が持つべきカルチャー（17）: 柴田 芳樹 (Yoshiki Shibata)
コードカバレッジを品質基準としない「API設計の基礎」の3.8節「コードカバレッジと防御的プログラミング」では、次のように述べています。 テストコードによるコードカバレッジは、そのソフトウェアの品質を担保しません。コードカバレッジが100%だから、品質が高いとは限りません。バグがあるコードでも、テストでコードカバレッジを100%にすることはできます。 ある機能を持つモジュールを開発する場合、そのモジュールのAPI設計が重要になります。APIの仕様には機能や使い方はもちろんのこと、不正なパラメータの場合の振る舞いが記述されていなければなりません（参考：「API設計の基礎」）。 そして、テストコードとしては、その仕様を検査するテストを書くことになります。①適切なAPI仕様、②それに基づく適切なテスト、そして実装です。実装がテストに合格したら、コードカバレッジを計測するわけです。コードカバレッジ
コードレビューの視点 018: 柴田 芳樹 (Yoshiki Shibata)
情報を付加しないコメントに注意するプログラミングにおいては日本語でプログラムを書くこと、つまりクラス名、メソッド名、変数名を日本語にしてプログラミングすることはまれだと思います。しかし、コメントを日本語で書くことは普通に行われています。そうすると、次のようなコードを目にすることになります。 // モデル情報を取得する Model m = config.getModelInfo() これはコードを読めば分かることを説明しているコメントに過ぎないのですが、日本語で書いてあるので何らかの情報を付加しているような印象を与えます。これを英語で書いたとしたら次のようになるでしょう。 // Gets the model info Model m = config.getModelInfo() 明らかに「同じこと」を二回書いていることになります。したがって、そもそもこのようなコメントは書かないわけです。
防御的プログラミング: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェア開発でのデバッグ効率を左右する要因は多くあります。長年、様々なソフトウェア開発を行い、デバッグに苦労していると、デバッグ効率を向上させるためどのようなことを行うと良いかを考えたり、書籍を通してヒントを得たりして、色々と工夫をするようになります。 デバッグ効率を向上させる方法の1つとして、防御的プログラミングがあります。防御的プログラミングでは、たとえば、メソッドのパラメータが正しい値であるかをきちんと検査して、不正であれば、例外をスローするということがあります。あるいは、switch文のdefaultラベルでは必ずAssertionErrorをスローするとかも一種の誤った設計に対する防御的プログラミングです。もちろん、呼ばれた側の設計上のバグであれば、それを検出してもAssertionErrorをスローしたりすると思います。これは、自分の想定している設計以外の状況が発生したらそ
防御的プログラミング（２）: 柴田 芳樹 (Yoshiki Shibata)
防御的プログラミングに関して、いくつか記事を書いています。 防御的プログラミング 防御的プログラミングとテスト駆動開発 防御的プログラミングしない後ろ向きの理由 防御的プログラミングしない後ろ向きの理由（２） 防御的プログラミングとカバレッジ 防御的にプログラミングするというのは、公開ＡＰＩの仕様にその内容を反映するということです。つまり、不正なパラメータが渡された時に、どのように振る舞うか（どのような例外をスローするかとか）を仕様書に記述する訳です。しかし、開発組織として防御的プログラミングの重要性を認識していない場合には、次のようなことが起きています。 開発者の多くが言葉としての「防御的プログラミング」を聞いたこともない。 ＡＰＩの仕様書には正常な場合の処理内容しか書かれておらず、不正なパラメータが渡された場合の振る舞いが何も記述されていない。 結果として、APIの実装コードでは不正パ
リファクタリングの勧め: 柴田 芳樹 (Yoshiki Shibata)
最近、コードレビューをしていて感じていることを、15年前に記事として書いていました。その記事は、「リファクタリングの勧め」（「Java PRESS Vol.12」、2000年5月、技術評論社）です。以下は、15年前に書いた内容をそのまま再現しています。 みなさんは、「リファクタリング（Refactoring）」という言葉を聞かれたことがありますか？私自身は、リファクタリングを意識するようになったのは、 Martin Fowlerの『Refactoring』注1を1999年の夏に読んでからです。それまでは、言葉としては他の書籍にも現れていたのでしょうが、貝体的に何を言っているのか深く考えることなく読んでいたのだと思います。今回は、私自身のフログラミングの経験を振り返り、Martin Fowlerの本の内容を簡単に紹介したいと思います。 プログラミング経験私が初めてプログラミングを覚えたのは、
アウトプット力が低下してきている？: 柴田 芳樹 (Yoshiki Shibata)
最近は、「検索の時代」になったため、大学でのレポートで、検索して、コピペして、仕上げる学生が多いのではないかと思います。確かに、大学で出される課題レポートであれば、検索して答えが見つかる可能性が高いと思います。しかし、企業内の文書作成では、そもそもネットで検索しても答えなどないものが多いです。たとえば、社内で作成されたソフトウェアフレームワークの仕組みを調べて、文書を作成する仕事が与えられたとして、ネットでは検索できません。 そうなると、フレームワークを調べる能力に加えて、それを分かりやすく文書にすることができないとだめです。しかし、残念ながら、そのような文章作成を学生時代行っていないため、レビューで「こんなことから指摘しなければならないのか」と思う低レベルの日本語の指摘もしなければなりません。例としては、「話し言葉」と「書き言葉」の違いとかです。たとえば、「機器へコマンドを送信する」では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
伸ばすのが難しい能力（２）: 柴田 芳樹 (Yoshiki Shibata)
第4期Java 8研修が終了しました: 柴田 芳樹 (Yoshiki Shibata)
書籍『変革の軌跡』: 柴田 芳樹 (Yoshiki Shibata)