「書く」ソフトウェア教育から「読む」ソフトウェア教育への転換 (in Japanese)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
「書く」ソフトウェア教育から
「読む」ソフトウェア教育への転換
山上俊彦
IoT 事業本部, ACCESS
2016/07
山上俊彦 (ACCESS Confidential) 「書く」ソフトウェア教育から「読む」ソフトウェア教育への転換 2016/07 1 / 60

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
書くソフトウェア教育の
生産性に疑問を持ち
　よりよい方法を
　　捜す人が対象

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
探して読むを基本に
1 日 1 万行読むための
　ソフトウェア教育を
　　　　　解説

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
読むソフトウェア教育の
イントロ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
普遍的な知的能力の獲得
既存の知識
ネット上の資産
（利用可能）
- 最小ギャップの
発見
問題解決
ソリューション
【ソフトウェアでも技術でも事業開発でも同じ：オープンイノベーション時代のスキル】
検索・結合洞察
小学校の読書 - 作家教育はしない
【読み書きの教育】
時間がたてば
自分も他人
- 読むスキルの需要
【ソフトウェア開発における不可避の時間軸の問題】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
何故、「読む」ソフトウェア教育？
小さな完結する
ソフトウェア製作は
企業にはない
- 100 行のソフトを
書く演習は必要？
【情報通信ソフトウェアで 30 年務めた所感】
書く:
完結する、
ゼロから動く
- 読む：
俯瞰してつかむ
【ソフトウェア教育のトレンド変化】
トップダウン設計力ボトムアップコーディング力

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
読むソフトウェア教育
1. ソフトウェアは
書かないと
理解できない
2. 書かないと
楽しくない
【読むソフトウェア教育への 2 つの反論】
書く教育は言語や
プラットフォームに
依存
- 教育者の選択が
悪いと役に立たない
【読むソフトウェア：言語依存・プラットフォーム依存のない教育】
書くスキル
- 読むスキル
【読み書きにはそれぞれ固有のスキル: 読む教育の教育は不足】
(デバッグスキル、
実行環境スキル)
(大量読破、俯瞰スキル)
(工数判定、品質判定、依存性・拡張性判定)

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
俯瞰するプログラミングで獲得すべき能力
開始、終了、接点、
繰り返し、の把握
依存性、ドキュメント、
基盤、拡張の把握
処理作法、名前、
記述規則、の把握
品質、例外処理、
負荷対応の把握
【俯瞰するプログラミングスキル】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードを
読む技術

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードを読む技術
構成力を
付ける
-
名前、ファイル、
ライブラリ、拡張性、
プロジェクト統一規則
【読むソフトウェア：構成力（抽象化単位）】
動的構成力を
付ける
-
利用技術、
利用基盤、依存性、
処理ルール (エラー等)
【読むソフトウェア：動的構成力（抽象化単位）】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードを読む技術 (2)
判定力を付ける -
利用技術、規模、
複雑さ、依存性、
拡張性、品質
【読むソフトウェア：判定力（利用可能性を判断）】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースコードを読む技術 (3)
巨視的な理解
規模の把握 (ファイル数、行数など)、ディレクトリ構造、ドキュメ
ントの精査、プロェクトのポータルサイトの確認 (サイトマッ
プ)、メーリングリスト、掲示板等コミュニティサイトの確認、名前
付け規約の確認、ソースコード管理システム、バグ管理システム
微視的な理解
ソースコード、ソースコードリファレンス、ChangeLog、バグデー
タベース、ソースコード管理システム (バージョン間の差分)、検索
エンジン、メーリングリスト、コーディングガイドライン
周辺
言語選択、実行環境選択、依存環境、プラットフォーム選択、圧縮
方法選択、ドキュメンテーション、コミュニティ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
具体的なソフトウェアソースの
読み方

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースの読み方
シーケンシャル
実行フロー
(ジャンプ) 探して戻る
【読み方はいろいろ】
静的に読む
(IDE, gdb など
ツール利用)
-
動的に読む
(ログ、性能などを
読む)
【大量だと静的に読むのも大変】
はしから順に読む -
順書きされていない
順読みするように
できていない
【もっとも非効率的な読み方】

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
読まない技術
読む技術とは
読まない (飛ばす)
技術
-
読むべきところを
見つける
【もっとも効率的な読み方（読まないスキル）: 1 人で読めるのは 1 万行くらい】
(e.g. oprofile, gprof)
目的に合わせて絞って読む

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースを読む: 読む目的
書くのは動けばいいが、読む目的はいろいろ
プログラミングの学習（テクニック、作法、構造）
コードの概要（構造、外部 IF(F, DB, Net)、技術理解、異常処理、運
用処理)
品質、外部依存性、チーム構造、歴史 (最近の更新)、ライセンス
改造、拡張の準備
コードは How、テストは What、ドキュメントは Why
読みながら何を「書く (メモ)」かも問題。ツール活用

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースの読み方はサイズに依存
サイズはあらゆる
人間の協調活動に
影響
- 読み方は
サイズに依存
【プログラムのサイズが読み方を決める】
・サイズが読み方、書き方、メンテナンスの仕方を決める
小規模
1–5 万行
中規模
5–20 万行
大規模
20 万行越え
(100 人年以上)
【チームの能力による: サイズの目安】
10 人以下、半年以下

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大規模なソース
OSS は 100 万行なんて珍しくない
(MySQL/PHP/PostgreSQL/Samba/Perl …)
Linux カーネルなんて 500 万行 (2007)
ひらメソッド（超精細）なんてのもある:
LKH-jp（旧読学のススメ）で提案されているコードリーディング手
法．
関数単位で Wiki にメモを残しながら，ボトムアップに読み進める．
知らない関数がでないようにボトムアップに読む
WebKit (browser) テスト除いて 80 万行
Android 　カーネル除いて　 800 万行
OSS でなくてもブラウザ、Java、など 100 万行超える組み込みソ
フトはごろごろ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
実践: 読む技術
全体構成、モジュール構成、オブジェクト構成
エントリポイントを把握
入出力作法（型など）を把握
呼び出し関係
メイン処理部分
実行シーケンス
終了処理
(ソース履歴)
コーディング規則

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
メタコーディングガイドライン
プログラミング言語による
ファイル構成を読み解く
コーディングガイドラインを読み解く
なぜそうなっているかを読み解く
不規則性の把握
マクロ、typedef など

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方: 歴史、依存関係の理解
歴史を読むこと
設計の開始点を読む
チーム構成を読む
変更の時間間隔、最新の変更を読む

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方：　周辺ドキュメントを読む
ヘッダファイルを読むこと
基本的なデータ構造
分岐やデバッグの作法
依存関係
権利を読むこと
ライセンス条件
配布条件

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方：ツールの使い方
静的な解析ツール (プラットフォーム依存)
ctags, doxygen, …
呼び出し関係の可視化ツールなどもある

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方：人の理解
ソースコードには著者の意思や哲学がちりばめられている
書いたひとを理解できればソースの理解は格段に効率化する
拡張する方法、好きなデータ構造などテーストを理解
ドキュメント提供の仕方、パッチ判定の仕方を理解

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
静的な読み方: テストコードを読む
テストコードを読むこと
テストの環境設定
テストの網羅性
テストの対象

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースを読む：いろいろ読む
読む技術
仕様書を読む技術
API 仕様書を読む技術
アーキテクチャを読む技術
コード規則を読む技術
リリースプロセスを読む技術
コメントを読む技術
ロードマップを読む技術
依存関係を読む技術
人間を読む技術

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
目的別の読み方

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プログラム言語を学ぶ
名前付け規則（変数、関数、定数、予約語）
データ定義（型、クラス）
構文規則（代入、条件文、繰り返し）
宣言、実行文、コメント
モジュール定義、処理フロー
ライブラリ、API、実行環境依存部分
他のプログラミング言語との類似、差異
教育効果尺度: 言語仕様理解度、言語比較理解度

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
プロジェクトを学ぶ
プラットフォーム、依存する実行環境、ライブラリ、共通部分
名前付け規則（変数、関数、定数、ファイル）
コメント、ドキュメンテーション
バージョン管理
変遷、成長 (拡張) の過程
拡張、外部 API
コンフィギュレーション定義
ロードマップ
教育効果尺度: プロジェクト理解度、API 理解度

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
技術を学ぶ
技術該当部分
実装部分と API 実行、Web 実行部分
コンフィギュレーション定義
教育効果尺度: アルゴリズム理解度、プラットフォーム理解度

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
品質を学ぶ
コーディングの整合性、規則性
更新履歴
条件判定（アサーション）
エラー判定（準正常系）
エラー処理（異常系）
耐性（異常データ、異常トラフィック)
更新履歴（頻度、更新方法、ドキュメンテーション)
教育効果尺度: 品質判定の正確性

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
機能実装例を学ぶ
例えば、Android コーディングの実装例
具体的に何を書くの？
携帯電話アプリってどう動くの？
プラットフォーム、API？
プラットフォーム依存のコーディング作法 (開始、終了、異常処理）
IDE？
教育効果尺度: 機能実装準備理解の進み具合

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソフトウェアソースを
大量に読む

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ソースを読む：たくさん読む
読む技術 - たくさん読む
【ソースをたくさん読む: 目的をはっきりさせて】
たくさんの著者と対話して学ぶ

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大きなプロジェクトを読み解く
大規模プロジェクトにしかないもの
API 仕様書
アーキテクチャ技術資料
リリースプロセス
ロードマップ
プロジェクト間依存関係 (Required Versions)
ファウンデーション (ByLaws, Membership agreement, …)(= ソース管理団体)
人間関係、今起こっていること
概要を読んで計画する
あるいは、できればコードまで読まないですます場合
プロジェクト外部からの言及、批判

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む
大量のコードを読む
そうはいっても何読むの？
Linux Kernel? GNU? GNOME? Android?
Adobe Open Source / http://sf.net/projects/adobe-source (C++ です)
石黒邦宏 (ACCESS 元 CTO) 曰く、「凄いコードなんでびっくりした。
凄いハッカーが作った凄いコード。ここ五年間に見たコードの中でい
ちばん凄かった。皆、これを勉強しなきゃ」
知らない OSS は怖い → ルータソフト Zebra http://www.zebra.org/
石黒邦宏作成の OSS
読む経験
読む勘所
既視感

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: 読む力 = 探す力
読む力 = 探す力
探すキー
関数、変数、
マクロ、型、…
探す場所
Dir, Web, Mail,
document, test, …
探すツール
Google, ViewVC,
Eclipse plugin, …
コード専用検索エンジンもある:BlackDuck Open Hub http://code.openhub.net/ (旧
Koders), Krugle (http://www.krugle.com/), {(http://www.google.com/codesearch は終了 (2015))

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: 忍耐力
大量の情報を処理するにはツールでも時間がかかる
400 万行のソースコードは doxygen かけるのに 2 時間
他人の書いたコードを読むのは苦痛
読み始めに抵抗感、ハードルが高い
(プログラムは思ったとおり動かない、書いたとおり動く)
大量といってもどれくらい読めばいいの？
Code Complete 2nd Edition にコードリーディングの節があるが、1
日 1,000 行とのこと

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: ソース可視化
IDE: 階層表示、型表示 on Eclipse (C/C++ なら Eclipse+CDT)
エディタ: Emacs with etags, vi with ctags
コードクローン可視化ツール: Gemini (阪大), CCFinderX
C フロー: cflow, cscope
SourceNavigator
ソース以外の視覚化
性能ボトルネックの可視化
Wiki の可視化
データ可視化: Gnuplot, GNU Octova, Scilab, MayaVi, Maxima,
OpenDX (バックエンドに使う)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: ソース可視化 (2)
山のようにツールはあるが探すのもかったるい
とりあえず Eclipse+CDT (C/C++ の場合) にする
Eclipse 4.5 をダウンロードしてインストール
CDT Plugin (8.8) をダウンロードしてインストール
workspace をつくり、“src” などソース拡張のディレクトリを指定
読みたいソースを指定したディレクトリに格納

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: ツール選択
フレームワークの理解
最近は main() やイベントハンドラを書くことはない
80 % 以上はフレームワークが仕事をしている
再利用可能な部品をどう組み合わせるかが勝負
フレームワーク対応のツールで読むことが多い
Java なら Eclipse, iPhone なら Apple Xcode, …
フレームワークの中身が読めないと意味がわからない
こちらから呼ぶのではなく、向こうがこちらを呼ぶ
Hollywood Principle: Don’t call me, I will call you.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: 紙から実行まで
紙派: 驚くべきことに紙と鉛筆というエキスパートも多い
集中できる
情報が多すぎない
何万行も紙で読むことは不可能: どこを読むかが重要
実行派: コンパイルして、動くコードなら、ビルドして動かす
IDE で breakpoint をいれて動かす
call stack など見ながら読むところの目星を付ける
グローバル変数の動きなどを追う

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: 書き留めること
ただ読んだだけではだめ
わかったことを書き留める
書き留めるツールの選択
書き留めるフォーマットの選択
当然、何を書くかでどう読むかが変わる
読む前に書くことを考える

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
大量のコードを読む: 人に聞く
OSS を理解する最良の方法は知人に聞くこと
大量で無秩序な情報 → 　事情を知っている人に聞く
「誰に」「何を」聞くかを的確に知ること
OSS の世界は狭い: ヒューマンネットワークが重要
OSS 関係者は大量のメールを読んでいるので埋没する可能性に注意

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
演習

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
演習 A
1 プロジェクト探索
大規模なプロジェクト、小規模なプロジェクトを探す
小規模で活発なプロジェクトを探す
2 プロジェクト解説
プロジェクトの歴史、概要をまとめる
3 OSS 地図
大きな Foundation 化されているプロジェクトの比較をする
4 Coding style 比較
Linux Kernel coding style と GNU coding style の比較をする

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
演習 B
1 プロジェクト観察
小規模で活発なプロジェクトを探し、過去 2 週間のメールアーカイ
ブから、プロジェクトの現在状況をまとめる
小規模で活発なプロジェクトを探し、メーリングリストに 2 週間入
って、プロジェクトの現在状況をまとめる
2 ソース観察
適当なサイズのコードを読み、プログラム構造をまとめる
3 IDE 体験
Eclipse を使ってみる

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
演習 C
1 用語辞典作り
適当なプロジェクトを探し、ドキュメント、メーリングリストから、
わからない単語 10 個を抽出し、意味を調べる
2 ツール探索
ソース用検索ツールを探す
インストールして使ってみて使用感をレポートする
探した履歴をまとめ、どうすれば早く探せるかをまとめてレポート
する
ソースの可視化ツールを探す

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
むすび

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
参考

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

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
(参考)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 などでは開発の習慣としてリフ
ァクタリングを挙げている

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
スーパープログラマの知人が推奨する読むべきソースコード
C なら Python のインタープリタ　 https://github.com/python/cpython
(ボリュームがある)
きれいに書いてあるのは Python
バージョン管理ツールの mercurial
http://mercurial.selenic.com/release/?M=D
– (ver 0.1 は 689 行 (6KB) ver3.2 のサイズは 600 倍の 3.9MB) 　適当
なサイズのを選んで読む

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
参考文献
Code Reading—オープンソースから学ぶソフトウェア開発技法
(2004)

「書く」ソフトウェア教育から「読む」ソフトウェア教育への転換 (in Japanese)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (13)

En vedette

En vedette (20)

Similaire à 「書く」ソフトウェア教育から「読む」ソフトウェア教育への転換 (in Japanese)

Similaire à 「書く」ソフトウェア教育から「読む」ソフトウェア教育への転換 (in Japanese) (20)

Plus de Toshihiko Yamakami

Plus de Toshihiko Yamakami (20)

Dernier

Dernier (6)

「書く」ソフトウェア教育から「読む」ソフトウェア教育への転換 (in Japanese)