SlideShare une entreprise Scribd logo
1  sur  18
Télécharger pour lire hors ligne
# refactoring リファクタリング

* 修正ではない 拡張でもない

* プログラムを外部視点で動作を変えず、内部構造を整理すること

* まだまだ発展途上な技術分野(ソフトウェアは全て発展途上とも言える)
t C
# 論よりコード

* 一度正常に動いたと思えるソースコードは二度と触るな->腫れ物を扱う

* これはバグが出ないようにする先人の知恵

* 数年単位のプロジェクトでは まぁ、なるほどと

* 日々変わる要件や技術が通常となっている状況じゃ意味のない言葉になりつつあるかも
# Code smell

* 臭うよ!危険なニオイがソースコードからするよ!
# 臭いのもとは?

* 重複したコード

* 長すぎるメソッド

* 巨大なクラス

* 他クラスのメソッドを過度に用いる

* 不適切な依存関係

* サブクラスのくせにスーパークラスを無視してないか?

* それ、オーバライドではなく、置き換えでは?

* 同一あるいは同様のメソッドが複数箇所に存在しないか?

* 簡潔な設計で十分なところに、過剰に複雑なデザインパターン

* 単純にわけわからん 1+2*3 と (1+2)*3 と 1+(2*3)
# How to の一例

* 細分化(Class / method)

長いコードはそれだけで大変 / でかいクラスは必ずいびつな形をしている

* 関連の一方向化

その参照は必要なのだろうか?オブジェクトは参照されている間生き続ける

* 条件分岐のポリモーフィズム化

継承や委譲で条件となる箇所を別に切り分ける

* 継承(is-a)を委譲(has-a/use-a)へ

可能であればやる

分岐と条件を切り分ける

静的型言語としての継承は結構制約が多い

* 疎結合と密結合

依存関係は出来る限り最小にしよう

(javaとかなら、非ジェネリックなimportの数とか、その延長の変数とか指標の一つになる)

* バリューオブジェクト

頻繁に見られる同じ引数パターンをまとめて名前をつけてあげる

* 名称変更

名前がイケてないの、変えようよ
t
# そもそも論

* リファクタリングは目に見えて作業進 しない、恐らくゼロ

* 塩漬け要件が出来ない->プログラム修正->スパゲッティでわかんないよ!

* コスト高くなるよ->わかりやすくしよう->リファクタリングしまーす

* リファクタリングにかけるコストは???

* お客さま曰く、「最初からちゃんとしてればそのコストいらないよね」(要件替えるくせに最初からって…要オトナの対応)

* 作業じゃないんだよ、空気なんだよ、そう思うのがプロだし、カイゼンってそういうことだよね
# test! test!! test!!!

* est! est!! est!!! はイタリア白ワインの銘柄の一つです

* 動作が変わっていない保証はテスト結果しかない

* 大胆な計画と慎重な行動

* とにかく少しずつユニットテスト前提で
i
# 不遇の時代

* 昔はそんなことをする必要があるコードを書くこと自体が悪

* 漸く冷遇されなくなった手法の一つ(必要性は結構感じられていた)

* ただ、動的実行で型がなく、ライブラリのコードを読むのが当たり前の世界だったSmalltalkとかだと、リファクタはふつうのコトだった(リファクタリングがプログラミング作業の半分みたいな感覚)

* 設計書をテスト駆動型TDDをベースとする方法で誤魔化すことでXP化が加速されてイイカンジかも

* 僕はビヘイビア駆動型BDD(テストコードのクラス名とか変数名とかに要求仕様を書くような意識=自然言語に近づく(英語だけど))が好きです
gm g
# 手法と手段

* 手段は色いろある(主な項目は前述のとおり、どこぞのアカデミックな偉い人は70通りも考えてくれてるから、遠慮なくネットで検索してそれを使いましょう、車輪の再発明はいらないです)

* 対象の絞りこみ方法は決まった、やり方もなんとなくあるって話だ、んじゃ、やれるか?
w C
w C
w C
# 予防線を張ります

