読者です 読者をやめる 読者になる 読者になる

Developer Migration 2013に参加しました #devmi

勉強会

http://www.pasonatech.co.jp/ca/devmi2013/

ハッシュタグ#devmi
https://twitter.com/search?q=%23devmi

開発者は仕事でリーダブルなコードを書けるのか?

http://slide.rabbit-shocker.org/authors/kou/devmi-2013/


例1と例2ではどちらがリーダブルなコードか。
例1の方が行数は少ないが、例2の方がリーダブル。
例1は、他のプロパティに対して、他の排他制御をするかもしれない。(mutex2で制御するとか)
例2であれば、このクラスのsynchronizeを呼んでいるため、クラス全体で排他制御をするように見える。


"書いた人の意図"をコードに表す


何しているか・何したいかがわからないコードを読む・変更するのはつらい


リーダブルなコードなら、変更の要求に対して、すぐに対応出来る
⇒オレってばスゲー感


検討を重ねて、必要なものだけを作るっていう考え方もあるが、
それは、コード書いてると時間がかかるから?
必要ないものに時間をかけたくないってことでは?
⇒簡単に試せるのであれば、考えてる間に書いて、動かせる(それで不要になっても、失った時間は少ない)


実サーバから仮想マシンに移行したことにより、追加・削除が容易になった
→コードだって同じ様に出来る(必要になったら、すぐに作る)


バッファを積むより、困ったらすぐ相談出来るような関係性を築いておく。
そっちのほうが、誠実。


リーダブルなコードなら、誰でも直せる
自分の担当コードだけで何とかしようとすると、DRYじゃないコードになる。
修正すべき箇所を修正するべき。
ただし、SIerでは、責任問題とかいろいろあって、難しいかも。


で、本題
"仕事で"リーダルブなコードが書けるのか?


コードレビューが必要といわれるが、読んでくれる人がいない
→まず、自分で読んで見ましょう
時間無いし
→1日15分とか、時間を決めてその時間だけ読む


クリアコードの事業の話
「みんながみんなのコードを読む」文化にする


B2D(Business to Developer)事業
B2CのCの気持ちを考えるより、Dの気持ちのほうが理解しやすいですよね?


読むことの必要性
読んだ経験がないと、どんなコードがリーダブルかわからない


"プロジェクト内のリーダブルなコード"を共有するためにコードレビューする
良いコードを見たら、真似してコミットする(いいね!ではなく行動する)


他の人のコードを読むことで、その人の力量・得意分野がわかる
コミットの間隔を見ることで、生存確認できる?


クリアコードにてサービスも提供していますが、、、
オープンソースソフトウェアの開発に参加してみれば、
そこでの体験を自分の言葉で説明できるのでは?

質疑応答

リーダブルなコードとは、チームのメンバーが同意できるコードということですか?
→YES


コードを読んで、指摘することで、負の感情を与えてしまうのでは?
→日本語で伝えるのが難しければ、コードで語る(こっちのコードが良いのでは?とコミットする)


リーダブルなコードを書くために気をつけていることは?(注:質問内容違ったかも)
→自分の書いたコードは忘れるようにしている
 忘れても、読めるようなコードを書く

あたりまえのアジャイルと、その先の世界

スライドは見つからなかったので、
http://hiroki.jp/2013/03/01/6786/


アジャイル開発のコンサルティングみたいなことをしている人


アジャイル開発が一般的になってきた。ただし、業種による。


アジャイル=not waterfall
それ以上の細かい説明は人それぞれになってしまう


ガラケー→スマホ
CD→iPod/iPhone
パッケージソフトを購入→AppStoreでダウンロード
上記は10年程度での変化⇒変化のスピードは速い


変化の無いものは捨てられていく
 新しくても、生き残れないものもあるけど


開発期間が短くなってきている
 年単位だったものが3〜6ヶ月とか
  1,2日で作った要件定義書から、実装して、みたいな。


技術も変化・拡大していく
 LAMPぐらいでサービスが作れる→とにかくたくさんの技術が必要になってきた


物事は変化するので、それに備えることが大切
→これを解決する一つの策として、アジャイルなプロセスがある


ソフトウェア開発プロセスとは、枠組みである
自分たちに合ったものを選べばよい


Scrum
アジャイルやるなら、まずはこれ。
詳しくは スクラムガイド を参照
理解は容易、しかし、習得が困難。
なぜなら、経験が必要→最初はつらい(経験主義)
Scrumは薄いフレームワークなので、それをやりながら、自分たちに合った手法を取り入れていけばよい。
本を読むことで経験を少しは補える。 サムライ・エピソード
 日本の開発者の経験が書かれている


