DevLOVE仙台 オブジェクト設計とリーン開発、その実践

2013/11/30 (土) に開催した、DevLOVE仙台 オブジェクト設計とリーン開発、その実践 のまとめです。 http://devlove-sendai.doorkeeper.jp/events/6549
4
藤原大 (Dai Fujihara) | アジャイルコーチ @daipresents

いくぜ、東北! DevLOVE仙台 オブジェクト設計とリーン開発、その実践 #devlove #DevSen http://t.co/q0DRTTb1Vr via @devcchi

2013-11-29 22:24:18
ichitani / 組織を芯からアジャイルにする @papanda

あすは塹壕をめぐる旅。-- DevLOVE仙台 オブジェクト設計とリーン開発、その実践 #devlove #DevSen http://t.co/rdcEG15Eq2

2013-11-29 22:32:24
仙台課長 @hananosuke44

いよいよ本日午後となりました! そして申込み限界まで30分! 11/30 「DevLOVE仙台 オブジェクト設計とリーン開発、その実践」 http://t.co/UU9rzqg4cb #DevLOVE #DevSEN

2013-11-30 10:33:08
小泉勝志郎 @koi_zoom1

#devlove #DevSen DevLOVE仙台、パパンダさんの前説中

2013-11-30 13:13:46
小泉勝志郎 @koi_zoom1

#devlove #DevSen 増田さんから「リーンなコードを書こう」

2013-11-30 13:15:36
小泉勝志郎 @koi_zoom1

#devlove #DevSen 増田さん:1.リーンな開発はリーンなコードから。2.コードをリーンにする。コードの改善準備、コードの重複をなくす、変更の副作用をなくす、for文を扱いやすくする、if文/switch文を部品に分解する。

2013-11-30 13:19:30
YAMAMOTO Masaki @nnasaki

増田さんの話、自身の体験を交えてくれてとてもわかりやすい。 #DevLove #DevSen

2013-11-30 13:21:21
小泉勝志郎 @koi_zoom1

#devlove #DevSen 増田さん:制御文はバグの温床。if文/switch文を使わずに条件分岐することがオブジェクト志向ならできる

2013-11-30 13:23:41
仙台課長 @hananosuke44

継続的な改善 これがリーンな開発のすべてだ 増田さん #DevLOVE #DevSEN

2013-11-30 13:24:04
YAMAMOTO Masaki @nnasaki

開発のやり方(プロセス)だけ変えてもダメ。コードの変更コストを下げる。両方必要。 #DevLove #DevSen

2013-11-30 13:25:08
YAMAMOTO Masaki @nnasaki

コードは見た目の美しさや教科書的なものを追求しなくても、現場のメンバーのスキルや環境によって歪めても良い。 #DevLove #DevSen

2013-11-30 13:26:57
小泉勝志郎 @koi_zoom1

#devlove #DevSen 増田さん:継続的な改善。これがリーンな開発のすべて。スッキリとしたムダのないコードは変更がやりやすい。変更がやりやすいと改善スピードが加速する。教科書的でなくても現場で変更がやりやすいを目指す

2013-11-30 13:27:25
YAMAMOTO Masaki @nnasaki

コードの変更コストが下がれば、アジャイルなやりかたで追加で作成することが可能になる。ウォーターフォールはコードの変更コストが高いのが前提なので、最初に計画をキッチリ立てて分割する必要がある。 #DevLove #DevSen

2013-11-30 13:29:27
小泉勝志郎 @koi_zoom1

#DevLove #DevSen 増田さん:DevSENなのでメタボなコードについて。それば変更が大変なコード!どこで何やっているかわからない、コピペの臭い、変数名が微妙、コメントが意味不明、ちょっとした変更があちこちに飛び火、結局全部やり直し……

2013-11-30 13:30:51
YAMAMOTO Masaki @nnasaki

新規の開発だけやってたら、オブジェクト指向に目覚めなかったかもしれない。C+SQLだけで問題ないと考えていたこともあった。 レガシーコードに触れることが多くなり、オブジェクト指向の良さに気がついた。 #DevLove #DevSen

2013-11-30 13:39:53
YAMAMOTO Masaki @nnasaki

コードを改善する機会は、変更が必要になった時。既存の機能をリファクタリングしてから、最後に変更箇所を追加する。 #DevLove #DevSen

2013-11-30 13:50:18
小泉勝志郎 @koi_zoom1

#devlove #densen 増田さん:みなさんInteliJ使いましょう!

2013-11-30 13:50:31
YAMAMOTO Masaki @nnasaki

増田さんは IntelliJ 推し!! まるで優秀なプログラマーとペアプロしてる気分になれるそうです。 #DevLove #DevSen

2013-11-30 13:51:36
小泉勝志郎 @koi_zoom1

#devlove #DevSen 増田さん:コードの整理。変更するコードとそうでないのを区別する、今回変更の対象となるデータと操作だけを集めた部品(メソッド)を作成する!

2013-11-30 13:56:01
YAMAMOTO Masaki @nnasaki

メソッド分割について、変更箇所をメソッドにする。変更されているコードはメソッドにしてまとめているという風にする。 #DevLove #DevSen

2013-11-30 13:57:07
小泉勝志郎 @koi_zoom1

#DevSen #devlove 増田さん:メソッド分割の原則。分割しすぎると一連の流れが追いにくい。確かにそうだが、バラバラの部品に分けて変更がやりやすいように組み立て直す。これでコードがわかりやすくなる味を覚えよう!計算式が1行だけでもメソッドにする

2013-11-30 14:00:38
YAMAMOTO Masaki @nnasaki

メソッド分割しすぎると一連の流れが追いにくくなるのでは? → YES 。 けれども、一連の流れ=手続き型プログラミング から抜け切れていない。分割することは変更の視点で行う。 対象が計算式1行でもメソッドにする。コードの長さは分割に関係ない。 #DevLove #DevSen

2013-11-30 14:03:06
小泉勝志郎 @koi_zoom1

#DevSen #devlove 増田さん:メソッドチェインは変更の視点から考えると危険なところかある。1ステップずつ分割する

2013-11-30 14:03:55