読者です 読者をやめる 読者になる 読者になる

鎌玉のよしなしごと

日々のよしなしごとをつぶやいているだけ。由無し言(とりとめもない話)か、良しな仕事(nice job!)かは、あなた次第。

第7回とくしまOSS勉強会 柴田芳樹さん講演メモ

遅くなりましたが、3/20(金)に開催された 第7回とくしまOSS勉強会 の講演内容のメモについて記します。
年度末の忙しい時期ということもあり、出席できなかった人も多く、当日キャンセルされた方もおられましたので、このメモで何らかの知見を共有できれば幸いです。
なお、自分なりの解釈が入っていて、元の内容の真意をくみ取れていないことがあると思われますので、ご注意ください。

下記の書籍のリンクには、株式会社はてなAmazonアフィリエイトが埋め込まれています。*1
柴田さんのサイト 柴田 芳樹 (Yoshiki Shibata):So-netブログ から購入いただくと、売上の一部が柴田さんに回りますので出来れば購入時はそちらをご利用下さい。
また、出版社からDRMフリーの電子書籍が出ている書籍もありますので、DRMフリーの書籍を探す方は DRMフリーのIT系電子書籍販売サイト一覧(日本語版)を参照してください。

講師の柴田芳樹さんについて

柴田芳樹さんは、『Effective Java』『APIデザインの極意』などの技術書を翻訳されていることや、『プログラマー“まだまだ”現役続行』等の著書やブログにおいて「ソフトウェアエンジニアとしての心得」を説かれていることで高名な方です。

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)

スタッフとして参加した DevLOVE四国2013というIT開発者を対象としたイベントで、講演者を決める際に候補者として柴田さんの名前が挙がったことがあります。
柴田さんは、 オープンセミナー2011@香川( オープンセミナー2011@香川(2):柴田 芳樹 (Yoshiki Shibata):So-netブログ ) で講演されていて、その講演がたいへん面白かったとのことが理由です。
そのときは、同じ開催地(DevLOVE四国2013も高松)での再演となるのが難点となり、別の方々(Oracleの寺田佳央さんたち)に講師を依頼しました。

しかし、柴田さんのブログは時々読んでいて、一度お話をお伺いしたいと常々思っていました。
今回、とくしまOSS普及協議会の事務局から講演者の要望を聞かれたときにお名前をお出ししていて、運良く話を聞ける機会をいただけました。


ちなみに柴田さんは、かつてJustsystem*2に勤務されていて、徳島に住まれていたことがあります。
Justsystem時代は、100% Pure Javaアプリケーション『一太郎Ark』*3の開発などに携われていたとのことです。

ソフトウェアエンジニアの心得

一人前になるには10年

ソフトウェアエンジニアとして一人前になるには何年かかるかとの問いかけに対して「10年を要する」という言葉が引用される。
しかし、漫然と10年を過ごすのでは無く、10年の間、継続的に学んで実践していることが必要。
普通の人は2,3年で仕事を覚えて、そのときの知識のまま、仕事を続けてしまう。
仕事の内容が変わらないのならば、それで通用するが、継続的な学習をしていかない限り、ソフトウェアエンジニアとしての仕事は続けていけない。

最近のソフトウェア開発ツールでは、リファクタリング機能など便利な機能がついているので、積極的に使っていくべき。
そして、エンジニアは、もっとクリエイティブな部分に集中すべきである。
それは、ソフトウェア設計である。

読みやすいコードを書く

ソフトウェアエンジニアの責任は何年も使われ続けるビジネス資産を作り出すことである。
何年も使われ続けるビジネス資産となるのは読みやすく保守しやすいコードである。
読みづらく保守できないコードは、資産ではなく、いつまでも不具合が消えず、機能の追加・変更もできない負債である。
初心者だからと言って、汚いコードを書くことが許される訳ではない。
【筆者参考リンク】 技術的負債 - Qiita

そこで、重要となるのがコーディング標準である。
理解しやすく統一されたスタイルのコードを書くために必要となる。

自分しかメンテナンスできないコードを書いていたら、そのプロダクトを他の人に引き継げず、新しいプロダクトに関わることができなくなり、結果的に自分のキャリアパスを狭めることにも繋がる。
【筆者注】プロダクトよりもフレームワークの流行/廃りのサイクルが短くなっていると感じられる今日において、1つのプロダクトを抱え込むよりも多様なプロダクトに関わって経験を積んだ方が現役ソフトウェアエンジニアとしてのキャリアを詰めるなぁと感じました。

読みやすいコードを書くための参考文献『レガシーコード改善ガイド』

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコードとは、テストのないコードである。
ネーミングは設計の中心である。
【筆者参考リンク】翻訳書「レガシーコード改善ガイド」の注目トピック:CodeZine(コードジン)

時間が経つとコードは腐り、品質は低下する。
コードに手を入れるときは、必ず綺麗にすることを心がけることが大切である。
具体的には、変数名を実態にあったものに変更したり、大きすぎる関数を分割したり、判定文を再設計したりする。
継続した改善こそが、プロとしての本質的な部分ではないでしょうか?

論理的思考

バグは、自然に消えてしまうことはない。
バグは、原因から論理的に説明しなければダメ。
デバッグするときは、まず仮説を立てること。
※ただし、知識がないと、キッチリした仮説は立てられない

継続した学習

ソフトウェア業界で取り残されないようにするには、常に学習していくこと。
ソフトウェア技術は3~5年で古くなる。