Skill
Scrumは部門まで巻き込む話。
プログラマとして何をするべきか書いてあるのがXP
Scrumをやるためには必須


プログラマとして、最低限必要なこと
・Git
・言語知識:その言語っぽく(その言語らしい)コードが書けること
・言語設計(オブジェクト設計、オブジェクトデザイン):これを知らないと、スプリント毎につらくなる
テスト駆動開発
・CI:最初(イテレーション0)でやるべき
実装パターンリーダブルコード :パターンを知る
フレームワークの知識:知識がなければ、使わない方がまし
チームに一人は詳しい人が欲しい
デザインパターン
リファクタリング
・インフラのオートメーション化: Pro Puppet



経験からの話


アジャイルにはコーチが必要
半年は必要。3ヶ月とかでは無理。
会社・チームにあったコーチを招くのが理想。


とにかく、学ぶ


GitHubを使いこなす
 http://github-book.doorkeeper.jp/


アジャイルが浸透した会社などが次に目を向けているのはLean
今までの話は、フィードバックループ内のBuildの話だけ。
次にやるべきはMeasure、そして解析
どういうデータを提供すべきかを、エンジニアが見当つけられた方がよい。
なので、初歩的な統計学の知識とかも合ったほうがいいスキルになるだろう。
Leanを学んでみるのなら、 Running Lean

質疑応答

計測・解析について、データサイエンティストになる必要がある?(注:ニュアンス忘れました)
→今のところ、一般的な環境ではそこまでやる必要がない。企画者・プロデューサが理解できないだろうし。
 ツール・可視化はエンジニアがやるだろうから、それぐらいの知識は必要になってくるだろう。

2013年の開発環境で求められるエンジニアとは?


(注:下記はほぼメモのまま)


勉強するべきプログラミング言語・抑えるべき技術についてはディスカッションしません。

自己紹介と発表の内容を簡単に


>大石さん
AWSに特化したSIer
未来予測は意味ないよね。
予測は外れるし。
変化に対応できるようにする


>大塚さん
フリーのアジャイルコンサル
変化に対応するためにアジャイルが必要
それが当たり前になると、Leanへ。
スキル・アジャイルが必要。


>須藤さん
リーダブルなコードとは。
利点と、どうやって実現するか。


>安達さん
DevOpsについて
・採用はいいけど、何を解決したかったの?
・変化が激しい→スキルセットの変化も必要
インフラエンジニア→アプリケーション開発者


これまでの10年を振り返る

・クラウド登場前後での変化


1.クラウドサービスを知ったきっかけ
2.知った前後で何か意識の変化があったか
3.具体的にどんな変化か


>大石さん
2007年にAWSを知った。
まず、コピーしようとした。
S3は作れなかった。実装が意味わからん。
3年30億かけても追いつけない。その時点で枯れた技術だった。(Amazon内で利用していた)
2008年社内サーバ購入禁止令
使う側の技術を極めるように方向転換。


>安達さん
Saasから知った
インパクトが大きかったのはIaas
サーバが使い捨てのイメージに
1年もしたら、新しいのに乗り換えるみたいな。


>大塚さん
ディザスタリカバリがすげーことになったなぐらいー。
古いインフラ屋さん、(=不動産業)はつらいなー。
今では、あたりまえになってきた。


>須藤さん
あんまり覚えてない。Amazon, googleとかで知ったなー。
意識の変化とか、特に無く、
なんかあったら、使おうかなー、ぐらい。


・業務システムへのOSS活用に抵抗なくなったのはいつ頃?
業務システムもOracleばっかりじゃなくなってきた


>大石さん
2005年でMySQL提案したら、蹴られた
2007,8年でやたら高いサーバを買えなくなった。経済的な要因が大きい。


ソラリスとか、見かけなくなった。


>安達さん
2007年とか入社なので、最初から抵抗がなかった。
在籍した部署もOSSを推進するようなところだったし。

2013年以降の展望


・SIの今後


>大石さん
ボタン一発で、一括リプレースとかが可能になってきた。
SIのピラミッドの、下の方の人達が必要なくなってきた。
人がたくさんいるから、コミュニケーションスキルが大事だった。
→人がすくなければ、そんなに必要ないので、コミュニケーションスキル<技術となってきた。


>須藤さん
大きなピラミッドにかかわってきてない


>大塚さん
ピラミッドから1年で脱出しちゃった


>安達さん
自分のいた部署はそうじゃなかったが、周りの人達はピラミッド構造の中にいて、大変そうだった