* ここからは僕の想い(手法)の話です、異論は認めますが、まずは聞いてくれ

* 異論は認めるが、今日議論をふっかけるのはやめてくれ

* できれば議論は来世で…

* 因みに結論はありません、聞いて欲しいだけです
# バックグラウンド

* 例えば、ソースコードを見るとメンバーの誰が書いたのか、60%位の確率で判るんじゃないか?

* 40%はスケジュールに追われているとかイラッとしてるとか( `д´) ケッ!とかおもってるとか

* 60%?ソレは何故?担当者のバックグラウンドが出ている

* 毛穴からにじみ出る汁みたいに

* それは、ボキャブラリ、嗜好、受けた教育、その他モロモロ
o
o
# 静的構造と動的構造

* 宗教と静的構造、動的構造の関係って見方がある

* 宗教論をするつもりではなく、構造の話です

* そもそもツリー構造はどちらかと言うと唯一神キリスト教、ピラミッド構造

* 神オブジェクト(なんでも持ってる)の実在は結構ある

* アリストテレスのイデア論って知ってますか?

* 八百万の神々とか和をもって尊しとなすとか日本文化チック

八百万の神々を一つにして神オブジェクトをやるととんでもないことになるw

* 仏教曼荼羅も仏様いっぱいいる

* どうも、西洋と東洋の差があるみたい(継承と委譲)

* 最近の作業を振り返って、クラスの構造関係とか動作時のオブジェクト関係とかどう?
rn la
# 表現と比喩

* 日本語って、表現方法が凄まじい

* 例えば、雨

** 霧雨、小糠(こぬか)雨、小雨: 雨の水滴の形状を指した言葉

** 時雨(ふったりやんだり)、にわか雨(すぐにやむ): 雨の状況(降り方)を指した言葉

** 春雨、五月雨、梅雨、秋雨、夕立: 時間や季節を含み持つことになった言葉

* で、例えば、五月雨

** 梅雨時期の雨のこと

** バラバラと断続的なこと

** 日本海軍駆逐艦、艦これの艦名なのは勝手に議論してください
# レトリック

* 直喩: 鬼のように強い(鬼の知り合い居ないけど、何となく分かる)(鬼みたいな人の知り合いは結構いる)

類似性を持つ何かに例える

* 隠喩: (ムスカ)見ろ!人がゴミのようだ(生ごみとか言っているのではなく、ゴミクズのように大量で捨てられているような感じ(たしか、実際は落ちていた))

メタファーというのはコレのこと、直喩を更に簡潔にした感じ

* 換喩: 赤ずきんちゃん(少女が赤い頭巾を被っているのであり、赤い頭巾に似ているのではない、因みに白雪姫(雪のように白い肌のお姫様)は隠喩

* 提喩: セロテープ(あるものを更に一般的な言い方で言い換える)

* 法政大学 理工学部 創生科学科 教授 玉井哲雄 氏

* 京都産業大学 コンピュータ理工学部 コンピュータサイエンス学科 教授 青木淳 氏
la
H
# 比喩とオブジェクト指向

* オブジェクト指向に言い換えると、

** 換喩=集約=has-a(part-of)=抽象データ型

** 提喩=一般化=is-a(kind-of)=インヘリタンス

** 隠喩=ポリモーフィズム
H o
c
# オブジェクト指向的に心がけるコトとか

* カプセル化(定義は色々あるけど、データ隠 で)

* 美味しいハンバーグのお店

* 年季の入ったコックさんの技

* 実はレトルトパックだったりして

* 美味しいハンバーグという要求には応えている

* きれいなおねーさんの居るお店

* 実は旦那子持ち->問題ない、嘘ではない

* 実は男->おねーさんの定義をもう一度

* 美形が居る->男女別は持ち出していないのでセーフだが、コンテキストが問題

* コンテキストって?

* まぁ、文脈。ラーメン食った後に、A店も美味しいから今度行こうと言われたA店がハンバーグ屋だったら、それは違うだろ
o
c
# コンテキスト的に心がけるコトとか

* 実家の近所では下の名前で通る、苗字を名乗る必要はほぼない

* 実家圏内(2km?)から出ると通用しない

* 更には社名とか肩書とか

* 更には国とか

* ある領域範囲では命名は短くて問題ない

* 本当に?

* publicじゃなければ…

* privateメソッドの中のローカル変数なんてなんでもいいじゃん

* でも、そのメソッド、1000近いステップ数

* privateメソッドのローカル変数の定義に追加するものが出てくる

* 適切な名称を付けるべき vs 長いのがそもそも変だろ
f! ds
e:
# 雑感:必要だと思っているコト

* 読書: 技術書でも新聞でも小説でもマンガでも何でもいい、とにかくボキャブラリを増やせ

* 映画とかでも良い、表現力も増やそう

* 技術原書を読んだことありますか?開発方法論の文書内でシェイクスピアで例えられて理解できますか?

* 英語だからわからないと当たり前のように言うな、俺だってわかんないから辞書引いてるよ

* 因みに、スペルミスは恥ずかしいから注意せよ

* ほんとうの意味での多国籍チームの開発を早く経験しよう、メンバー間の考え方の格差に呆然

* できれば、数学の知識があると面白くなると思う、論理的な考察を強いられるから

* たまに案件では必要なことも(金融とか)、実際、僕はとある案件でMD5ハッシュ暗号化処理をjavaで書いたときに、java.lang.mathとか使いました(たしか、三角関数?、sinだったかと)

* ハウツー本には頼るな、答えのみならず、答えの探し方も必要なコトです

* マネジメントには「ハイ」と返事しろ。反論しても自分の時間が削られるだけだ

* 自己主張と反発は違う

* 説明はするべきだが、アホな質問には「ググれ」で十分。無知は罪。つか、相手、この業界の人だよね?

* 考え方の反転: 人間原理宇宙論って知ってますか?

* 衣食住足りて礼節を知る、あと、睡眠もかな

* 所 、この世は酒と金

Contenu connexe

En vedette

オブジェクト指向ワークショップ 201507版
オブジェクト指向ワークショップ 201507版オブジェクト指向ワークショップ 201507版
オブジェクト指向ワークショップ 201507版
Mao Ohnishi
 
ドメイン駆動設計の捉え方 20150718
ドメイン駆動設計の捉え方 20150718ドメイン駆動設計の捉え方 20150718
ドメイン駆動設計の捉え方 20150718
Mao Ohnishi
 

En vedette (18)

第11回rest勉強会 リファクタリング(クライアント編)
第11回rest勉強会 リファクタリング(クライアント編)第11回rest勉強会 リファクタリング(クライアント編)
第11回rest勉強会 リファクタリング(クライアント編)
 
第10回rest勉強会 リファクタリング(サーバ編)編
第10回rest勉強会 リファクタリング(サーバ編)編第10回rest勉強会 リファクタリング(サーバ編)編
第10回rest勉強会 リファクタリング(サーバ編)編
 
Mizukiryu refactering-20110821
Mizukiryu refactering-20110821Mizukiryu refactering-20110821
Mizukiryu refactering-20110821
 
わんくま名古屋 #32 (20140823) TDD道場 #20
わんくま名古屋 #32 (20140823) TDD道場 #20わんくま名古屋 #32 (20140823) TDD道場 #20
わんくま名古屋 #32 (20140823) TDD道場 #20
 
オブジェクト指向ワークショップ 201507版
オブジェクト指向ワークショップ 201507版オブジェクト指向ワークショップ 201507版
オブジェクト指向ワークショップ 201507版
 
本職のプログラマーが趣味で対戦ゲーム作ってみた Part10
本職のプログラマーが趣味で対戦ゲーム作ってみた Part10本職のプログラマーが趣味で対戦ゲーム作ってみた Part10
本職のプログラマーが趣味で対戦ゲーム作ってみた Part10
 
リファクタリング?
リファクタリング?リファクタリング?
リファクタリング?
 
リファクタリングについてのお話
リファクタリングについてのお話リファクタリングについてのお話
リファクタリングについてのお話
 
20141114 ddd13章 より深い洞察へと向かうリファクタリング
20141114 ddd13章 より深い洞察へと向かうリファクタリング20141114 ddd13章 より深い洞察へと向かうリファクタリング
20141114 ddd13章 より深い洞察へと向かうリファクタリング
 
リファクタリング勉強会 第2回
リファクタリング勉強会 第2回リファクタリング勉強会 第2回
リファクタリング勉強会 第2回
 
Builderによるcompositeの隠蔽
Builderによるcompositeの隠蔽Builderによるcompositeの隠蔽
Builderによるcompositeの隠蔽
 
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコードプログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコード
 
12.11.12 めいめいについて考えること
12.11.12 めいめいについて考えること12.11.12 めいめいについて考えること
12.11.12 めいめいについて考えること
 
レガシーコード改善のススメ
レガシーコード改善のススメレガシーコード改善のススメ
レガシーコード改善のススメ
 
ドメイン駆動設計の捉え方 20150718
ドメイン駆動設計の捉え方 20150718ドメイン駆動設計の捉え方 20150718
ドメイン駆動設計の捉え方 20150718
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
 
PHP版レガシーコード改善に役立つ新パターン #wewlc_jp
PHP版レガシーコード改善に役立つ新パターン #wewlc_jp PHP版レガシーコード改善に役立つ新パターン #wewlc_jp
PHP版レガシーコード改善に役立つ新パターン #wewlc_jp
 
大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)
大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)
大きな泥のカタマリを相手にするためのアジャイルと努力と苦労 by Joe Yoder (XP祭り2014)
 

Similaire à Refactoring

アプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考えるアプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考える
pospome
 
コードの複雑さを測ろう
コードの複雑さを測ろうコードの複雑さを測ろう
コードの複雑さを測ろう
Shinya_131
 
CodingTips+ 基礎編
CodingTips+ 基礎編CodingTips+ 基礎編
CodingTips+ 基礎編
Yusuke Ito
 

Similaire à Refactoring (20)

Howtoよいデザイン
HowtoよいデザインHowtoよいデザイン
Howtoよいデザイン
 
Coderetreat
CoderetreatCoderetreat
Coderetreat
 
アプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考えるアプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考える
 
社内 DDD 勉強会第1回
社内 DDD 勉強会第1回社内 DDD 勉強会第1回
社内 DDD 勉強会第1回
 
トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめトランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
 
ソフトウェア設計原則【SOLID】を学ぶ #1 単一責務の原則(single-responsibility principle).pdf
ソフトウェア設計原則【SOLID】を学ぶ #1 単一責務の原則(single-responsibility principle).pdfソフトウェア設計原則【SOLID】を学ぶ #1 単一責務の原則(single-responsibility principle).pdf
ソフトウェア設計原則【SOLID】を学ぶ #1 単一責務の原則(single-responsibility principle).pdf
 
Visual Studio Code でプログラムをデバッグしよう!
Visual Studio Code でプログラムをデバッグしよう!Visual Studio Code でプログラムをデバッグしよう!
Visual Studio Code でプログラムをデバッグしよう!
 
コンテナー型仮想環境の情報交換会
コンテナー型仮想環境の情報交換会コンテナー型仮想環境の情報交換会
コンテナー型仮想環境の情報交換会
 
Bpstudy26
Bpstudy26Bpstudy26
Bpstudy26
 
コードの複雑さを測ろう
コードの複雑さを測ろうコードの複雑さを測ろう
コードの複雑さを測ろう
 
初心者が伝えるDocker超入門
初心者が伝えるDocker超入門初心者が伝えるDocker超入門
初心者が伝えるDocker超入門
 
LINTから理解するTDD
LINTから理解するTDDLINTから理解するTDD
LINTから理解するTDD
 
DartPad+CodePenで、Flutterを体験してみよう
DartPad+CodePenで、Flutterを体験してみようDartPad+CodePenで、Flutterを体験してみよう
DartPad+CodePenで、Flutterを体験してみよう
 
CodingTips+ 基礎編
CodingTips+ 基礎編CodingTips+ 基礎編
CodingTips+ 基礎編
 
【de:code 2020】 あらゆるエンジニアを支援! VS Code Meetup の紹介とハンズオンで活躍するテクニック集
【de:code 2020】 あらゆるエンジニアを支援! VS Code Meetup の紹介とハンズオンで活躍するテクニック集【de:code 2020】 あらゆるエンジニアを支援! VS Code Meetup の紹介とハンズオンで活躍するテクニック集
【de:code 2020】 あらゆるエンジニアを支援! VS Code Meetup の紹介とハンズオンで活躍するテクニック集
 
20221226_TITECH_lecture_ishizaki_public.pdf
20221226_TITECH_lecture_ishizaki_public.pdf20221226_TITECH_lecture_ishizaki_public.pdf
20221226_TITECH_lecture_ishizaki_public.pdf
 
ABC2016Spring Androidアプリ実装アンチパターン(暫定)
ABC2016Spring Androidアプリ実装アンチパターン(暫定)ABC2016Spring Androidアプリ実装アンチパターン(暫定)
ABC2016Spring Androidアプリ実装アンチパターン(暫定)
 
C・C++用のコードカバレッジツールを自作してみた話
C・C++用のコードカバレッジツールを自作してみた話C・C++用のコードカバレッジツールを自作してみた話
C・C++用のコードカバレッジツールを自作してみた話
 
レガシーコード In WordPress
レガシーコード In WordPressレガシーコード In WordPress
レガシーコード In WordPress
 
Pythonにおけるデバッガツールpdbについて
PythonにおけるデバッガツールpdbについてPythonにおけるデバッガツールpdbについて
Pythonにおけるデバッガツールpdbについて
 

Refactoring

  • 1. # refactoring リファクタリング * 修正ではない 拡張でもない * プログラムを外部視点で動作を変えず、内部構造を整理すること * まだまだ発展途上な技術分野(ソフトウェアは全て発展途上とも言える)
  • 2. t C # 論よりコード * 一度正常に動いたと思えるソースコードは二度と触るな->腫れ物を扱う * これはバグが出ないようにする先人の知恵 * 数年単位のプロジェクトでは まぁ、なるほどと * 日々変わる要件や技術が通常となっている状況じゃ意味のない言葉になりつつあるかも
  • 3. # Code smell * 臭うよ!危険なニオイがソースコードからするよ!
  • 4. # 臭いのもとは? * 重複したコード * 長すぎるメソッド * 巨大なクラス * 他クラスのメソッドを過度に用いる * 不適切な依存関係 * サブクラスのくせにスーパークラスを無視してないか? * それ、オーバライドではなく、置き換えでは? * 同一あるいは同様のメソッドが複数箇所に存在しないか? * 簡潔な設計で十分なところに、過剰に複雑なデザインパターン * 単純にわけわからん 1+2*3 と (1+2)*3 と 1+(2*3)
  • 5. # How to の一例 * 細分化(Class / method) 長いコードはそれだけで大変 / でかいクラスは必ずいびつな形をしている * 関連の一方向化 その参照は必要なのだろうか?オブジェクトは参照されている間生き続ける * 条件分岐のポリモーフィズム化 継承や委譲で条件となる箇所を別に切り分ける * 継承(is-a)を委譲(has-a/use-a)へ 可能であればやる 分岐と条件を切り分ける 静的型言語としての継承は結構制約が多い * 疎結合と密結合 依存関係は出来る限り最小にしよう (javaとかなら、非ジェネリックなimportの数とか、その延長の変数とか指標の一つになる) * バリューオブジェクト 頻繁に見られる同じ引数パターンをまとめて名前をつけてあげる * 名称変更 名前がイケてないの、変えようよ
  • 6. t # そもそも論 * リファクタリングは目に見えて作業進 しない、恐らくゼロ * 塩漬け要件が出来ない->プログラム修正->スパゲッティでわかんないよ! * コスト高くなるよ->わかりやすくしよう->リファクタリングしまーす * リファクタリングにかけるコストは??? * お客さま曰く、「最初からちゃんとしてればそのコストいらないよね」(要件替えるくせに最初からって…要オトナの対応) * 作業じゃないんだよ、空気なんだよ、そう思うのがプロだし、カイゼンってそういうことだよね
  • 7. # test! test!! test!!! * est! est!! est!!! はイタリア白ワインの銘柄の一つです * 動作が変わっていない保証はテスト結果しかない * 大胆な計画と慎重な行動 * とにかく少しずつユニットテスト前提で
  • 8. i # 不遇の時代 * 昔はそんなことをする必要があるコードを書くこと自体が悪 * 漸く冷遇されなくなった手法の一つ(必要性は結構感じられていた) * ただ、動的実行で型がなく、ライブラリのコードを読むのが当たり前の世界だったSmalltalkとかだと、リファクタはふつうのコトだった(リファクタリングがプログラミング作業の半分みたいな感覚) * 設計書をテスト駆動型TDDをベースとする方法で誤魔化すことでXP化が加速されてイイカンジかも * 僕はビヘイビア駆動型BDD(テストコードのクラス名とか変数名とかに要求仕様を書くような意識=自然言語に近づく(英語だけど))が好きです
  • 9. gm g # 手法と手段 * 手段は色いろある(主な項目は前述のとおり、どこぞのアカデミックな偉い人は70通りも考えてくれてるから、遠慮なくネットで検索してそれを使いましょう、車輪の再発明はいらないです) * 対象の絞りこみ方法は決まった、やり方もなんとなくあるって話だ、んじゃ、やれるか?
  • 10. w C w C w C # 予防線を張ります * ここからは僕の想い(手法)の話です、異論は認めますが、まずは聞いてくれ * 異論は認めるが、今日議論をふっかけるのはやめてくれ * できれば議論は来世で… * 因みに結論はありません、聞いて欲しいだけです
  • 11. # バックグラウンド * 例えば、ソースコードを見るとメンバーの誰が書いたのか、60%位の確率で判るんじゃないか? * 40%はスケジュールに追われているとかイラッとしてるとか( `д´) ケッ!とかおもってるとか * 60%?ソレは何故?担当者のバックグラウンドが出ている * 毛穴からにじみ出る汁みたいに * それは、ボキャブラリ、嗜好、受けた教育、その他モロモロ
  • 12. o o # 静的構造と動的構造 * 宗教と静的構造、動的構造の関係って見方がある * 宗教論をするつもりではなく、構造の話です * そもそもツリー構造はどちらかと言うと唯一神キリスト教、ピラミッド構造 * 神オブジェクト(なんでも持ってる)の実在は結構ある * アリストテレスのイデア論って知ってますか? * 八百万の神々とか和をもって尊しとなすとか日本文化チック 八百万の神々を一つにして神オブジェクトをやるととんでもないことになるw * 仏教曼荼羅も仏様いっぱいいる * どうも、西洋と東洋の差があるみたい(継承と委譲) * 最近の作業を振り返って、クラスの構造関係とか動作時のオブジェクト関係とかどう?
  • 13. rn la # 表現と比喩 * 日本語って、表現方法が凄まじい * 例えば、雨 ** 霧雨、小糠(こぬか)雨、小雨: 雨の水滴の形状を指した言葉 ** 時雨(ふったりやんだり)、にわか雨(すぐにやむ): 雨の状況(降り方)を指した言葉 ** 春雨、五月雨、梅雨、秋雨、夕立: 時間や季節を含み持つことになった言葉 * で、例えば、五月雨 ** 梅雨時期の雨のこと ** バラバラと断続的なこと ** 日本海軍駆逐艦、艦これの艦名なのは勝手に議論してください
  • 14. # レトリック * 直喩: 鬼のように強い(鬼の知り合い居ないけど、何となく分かる)(鬼みたいな人の知り合いは結構いる) 類似性を持つ何かに例える * 隠喩: (ムスカ)見ろ!人がゴミのようだ(生ごみとか言っているのではなく、ゴミクズのように大量で捨てられているような感じ(たしか、実際は落ちていた)) メタファーというのはコレのこと、直喩を更に簡潔にした感じ * 換喩: 赤ずきんちゃん(少女が赤い頭巾を被っているのであり、赤い頭巾に似ているのではない、因みに白雪姫(雪のように白い肌のお姫様)は隠喩 * 提喩: セロテープ(あるものを更に一般的な言い方で言い換える) * 法政大学 理工学部 創生科学科 教授 玉井哲雄 氏 * 京都産業大学 コンピュータ理工学部 コンピュータサイエンス学科 教授 青木淳 氏
  • 15. la H # 比喩とオブジェクト指向 * オブジェクト指向に言い換えると、 ** 換喩=集約=has-a(part-of)=抽象データ型 ** 提喩=一般化=is-a(kind-of)=インヘリタンス ** 隠喩=ポリモーフィズム
  • 16. H o c # オブジェクト指向的に心がけるコトとか * カプセル化(定義は色々あるけど、データ隠 で) * 美味しいハンバーグのお店 * 年季の入ったコックさんの技 * 実はレトルトパックだったりして * 美味しいハンバーグという要求には応えている * きれいなおねーさんの居るお店 * 実は旦那子持ち->問題ない、嘘ではない * 実は男->おねーさんの定義をもう一度 * 美形が居る->男女別は持ち出していないのでセーフだが、コンテキストが問題 * コンテキストって? * まぁ、文脈。ラーメン食った後に、A店も美味しいから今度行こうと言われたA店がハンバーグ屋だったら、それは違うだろ
  • 17. o c # コンテキスト的に心がけるコトとか * 実家の近所では下の名前で通る、苗字を名乗る必要はほぼない * 実家圏内(2km?)から出ると通用しない * 更には社名とか肩書とか * 更には国とか * ある領域範囲では命名は短くて問題ない * 本当に? * publicじゃなければ… * privateメソッドの中のローカル変数なんてなんでもいいじゃん * でも、そのメソッド、1000近いステップ数 * privateメソッドのローカル変数の定義に追加するものが出てくる * 適切な名称を付けるべき vs 長いのがそもそも変だろ
  • 18. f! ds e: # 雑感:必要だと思っているコト * 読書: 技術書でも新聞でも小説でもマンガでも何でもいい、とにかくボキャブラリを増やせ * 映画とかでも良い、表現力も増やそう * 技術原書を読んだことありますか?開発方法論の文書内でシェイクスピアで例えられて理解できますか? * 英語だからわからないと当たり前のように言うな、俺だってわかんないから辞書引いてるよ * 因みに、スペルミスは恥ずかしいから注意せよ * ほんとうの意味での多国籍チームの開発を早く経験しよう、メンバー間の考え方の格差に呆然 * できれば、数学の知識があると面白くなると思う、論理的な考察を強いられるから * たまに案件では必要なことも(金融とか)、実際、僕はとある案件でMD5ハッシュ暗号化処理をjavaで書いたときに、java.lang.mathとか使いました(たしか、三角関数?、sinだったかと) * ハウツー本には頼るな、答えのみならず、答えの探し方も必要なコトです * マネジメントには「ハイ」と返事しろ。反論しても自分の時間が削られるだけだ * 自己主張と反発は違う * 説明はするべきだが、アホな質問には「ググれ」で十分。無知は罪。つか、相手、この業界の人だよね? * 考え方の反転: 人間原理宇宙論って知ってますか? * 衣食住足りて礼節を知る、あと、睡眠もかな * 所 、この世は酒と金