イノベーション人材育成のためのオープン・ソース・ソフトウェア概説　(in Japanese)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
イノベーション人材育成のための
オープン・ソース・ソフトウェア概説
山上俊彦
ACCESS IoT 事業本部, ACCESS
Toshihiko.Yamakami@access-company.com
2017/03
山上俊彦 (ACCESS Confidential) イノベーション人材育成のためのオープン・ソース・ソフトウェア概説2017/03 1 / 61

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
前編
オープンイノベーション
オープンソースとは
ツール
オープンソースの掟
オープンソースのご法度
オープンソースのビジネス活用

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
OSS (Open Source Software): ソフトウェアの著作者の権利を守りながらソースコードを
公開することを可能にするライセンス（ソフトウェアの使用許諾条件）を指し示す概念
(Wikipedia)
二元論の終わり
オープンソース
ソフトウェア
商用
ソフトウェア
現代工学の
主要課題
オープン
イノベーション
越境
ソフト工学
説明するソフト開発
大規模ソフト開発、分散開発
顧客や提携相手と
イノベーション
現代研究開発戦略
標準化 or 財団
工学
コンセンサス工学
個人戦 → 団体戦
経済生態系
工学
フリー経済
フレームワーク
生態依存性工学
プラットフォーム戦略

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
OSS に見るプログラミングスキル転換
スキルパワー
10 年前の
プログラミング
アーキテクト
能力
スキルパワー
今の
プログラミング
ソフトは資産ではなくて負債 (1 行でも書かないほうがいい)
80 % 以上はフレームワークが仕事をしている
何をどう流用し、組み合わせるかを知っていることが決定的

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Hollywood Principle
フレームワークデザインのガイドライン
“don’t call us, we’ll call you”
コントロールの放棄: デバッグ、維持、試験の容易さ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
フレームワークへの変遷
機械
?
信号
機械信号プログラム
メモリ
?
信号
【フォンノイマン型コンピューティングの誕生】
機械プログラム変数
ROM RAM
?
信号
?
信号
ファイルシステム
ソース → バイナリ
【ソースコードプログラミングの誕生】
?
信号
ファイルシステム
フレームワーク
WS 要素 FW 要素
コードコード
→ バイナリ
(OSS or Proprietary)
サーバ
クラウド, Web Services
(OSS or Proprietary)
ネットワーク
【フレームワークプログラミングの誕生 (OSS による普及)】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
OSS とは？
オープンソースはソフトウェア以外にもある
知財の一部を無償公開し、周辺領域で事業運営する
ソフトの場合は OSS (オープンソースソフトウェア)
OSS とは何かは非常に難しい (私だけ?)
複雑な概念だという理解が不足 (OSS= 無料という程度の理解)
IT インフラ進化により加速
OSS はプロジェクトによって千差万別
コード
SourceForge
e.g Meego(1 億行)
ライセンス
GPL, LGPL (GPL 汚染)
BSD
Dual License
XXX Public License 乱立
開発手法
、バザール方式
設計 + コード + デバッグ
+ 運用の一体化
哲学・
社会運動
フリーソフトウェア
普及方法
プロフェッショナル OSS
コミュニティ
属人的, 感情的摩擦
Maintainer, 標準ツール,
プロジェクト数 30 万

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
[参考] OSS の歴史
GNU
(1983)
FSF
(1985)
BSD
License
(1990)
GPLv2
LGPL
(1991)
Linux
(1991)
OSS, OSI
(1998)
Black Duck
(2002)
Apache
S. F.
(1999)
SourceForge
(1999)
GNOME
Foundation
(2000)
Linux
F.
(2007)
LiMo F.(2007)
OHA (2007)
Symbian F. (2008)
Mozilla
Foundation
(2003)
Eclipse.org
(2001)
Eclipse
Foundation
(2004)
Ubuntu
(2004)Red Hat
Software
(1995)
MySQL AB
(1995)
MySQL 買収
(2008)
注 1: Red Hat は copyleft 注 2: Linux は今でもバザール方式
注 3: GNU/Linux はアプリも含めたパッケージ注 4:BSD 系ライセンスは派生ライセンスが自由
注 5: Bugzilla(1999)山上俊彦 (ACCESS Confidential) イノベーション人材育成のためのオープン・ソース・ソフトウェア概説2017/03 8 / 61

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンであること
オープンであることは痛みを伴う
プロジェクト毎にやりかたはいろいろ
汗を流した人に決める権利がある
大規模であれば、実は OSS でなくても課題は同じ
コーディング
コミュニ
ケーション
コーディング
コミュニ
ケーション
多少の誇張はあるが…

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソース
共同開発の新しい形態
今後のソフトウェア開発の方法として有望

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソース (2)
単にソースコードを公開する、ということではない
会社に入る、と同じような、ある作法に従うことを前提とする開発
の仕方の選択

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソース (3)
オープンソース化したい
自分を証明する
仲間の一員として認めてもらう

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
仲間にはいる方法
自分を知ってもらう (1)
IRC(チャット) にはいって話しかける
メーリングリストに入ってメール交換する
自分がどのようなソフトを作ろうとしているかをチャットやメール
で話す
変なおたくジョークをチャットで披露
自分を知ってもらう (2)
Bugzilla(バグ管理ソフト) の中からバグを取り上げて直す
Project の作業項目の中から何かを貢献する
相手を知る
Maintainer, Contributors を知る

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
仲間にはいる方法 (2)
中世のギルドのようなもの
おひかえなすって、…
自分の知識を紹介
その中で時間を使う: 存在証明
作業を分担し、信頼してもらう

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ご法度
いきなり大貢献
こっそり半年作業して、いきなり 15 万行の改変コードを貢献する
誰もレビューできない：レビューシステムの無視
他人との共同作業の拒否と見られる
部分的に何かつくっていた人々の時間が無駄に
いろいろなアイディアがあって進行している他作業や経緯の無視
大きな tarball を出すくらいならプロジェクトを起こす

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
貢献
Bugzilla にそって行う
パッチ (修正) を投稿
パッチのレビュー
パッチの承認/拒否
パッチの受け入れ
パッチのコミット

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
貢献 (2)
大きな貢献１回より小さな貢献たくさん
不安定でも早く何回もリリース

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プロジェクトの掟
プロジェクトの掟はプロジェクト毎に違う
プロジェクトは基本的には Maintainer の Baby
Getting Involved
慣例もプロジェクトによって違う
例: 偶数バージョンは安定版、奇数バージョンは試用版: プロジェ
クトによって違う

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プロジェクト
プロジェクトは次のものからなっている
人: Maintainer, Reviewers, Contributors
コード
ツール: Web, Wiki, IRC, Mailing List, blog, RCS, doxygen, Bugzilla,
SDK, …

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ツール
コミュニケーションツール
開発ツール
バグ管理ツール
コード維持ツール
ドキュメンテーションツール

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
人
Maintainer
Main Contributors
Occasional Contributors
Breeding Edge Users
Users

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
エコシステムの一員になる
プロジェクトのツールを使う
プロジェクトの情報交換の一部となる
プロジェクトの貢献・レビューシステムの一員となる
ロードマップを共有する

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
エコシステムの一員になる (2)
まず Maintainer, Contributors と相談

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
尊敬と責任
オープンソースエコシステムの一部となる
信頼を勝ち得る
尊敬を勝ち得る
責任を勝ち得る

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
開発の方法
Internal Temporary Branch
Temporary Branch: No Guarantee
Pre-release Branch
Stable Branch
Upstream への貢献

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
よい OSS プロジェクト
強い開発コミュニティ
確固たるユーザベース
メジャーディストリビューションでの採用
安定したリリースサイクル

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
なぜオープンソース
メンテナンスコストの削減
標準のツール、ドキュメンテーションの利用：継続可能なシステ
ムの採用

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソース化するには
オープンソースコミュニティのメンバを雇用
オープンソースコミュニティメンバをコンサルタント契約
e.g. オープンソース廃人の活用

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソースのバリア
時間的制約
英語圏のチャットに参加するには時差が壁
言語的制約
IRC やおたくジョークはしきいが高い
開発文化的制約
制約された開発計画の拒否
定期的ミーティングや出社の拒否
自宅勤務

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソース会社
オープンソースのビジネスモデル
デュアルライセンス
開発コンサルタント
勤務形態
自宅勤務
グローバル: オーストラリア、ブラジル
採用形態
バグ修正の経験をみて採用
はずれがない
コミュニティの束縛

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
哲学
オープンソース・ソフトウェアの哲学の尊重
プログラミングはアート
プログラマはアーティスト
新しい思考方法, 勤労方法
プログラマの情熱の共有

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
コミュニケーションスキル
なにもかも話さなければならないわけではない
開発プランの一部を秘匿しても深い技術的議論はできる
隠したがっているという態度は NG

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソースにする
オープンにしながら自分の優位性を保つには
基盤プラットフォームは人と共通化する
よりクリエイティブになる

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソースにする (2)
プロトコル、などは成功例が多い
開発環境、もオープンソース向き
ユーザエクスペリエンス、などは難しい

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソースにする (3)
プロジェクトを理解するのに時間を惜しまない
信頼を勝ち得るのには時間がかかる

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
前編のまとめ
ツール
オープンソースの掟
オープンソースのご法度
オープンソースのビジネス活用

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
後編のはじめに
書く技術より読む技術
ソースコードを読むことは状況を読むことに近い
読む目的を理解
外部依存性の理解
すべては読まない技術
構造の理解
リスクの理解
成り立ちの理解

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードを読む技術
他人のソースを読むことは書くことより難しい
読む技術を教えることは難しい
読む技術は教えられていない
自分で書いたソースも忘却により他人のソースと同じになる
多くのコミュニケーションと同様、ソースコードを読むことも苦
痛

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードを読む技術 (2)
よいコードを書くためによいコードを読めといわれた時代
技術の習得
よい習慣の習得
統一的なコーディング
書かないために読む、時代へ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
オープンソース時代にはソースを読むことが重要
規模
複雑さ
完成度
外部依存性
自分で書くか、オープンソースを使うかを判断

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
添付されているドキュメントを読む

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
巨視的な理解
規模の把握 (ファイル数、行数など)、ディレクトリ構造、ドキュメ
ントの精査、プロジェクトのポータルサイトの確認 (サイトマッ
プ)、メーリングリスト、掲示板等コミュニティサイトの確認、名前
付け規約の確認、ソースコード管理システム、バグ管理システム
微視的な理解
ソースコード、ソースコードリファレンス、ChangeLog、バグデー
タベース、ソースコード管理システム (バージョン間の差分)、検索
エンジン、メーリングリスト

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
、

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースの読み方
静的に読む
そもそも静的に読むだけでも大変
IDE, gdb などを使い、ツールで読む
動的に読む
ツールなどを使い、性能などを解析する

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースの読み方 (2)
もっとも非効率な読み方
はしから順番に読む
ソースコードははしから読むようにできていない
ソースコードははしから順番に書かれたわけでもない
効率的な読み方
コードを読む技術とはコードを読まない技術
読まなくていいところを判断する技術
ツールを使う: gprof, oprofile など → 読むべきところを把握

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースの読み方 (3)
読み方はサイズに依存
プログラムのサイズ
サイズはありとあらゆる人間の協調活動に影響
サイズは読み方、書き方、メンテナンスに仕方に影響
プログラムのサイズ
小規模: 1-5 万行 (10 人以下で半年以下)
中規模: 5-20 万行
大規模: 20 万行以上 (100 人で 1 年以上)
メンテナンス、依存関係にもよる

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大規模なソース
OSS は 100 万行なんて珍しくない
(MySQL/PHP/PostgreSQL/Samba/Perl …)
Linux カーネルなんて 500 万行 (2007)
ひらメソッド（超精細）なんてのもある:
LKH-jp（旧読学のススメ）で提案されているコードリーディング手
法．
関数単位で Wiki にメモを残しながら，ボトムアップに読み進める．

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大規模なソース (2)
WebKit (browser) テスト除いて 80 万行
Android 　カーネル除いて　 800 万行
OSS でなくてもブラウザ、Java、など 100 万行超える組み込みソ
フトはごろごろ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方
読む目的の設定
構造を理解する
インタフェースを理解する
改造の準備をする
利用可能性を評価する

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方 (2)
読むこと
名前の塊を理解すること
関数名、変数名、定数名、…
コメントのスタイル
ファイル名
名前付けの体系

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
歴史を読むこと
設計の開始点を読む
チーム構成を読む
変更の時間間隔、最新の変更を読む

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
構造を読むこと
ファイル構成、ディレクトリ構成
バージョン管理
グローバルな名前体系、コーディングルール
インタフェース仕様
拡張の方法
想定されているデバッグのしかた
外部依存関係
データ構造
制御構造
データベース構成

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ヘッダファイルを読むこと
基本的なデータ構造
分岐やデバッグの作法
依存関係

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
権利を読むこと
ライセンス条件
配布条件

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な解析ツール
ctags, doxygen, …
呼び出し関係の可視化ツールなどもある

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードには著者の意思や哲学がちりばめられている
書いたひとを理解できればソースの理解は格段に効率化する
拡張する方法、好きなデータ構造などテーストを理解

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
テストコードを読むこと
テストの環境設定
テストの網羅性
テストの対象

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
後編のむすび
書く技術より読む技術
ソースコードを読むことは状況を読むことに近い
読む目的を理解
外部依存性の理解
すべては読まない技術
構造の理解
リスクの理解
成り立ちの理解

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
参考
ソースコードを読むための技術 http://i.loveruby.net/ja/misc/readingcode.html
その後、Ruby ソースコード完全解説序章にはいった模様
Code Reading: The Open Source Perspective (by Diomidis Spinellis, 2003 Addison-Wesley)
オープンソースのコードサーチエンジン http://www.koders.com/

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
最近の潮流
単体で読みやすくする
ユニットテストをしっかりする
リファクタリングする

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
(参考)Eclipse
IBM によって開発された Java 用統合開発環境 (IDE)
Java で書かれている
1998 年開発開始, 2001 年 11 月オープンソース化
2004 年 Eclipse Foundation 設立
プラグイン
さまざまな機能をプラグインとして組み込めるよう設計
非常に拡張性が高い
プラグインでさまざまな言語 (C++, Perl, C#, Python, …) に対応
CVS 連携, JUnit 連携, Ant 連携
SWT(Standard Widget Toolkit) を使い、動作が軽快

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
(参考) リファクタリング
振る舞いを変えずにソースコードの内部構造を整理する)
主な技術
長いメソッドの抽出
双方向関連を単方向に変更
継承を委譲に書き換える
コンストラクタを Factory Method に書き換える
引数オブジェクトの導入
クラス、メソッド、属性の名称を変更
最近の IDE はリファクタリング機能が具備
アジャイルプログラミングの XP などでは開発の習慣としてリファクタリングを挙げてい
る

イノベーション人材育成のためのオープン・ソース・ソフトウェア概説 (in Japanese)

More Related Content

What's hot

Viewers also liked

Similar to イノベーション人材育成のためのオープン・ソース・ソフトウェア概説 (in Japanese)

More from Toshihiko Yamakami