Download as PDF, PPTX
Uploaded byyoshikishibata
ソフトウェアエンジニアとして心がけてきたこと
レッツゴーデベロッパー555の基調講演のスライドです。実際の講演では、スライドに書いていないことを話しています。
![[A-2] 今後の生き方についてサラリーマンエンジニアが人生半ばにして考えてみた](https://cdn.slidesharecdn.com/ss_thumbnails/a2-190703094334-thumbnail.jpg?width=640&height=640&fit=bounds)
ソフトウェアエンジニアとして心がけてきたこと
- 1.
- 2. 自己紹介 • 柴田 芳樹（しばた よしき） • 1959年11月生 •1984年3月 九州工業大学 大学院 修士課程終了（情報工学） • 1984年4月 富士ゼロックス 1988年11月∼1993年5月 米国ゼロックス • 1996年9月 日本オラクル • 1997年5月 ジャストシステム • 1998年5月 富士ゼロックス情報システム 2002年8月∼2003年1月 米国ゼロックス • 2009年9月 リコー
- 3. プログラミング言語経験 • 大学時代（1978年∼1984年） Fortran, APL,PL/I, Pascal, Z80アセンブリ言語 • 社会人（1984年∼1993年） 仕事：C、Mesa（Xerox社内の言語） • 社会人（1993年∼2009年） 仕事：C++（マルチスレッドプログラミング） プライベート：Java（1996年夏頃∼） • 社会人（2010年∼現在） 仕事：ほとんど書けていない プライベート：Go, Java
- 4.
- 5. 一人前になるには10年 ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する。 Richard Gabriel, 「ThePoetry of Programming」 私ならプログラミングを技芸と表現します。それは一種の芸術ですが、美術作品ではありません。技芸 は、おそらく装飾的仕上がりを持つ有益な物を作ることを意味します。美術作品は純粋に美しさのため に物を作ることを意味します。 Richard Stallman、「Art and Programmingにて」 どの言語でプログラムしようとも、プログラマとしてのあなたの仕事は、使えるツールを使ってベスト を尽くすことです。優秀なプログラマであれば、低レベルの言語、あるいは扱いにくいシステムであっ ても克服しますが、優れたプログラミング環境は、できの悪いプログラマを救済してはくれません。 Brian Kernighan, Rob Pike, 『プログラミング作法』 優れたソフトウェアは、CASEツールや、ビジュアルプログラミングや、ラピッドプロトタイピング や、オブジェクト指向技術から生まれるものではありません。優れたソフトウェアは人が作るのです。 ダメなソフトウェアも同様です。 Larry L. Constantine, 『The Peopleware Papers』 並のプログラマが良いツールや良い言語を使っても並のシステムしか開発できないが、優れたプログラ マは、粗末なツールや並の言語を使うハンディを負っても、すぐれたソフトウェアを作り出すことがで きる。このことは過去には正しかったが、これからもずっと正しいだろう。 Edward Yourdon, 『ソフトウェア管理の落とし穴』 ソフトウェアは、統合開発環境などのツールによって設計されるのではなく、プログラマーの頭の中で 考え出され、作り出されるものなのです。 Andy Hunt, 『リファクタリング・ウェットウェア』
- 6.
- 7. 読みやすいコードを書く ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出す ことです。ソフトウェアエンジニアが、他人の書いたコードを理解することがで きない場合には、そのコードはあっさりと捨てられ、一から書き直されてもおか しくはないでしょう。残念なことに、このような書き直しは頻繁に起きています。 コードを読みやすく保守性を高めることは、コードを正しく動作させることと同 じくらい、あるいはそれ以上に重要です。正しく動作しないコードは、動作する ように修正することはできます。保守できないコードは、がらくたに過ぎません Taligent’s Guide toDesigning Programs: Well-Mannered Object Oriented Design in C++ ソフトウェアは機能が実現すれば資産になるとは限らない。保守できないコード は、負債となる 初心者だからと言って、汚いコードを書くことが許される訳ではない
- 8. 読みやすいコードを書く Martin Fowler, 『リファクタリング』より •誰でも、コンピュータが理解できるコードは書けます。優れたプログラマは、 人が理解できるコードを書きます。 •良い名前を付けることは、訓練を必要とするスキルです。このスキルを伸ば すことが、本当に熟練したプログラマとなるために重要です。 マイケル・C・フェザーズ、『レガシーコード改善ガイド』より •ネーミングは設計の中心である。優れたネーミングはシステムの理解を助け、 作業を容易にする。しかし、貧弱なネーミングはシステムの理解を妨げ、後 でシステムを扱うプログラマに辛い日々を送らせる。
- 9.
- 10. 論理的思考 − デバッグの科学的手法 − 1.プログラムの失敗を観察する 2. 観察と矛盾しない失敗の原因についての仮説を立てる 3. 仮説を使って予想する 4. 予想を実験でテストして、さらに観察する a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする b. 満たさないなら、別の仮説を立てる 5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。 書籍『ビューティフルコード』第28章より キーボードを早く触りたい気持ちを抑えること。思考はそれに勝るとも劣らない 行為なのだ。 Brian Kernighan, Rob Pike, 『プログラミング作法』 まず深呼吸をしてから、バグを引き起こした原因について考える。 Andrew Hunt, David Thomas, 『達人プログラマー』
- 11.
- 12. 継続した学習 ソフトウェア業界で取り残されないようにするには、次の３つの事柄をあなた自 身が認識することが重要です。 (1) 重要な本、出版物を読み、主な専門的カンファレンスに参加すること。 (2) あなたが今日読んだ情報は３年から５年で古くなるため、常に終わることの ないプロセスであると言うこと。 (3)あなたの会社は、良くても限られたサポートしか提供してくれないでしょう し、最悪何もサポートしてくれないと言うこと。 大多数のプログラマーやシステムアナリストは、自分の専門性が時代遅れになら ないように維持することを会社に頼ることはできません。ソフトウェア業界で取 り残されないためには、自分から進んで自分の時間（休暇さえも）や自分のお金 を投資しなければなりません。 -- Edward Yourdon, Decline & Fall of the American Programmer
- 13. 継続した学習 Read Any GoodBooks Lately? 新しい知識と見識を得るために、私は常に本を読んでいます。一冊の良い本を選 べば、他の人が何十年もかかって修得してきた見識を、数日で得ることができま す。それなのに、なぜ、何年もかかって試行錯誤により学ぶのですか。非常に大 きな差ですよ。もし、チームのメンバーが一年間に6冊の見識深い本を読んだと したら、そのことがメンバーの仕事にどのような影響を与えるか想像してみてく ださい。 --Steve Maguire, Debugging The Development Process •技術を作り出した人が執筆した書籍を読む •技術書には誤りがあると思って読む
- 14.
- 15. コンピュータの基礎知識 何年経過しても陳腐化しない、コンピュータの基礎知識を習得しておくことも重要 コンピュータの基本動作原理 CPUの基本構造、メモリー回路、割り込み動作、etc ハードウェア Linuxなどのオペレーティングシステムの基本的な仕組み オペレーティングシステム リスト、ツリー、ハッシュテーブル、サーチ、O標記、etc データ構造とアルゴリズム 書籍『プログラミング作法』（Brian Kernighan, RobPike）の 第2章「アルゴリズムとデータ構造」の内容程度は必須 勉強会ノート http://www001.upp.so-net.ne.jp/yshibata/TPOP.pdf
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.