学習するには、良い本を読むこと。何十年もの見識を短い時間で学ぶことができる。
海外で、どのような良書があるかは、Jolt Awards http://www.drdobbs.com/joltawards *4 の候補作をチェックしている。

【筆者注】以下、推薦図書。ソフトウェア開発の名著を数多く翻訳して出版していた桐原ピアソンが倒産したために絶版が多いですが、ここで英語の原著を読むのも一興かもしれません。

推薦図書(読みやすいコードを書く)
  • CODE COMPLETE 第2版

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

  • プログラミング作法

プログラミング作法

プログラミング作法

  • Clean Code

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

  • 実装パターン(日本語版は絶版中)

実装パターン

実装パターン

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

  • リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

推薦書籍(実践する開発者)

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (349件) を見る

  • ソフトウェア職人気質 (日本語版は絶版中)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

  • 作者: ピートマクブリーン,McBreen Pete,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/03
  • メディア: 単行本
  • 購入: 4人 クリック: 85回
  • この商品を含むブログ (63件) を見る

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

  • アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道


新しい技術を学習していく一方、何年経過しても陳腐化しない『コンピュータの基礎知識』を習得しておくことも重要

  • ハードウェア
    • コンピュータの基本動作原理、CPUの基本構造、メモリ回路、割込動作など
  • OS
    • LinuxなどのOSの基本的な仕組み
  • データ構造とアルゴリズム
    • リスト、木構造、ハッシュテーブル、探索、計算量(オーダ)など

『プログラミング作法』の第2章の内容程度は必須

ソフトウェアエンジニアは、特別な技術に執着するのでは無く、多くの技術の道具箱(オブジェクト指向UMLデザインパターン、マルチ・スレッドプログラミング、データベース技術など)の中から、与えられた問題に対して適切な道具を使って解決することが重要。
そのためには、その道具の使い方を熟知しておくことが必要。

1度にすべての道具を増やすことはできないので、新しいプロジェクトを経験するごとに道具箱の中味を増やしていくことが必要。
数年ごとに新しいプロジェクトに移った方が良い。

英語力

最新技術や上級者向けの情報は英語しか情報がない。
技術の継続学習と同様に、あるいは、それ以上に、英語力を身につけるための継続学習が必要。
http://yshibata.blog.so-net.ne.jp/search/?keyword=英語力

コミュニケーション力

よくエンジニアの会話で、相手に対して同じ説明を繰り返すことがあるが、相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明しよう。
相手の説明をきちんと理解できない場合に、相手が何を言いたいのかを逆に質問して、正しくコミュニケーションを取ろう。yshibata.blog.so-net.ne.jp
yshibata.blog.so-net.ne.jp

朝型(「朝活」)の勧め

yshibata.blog.so-net.ne.jp

ソフトウェア・スキル・インデックス

ソフトウェア開発のながい道のり(The Long Road)を、管理職になることなく歩んでいくという観点からソフトウェア・スキル・インデックス(Software Skill Index)として、ソフトウェア技術者のレベルを分類しています

http://yshibata.blog.so-net.ne.jp/2010-01-11
  • 上級職人以上は、常に学習を継続している
  • 名人、匠では、職人育成もその活動の一部である
  • 名人、匠では、会社内での評価には限界があり、社外からの評価を得る必要がある

たいていのエンジニアが、仕事について5年ぐらいで学習しなくても開発「業務」をこなせているため、学習意欲を失ってしまう。
学習しないため、技術進化のスピードについていけず、技術力は年々落ちていく。

「型」覚えずして上達なし

yshibata.blog.so-net.ne.jp

守破離(しゅはり)は、日本での茶道、武道、芸術等における師弟関係のあり方の一つ。日本において左記の文化が発展、進化してきた創造的な過程のベースとなっている思想でもある。
まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。

http://ja.wikipedia.org/wiki/%E5%AE%88%E7%A0%B4%E9%9B%A2
学んで思わざれば則(すなわ)ち罔(くら)し、思うて学ばざれば則ち殆(あやう)し

学んでも考えなければ物事は鮮明にならない。考えても学ばなければ独断に陥って危険だ

Java SE 8オーバービュー

OSS勉強会ということもあり、残りの短い時間で、最新のJava SE 8の仕様を駆け足で紹介してくださいました。yshibata.blog.so-net.ne.jp

DRMフリー版book.impress.co.jp

他言語の仕様追加のスピードに比べ、Javaは停滞していると感じていました*5 が、ここに来て進化の力強さを感じました。


Javaは既に終わっているという風潮もありますが、それは最新仕様に追随していかないエンジニア側に問題があるんじゃないかと感じてツイートしました。
f:id:kamatamadai:20150405215512j:plain
https://twitter.com/kamatamadai/status/578940317920989184


ただ、柴田さんご自身は、Go言語をメインに扱っていくそうです。yshibata.blog.so-net.ne.jp
yshibata.blog.so-net.ne.jp

以上

*1:筆者は今のところ、アフィリエイトをやっていません

*2: 今は東京の会社になってしまった

*3:プラットフォームに依存しないJava環境の良さをフルに活かすことにこだわった先進技術の息づいた新世代ワープロ http://www.justsystems.com/jp/software/dt/ark/

*4:コンピュータ業界のオスカー賞

*5:筆者自身がJavaを最近さわっていなかったというのもあります