20100226 jim coplien said you should foster generative scheme in your system

しまだこうじSHIMADA Koji

日本Rubyの会Ruby札幌

Jim Coplien said you should foster generative scheme in your system.2010-02-26 Ruby Sapporo Night vol.13アップルストア札幌

パターンから東方のリーンそして西方の真のオブジェクトへから学んだことを北で

2010年3月1日月曜日

意味があると感じる方向に進むと良いと思う

- Shintaro KAKUTANI


提供

Ruby札幌From Sapporo, with Love for Ruby.


しまだこうじ島田浩二

Photo by tmaeda


http://www.flickr.com/photos/tmaedax/3845208228/

http://www.flickr.com/photos/tmaedax/3845208228/

Sapporo is a beautiful provincial city of Japan.

Photo by enggul


http://www.flickr.com/photos/enggul/2260756550/

http://www.flickr.com/photos/enggul/2260756550/

Our Base


Our Dream2010年3月1日月曜日

from Sapporo,with Love for Ruby

Photo by darashi


http://www.flickr.com/photos/darashi/3209968808

http://www.flickr.com/photos/darashi/3209968808

日本Rubyの会2010年3月1日月曜日

一般社団法人 LOCAL


e "rst editionstill in store.


よろしくお願いします


http://www.amazon.co.jp/exec/obidos/ASIN/4873114381/butitsuptoust-22

広告




今日のお話


道2010年3月1日月曜日

人の活動を支え動作しつづけるきれいなコードのために私たちが出来ることを探す

島田浩二[email protected]

— Where e Street Has No Name.

2010年2月13日(土) LOCAL DEVELOPER Day’10 Winter


mailto:[email protected]?subject=


A Handbook of Agile Software Craftsmanship


第１部2010年3月1日月曜日

Welcome to The Desert

of The Real

現実世界の砂漠で


前回のRSN


現実の世界


✓ 開発の現場✓ 運用の現場✓ コードベース✓ 顧客

痛みに充ち満ちている


✓ ほとんどの障害が開発者の関与を必要とする✓ 開発チームと保守チームの関係が冷ややか✓ 保守チームが新しいアプリケーションを嫌がる✓ アーキテクトと開発チームが本番システムで多くの時間を費やしている

✓ 問題解決の手段としてアプリケーションが頻繁にリスタートされる

✓ システム管理者がトラブルに追われ、システムのチューニングに時間を使えない

危険な匂い

『97 Things Every Software Architect Should Know』2010年3月1日月曜日


of The Realhttp://www.slideshare.net/kakutani/welcome-to-the-desert-of-the-real


http://www.slideshare.net/kakutani/welcome-to-the-desert-of-the-real



of The Real

ビジネスとしてソフトウェアづくりに関わるにあたって本当にそれだけで十分なのか？本当に？


現実の世界


✓ 予算✓ 時間✓ メンタル✓ 情熱、余裕、心

全てのリソースは限られている


いち開発者である自分には企業資産(つまりコードベース全体)の価値を低下させるような権限はない

- Shintaro KAKUTANI


Yes, the world is crazy.





of The Real

どうしたらよいか全く分からない


第２部2010年3月1日月曜日

http://www.objectclub.jp/event/2010alexander/

1月15日東京オリンピックセンター




オブジェクト倶楽部アレグザンダー祭 2010-01-15

James O. CoplienScrum Training Institute

Gertrud & Cope

[email protected]

From Patterns:Eastward to Lean,

Westward to true objects

http://www.objectclub.jp/event/2010alexander/James.O.Coplien



James O. CoplienScrum Training Institute

Gertrud & [email protected]

From Patterns:Eastward to Lean,

Westward to true objects




まとめ

• パターンとTPS• アジャイルとリーン• 失われた価値• リーンアーキテクチャとDCI


詳細はスライドと動画を見ていただくとして…


僕がCopeのスライドで特に印象に残った所



Missing from Scrum...

80% of software is maintenance

Toyota knows that: 総生産性メンテナンス

Hope in software:




✓ 無くしたものがよくわからなかった✓ ソフトウェアの80%が保守だとして、どうすれば✓ この文脈で Clean Code が希望？？


第３部2010年3月1日月曜日

人の活動を支え動作しつづけるきれいなコードのために私たちが出来ることを探す

島田浩二[email protected]

— Where e Street Has No Name.

2010年2月13日(土) LOCAL DEVELOPER Day’10 Winter





- Shintaro KAKUTANI


もう一度基本へ戻る


心があるとき僕が確かに意味があると感じている方向


もう一度基本へ戻る


ソフトウェア設計とは何か- Jack W.Reeves


ソフトウェア設計とは何か？

✓ 設計: ソースコード✓ 製造: ビルド


コーディングは設計であり、テスティングとデバッギングも設計の一部であり、私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです


付録B:Naur,Ehn,武蔵

http://www.amazon.co.jp/exec/obidos/ASIN/4894715791/butitsuptoust-222010年3月1日月曜日

http://www.amazon.co.jp/exec/obidos/ASIN/4894715791/butitsuptoust-22/ref=nosim


• プログラマによる現実世界の問題をプログラムで解決・サポートする方法についての理論構築• プログラムのテキストを生み出すことではない