・SIのビジネスモデル変化で今後意識した方がよいことは?


>安達さん
インフラチーム・アプリチームの分業だった
→一人のエンジニアが全てやるようになってきた
 いなくなった時のことを考えペアとかにはするけど、個人が一通り出来る必要がある


>須藤さん
開発・運用・監視とかは一通りやってる
SIのビジネスモデルから離れたところで仕事するのがいいのでは。(B2Dみたいに)


ストレッサー
=ストレス要因となるもの
 人によって異なる

・外部環境変化が「ストレッサー」にならなかったか?


>小山田さん
変化をわりと楽しめている
この進行役も緊張/ストレスは感じるけど、楽しめる


↓いろんな環境変化を経験してますよね?
>大塚さん
SIがストレス→やめる
不動産業ストレス→やめる
ソフトウェア開発がストレスだから、それを変えるためにアジャイルを進めている
ソフトウェア開発がストレス=納期・金額をどんぶり勘定で押し付けられる


>安達さん
自分が変わらないと、という危機感から変化する
違う強い思いから、外的変化がストレスを感じない


↓普通のSI→AWS特化への変化
>大石さん
ストレスにはなる
AWS特化になって、インフラのリーダーがいやになってやめた。
→ストレスだったんだろう。
その後戻ってきた
普通になってきたから?
だいたいのことは、命までは取られないから、1,2年我慢してみたら。
ストレス耐性高い=パフォーマンスが高い(一般論として)


↓ストレス耐性は、先天的にもってるもの?後天的に得られるもの?
>大石さん
自分はストレス耐性が無かった(学生時代のテストとか)
プレゼンも全く緊張しなくなってきた
 聴衆が、見てない・覚えてないことをわかったから
自分の覚えた言語が無くなったみたいなことも経験してきた
 経験・達観・前のあれみたいなやつ
 例:クラウド=タイムシェア・集中コンピューティング
学習により、ストレス耐性がつく


>須藤さん
どんな変化によるかで違う
 技術的な変化は楽しい
会社の経営はストレス、いろんなことを決めなくてはならない
しかし、周りの人にいろいろ教えてもらって、楽になってきた
判断基準を学んだ
好きじゃないものでも、ストレス対象にならなくなってくる


↓パネルディスカッションは初めてらしいですがストレス?
>須藤さん
ストレスというか、どうしたらいいかわかんない感じ


・ご自身なりの「キャリア戦略」をお持ちですか?


>小山田さん
コードが書けるキャリアコンサルタント
QuitaのiPhoneアプリを申請中
技術者と話すときに、共通言語で喋れる=相手の力量が計れる


>大塚さん
意識は特になく、自分が何が出来るか、何を提供できるかを明確に持っている、ぐらい


↓ブログのテーマ選択とかの基準は?
>大塚さん
ブログは仕事を意識して書いてはいない。

基本的に、経験したものしか、自信をもって提供できない


↓インフラ寄りの人はアウトプットの仕方が難しいですよね?
>安達さん
ブログは書けない(外にだせない)こともある
キャリア戦略としては、人と違うことをやってみる
DevOpsでインフラ・アプリが出来る
マーケティングが出来るエンジニア
デザインも出来るエンジニア
とか。


↓マーケティング・デザインなど、何を基準に次の領域を選ぶ?
>安達さん
一人で設計・開発・運用が出来るようになるにはを考えている
結びつかないような(他人がやらないような)技術領域にチャレンジ
インフラもデザインも出来る、とか。


↓安達さんみたいなひと(なんでもやる)が採用にエントリーしてきたら?
>大石さん
基本、キャリア戦略とか信用してない
会社としてはマルチタレントが欲しいので、好印象。
ただし、キャリア戦略よりも、今、会社内で評価されてるか
 過去・現実の評価があること
今の環境でベストを尽くせない人は、どこへ行ってもベストを尽くせない。


↓変わった採用方法を採ってますよね?
>須藤さん
http://www.clear-code.com/recruitment/:パッチ採用
戦略より、コード書けよ。


↓採用にかかる期間、長いですよね
>安達さん
採用に半年かかる
採用は結婚


↓フィーリングが合いそうな人とは?
>須藤さん
積み重ねが必要。(これさえクリアしたら、みたいなものではない)
コーディングスタイルを個々のプロジェクトに合わせる(不要な我を全面に押し出さない)
他の人も考えたコードを書く


>安達さん
同棲してみて、価値観をすり合わせる
積み重ねていく