理論構築としてのプログラミング


• 知識はプログラマが所有するものであり全てのドキュメントは補助的で二次的な産物でしかない• ドキュメントだけから理論を再構築することは不可能

理論構築としてのプログラミング


コーディングテスト

ヒアリング

ソフトウェア開発のアクティビティ

設計2010年3月1日月曜日

ソフトウェア開発のアクティビティ

コーディングテスト

ヒアリング設計

メタファー

計画ゲーム

短期リリース

40時間労働

単純な設計

オンサイト顧客

テスティングペアプログラミング

コーディング規約集団所有継続した統合

リファクタリング


変化ヲ抱擁セヨ


変化2010年3月1日月曜日

変更はソフトウェアを特徴付けるものである。変更すなわち適応は、リリースで始まる。リリースがソフトウェアの生涯の真の始まりであり、それ以前はすべて妊娠期間だ。システムは時と共に成長し、変化する環境に適応していくか、あるいはコストが利益を上回るまで堕落して、死に至る。

　- マイケル・ナイガード『Release It!』


変化2010年3月1日月曜日

運用が痛みを伴うものであってはならない


問い続けた末にたどり着いた答え（と思われるもの）


道2010年3月1日月曜日

何百年にもわたって生まれてきた、いきいきとした建物や町を現代の建築家が生成出来るようにするための“道”


18. ランゲージの発生力19. 空間の分化20. 一度に一つのパタン21. 建物の形成22. 建物群の形成23. 施工のプロセス24. 修復のプロセス25. 町のゆるやかな出現26. 不滅の特性

道


道18. ランゲージの発生力19. 空間の分化20. 一度に一つのパタン21. 建物の形成22. 建物群の形成23. 施工のプロセス24. 修復のプロセス25. 町のゆるやかな出現26. 不滅の特性


形成

施工

修復

全体を生成するプロセス


...庭を改良する機会があれば、一度の建設行為によって二つの不完全なパタンを改修できるのである。ここでやろうとしていた修復は、単なる「修復」ではなく、最初の設計の欠陥を複合的に解消する新たな設計なのである。...


...新しい意味での修復では、何かを変質しようと考え、新たな全体を生み出そうと考え、実際、修復された全体そのものが、修復の結果としてまったく異なる全体に変わると考える。...このような意味で、修復の概念は創造的で、動的で、開放的である。...


...そこでは、既存の全体がかかえる欠点に注目しつつ修復を試みれば、絶えず新しい全体の創出に導かれると考える。あらゆる行為が、より大きな、より古い全体の修復を助けるという点では、これまで通り正しい。だが、ここでいう修復は一時的な継ぎはぎだけでなくーーー既存の全体を修正し、変質させ、何か全く別のものに向けての路線を引くことなのである。...


...このように、最も単純かつ実用的な方法で、小さな増築部分の豊かさと独自性が生まれるのである。既存の建物の欠陥に注目し、それを修復しようという熱意さえあれば、それはほぼ自動的に生まれてくるのである。...このようにして建てた建物の部分部分は、思いもかけぬほど豊かで変化に富むものになる...






Hope in software:




A Handbook of Agile Software Craftsmanship


洗練されたコードは、どうして、こうも早く粗悪なコードへと変質してしまうのでしょう? ... 間違っているのは我々自身なのです。これでは、我々はプロとは呼べないのです。...つまり、あなたがそれに負けない熱意をもって、コードを守ればよいのです

ーークリーンコード、ロバート・C・マーチン






Hope in software:




Cope自身による前書き


...もしもこの本を読み進め、そして実践するという挑戦を続けるのであれば、やがて、最終到達点を理解し、そして評価することになるでしょう。ついに私たちは、製品のライフサイクルに関係した職業における、責任の重いプロ意識の根幹へとたどり着きました。


故障の修理(バグが露呈するまで待つこと)というのは例外なのです。そうではなく、水準を一つ上げるのです。...こうした手入れや修理というものに終わりはありません。...クリストファー・アレグザンダーは、１つ１つの設計作業は局所的な小さな修復作業であると見なしています。...設計に終わりはありません。...


形成

施工

修復



変更はソフトウェアを特徴付けるものである。変更すなわち適応は、リリースで始まる。リリースがソフトウェアの生涯の真の始まりであり、それ以前はすべて妊娠期間だ。システムは時と共に成長し、変化する環境に適応していくか、あるいはコストが利益を上回るまで堕落して、死に至る。

　- マイケル・ナイガード『Release It!』


形成

施工

修復



開発

稼働

適応



適応2010年3月1日月曜日

適応しつづける


!"#$%&'()*+,-./01-2345

6789:0;<=13-A-5

>?@AB*)8CDCEF

http://tinyurl.com/yejdboj








Hope in software:




変化ヲ抱擁セヨ


まとめ


✓ ソフトウェア開発に(足りていない|必要な)のは、アレグザンダーの言う「修復のプロセス」-Clean Code is hope in software.

✓ ここから先はきっと Cope から僕らへの宿題✓ “As ten years ago: chances for success in Japan is higher than in West.”

まとめ



- Shintaro KAKUTANI


ご清聴ありがとうございました


20100226 jim coplien said you should foster generative scheme in your system

Technology