↓一方的にアウトプットする人ではなく、協調出来る人?
>安達さん
会社が若いので、変化も体験してもらいながら、価値観をすりあわせていければ。


・なぜリーダブルなコードが必要なのか?
>須藤さん
リーダブルじゃないコードを見続けるのがつらい→ストレッサー
なんかあった時にすぐ対応できる→"変化"に対応


・リーダブルなコードのビジネス上の利点
↓「お客さんの要望に答えやすい」以外に
>須藤さん
開発者が死んで行かない
精神衛生上やさしい


↓こんな利点が、とかあります
>大塚さん
リリース後の方が時間が長い(短納期)
書く時間<読む時間 になってる
リーダブルなコードが必要なのではなく、リーダブルなコードを書ける人が必要
↑それには、リーダブルなコードを読む必要がある(鶏が先か卵が先か)


>大石さん
マイコンBASICマガジンというドMな雑誌が昔ありました。
昔、リーダブルより、メモリ節約だった。それを写経で覚えた。
新入社員にリーダブルなコードを写経してもらおうかと考えてる
 自分もやらされそうだけど。


・コード書けないエンジニアの立場ってどう思うか?
>安達さん
インフラエンジニアは昔はコーディングしなくてよかった。
インフラ構築のためにコードが必要になってきた
料理の作れない料理人(いらない人)=コードの書けないエンジニア になってくる


>大塚さん
ネットワーク・インフラとかは(コードを書けないエンジニアでも)必要では?
中途半端な領域の立場の人は危ういだろうけど、
DC1から作れますとか、極めたひとはコードは必要ないのでは


>安達さん
物理的なものに特化した人はコードが書けなくていい
 ネットワーク仮想化とかでコードで解決する技術領域が広がってくるとわからないが。


・「コード書けるようになりたい」という気持ちを持ったエンジニアに何かヒントを
>大石さん
コード書けばいいですよ。
写経。
コード書けないエンジニアも、前までは必要だった。
Excel書くとか、人と人をつなぐとか。
これからは、そういう人が減ってくる。
綺麗なコードを書ける人は、論理構造の綺麗な日本語を書ける。
ドキュメントもコードも言語なんだから、ちゃんと日本語書けた人は、コードも書けるはず。


>大塚さん
コード書いてる人向けに言うと、テストを書けるようになれ。
テストを書けるようになるには、テストコードを写経する。
常識の位置を変える。
テストを必ず書く、を徹底する
チーム内で自分だけ書いてる人もいる。
意識を変えていく。


↓テストを個人プロダクトで書けてない。モチベーションが上がらない。どうしたらいい?
>大塚さん
WEBアプリ作るときに、コード書く→F5 をやりたければ、それをやれば。
書かなければいけない、トレーニングを強制する。
とりあえず、1つ書いてみる。
仲間を作る。議論しあえる。


>大石さん
会社では、テスト通らないとYammerに報告される
→はずかしい



・参加者からの質問


・AWS以外にいいのありますか?
 ソフトレイヤーとかいいのでは?


>大石さん
Amazonの人いないですよね。。。下手なこと言うと、怒られちゃう。
IAASはAmazonでよいのでは?
あとは、それぞれの得意領域に合わせて選択していけばいい。(ストレージが安いところと、簡単にアプリを作れるところをつなぐ、とか)
組み合わせだけで、作らない開発ができるのでは。


・写経するのにおすすめのものはありますか?
 Ruby/JavaScriptとかで。
>須藤さん
自分が使ってるサービスをやってみれば。その方がイメージつきやすいし。
Redmineとか?
いいと思います。
とりあえずやってみればいいと思う。
で、いくつかやってみる。


>大塚さん
実装パターンを読んでみるとか。
コードは小さなパターンの組み合わせ。
元ネタがあると、実用的かどうかを判断しやすい。


・テストコード書く際に徹底させるべきこと
>須藤さん
とりあえず、リーダブルコードをまず読んでください。
自分のコードをリーダブルにする。


>大塚さん
計画が大事なのは当たり前だが、振り返りも大事。
定期的に振り返りを行う。
日々の積み重ねを行う。


・コード書ける人が、インフラを学ぶヒント
>安達さん
Rubyをやってるのであれば、サーバ内で動いているスクリプトをRubyで書いてみたら?


>大石さん
サーバワークスという会社がありますよ。今回は採用みたいな話は出来ないのですが。
個人でやるのは限られる。大きなものをやるには会社が必要。
上長を巻き込む・説得する。
経営的なメリットがあるらしい、と上長に訴え、ボトムアップでやる。