Download SlideShare for Android. 15 million presentations at your fingertips  Get the app
×
  • Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 
« ‹ › »
   

メンテナブルなJsってなんだろう

on

  • 287 views

 

Statistics

Views

Total Views
287
Views on SlideShare
162
Embed Views
125

Actions

Likes
0
Downloads
1
Comments
0

4 Embeds 125

http://developer.cybozu.co.jp 57
http://toarudia.hatenablog.com 56
https://twitter.com 11
http://feedly.com 1

Accessibility

Categories

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 世界中のチームワークを良くすること <br /> Mission <br /> 　世界中のチームワーク向上に貢献する <br /> <br /> Vision <br /> 世界で一番使われるグループウェアメーカーになる <br /> <br /> CoreValue <br /> 顧客体験のすべてにおいて「Fast&Easy+Entertain」を
  • 新卒サイトのキャプチャ <br /> 世界中のチームワークを良くすること <br /> Mission <br /> 　世界中のチームワーク向上に貢献する <br /> <br /> Vision <br /> 世界で一番使われるグループウェアメーカーになる <br /> <br /> CoreValue <br /> 顧客体験のすべてにおいて「Fast&Easy+Entertain」を
  • グループウェア <br /> ホームページのキャプチャ
  • コードを書くときにこれが原因でどんなやりにくさがあるか <br /> 　探すのが大変とか。影響範囲がわからない。JSのUnitテストはない <br /> 　周りに合わせてスタイルを整える
  • コードを書くときにこれが原因でどんなやりにくさがあるか <br /> 　探すのが大変とか。影響範囲がわからない。JSのUnitテストはない <br /> 　周りに合わせてスタイルを整える
  • 既存のコードを確認 <br /> <br /> 多数決 <br />
  • 問題を強調（覚えきれねぇ） <br /> CIにのせる <br />
  • えらーでまくる
  • どういう方針で進めていくか
More…

メンテナブルなJsってなんだろう メンテナブルなJsってなんだろう Presentation Transcript

  • メンテナブルなJSってなんだろう 松元 @datomotu 2014/ 0 6 /1 4
  • 自己紹介 名前 松元 大樹（まつもと だいき）@datomotu 出身 広島 好きな言語 JavaScript 好きななにか 運動、アクアリウム、カメラ、YouTube サイボウズ株式会社（４年目） 松山開発部 PG
  • サイボウズについて サイボウズについて ちょこっと紹介させてください。
  • サイボウズについて http://cybozu.co.jp/company/job/recruitment/business/
  • サイボウズについて https://www.cybozu.com/jp/service/
  • 今から話すこと メンテナブルなJSを書くために 現在プロジェクトで行っている 取り組みの話
  • 今から話すこと メンテナブルなJSを書くために 現在プロジェクトで行っている 取り組みの話 TypeScriptの話は出てきません。
  • 経緯
  • 経緯 サイボウズ Office
  • 経緯 サイボウズ Office • ここ数年JSでの開発が増えている
  • 経緯 サイボウズ Office • ここ数年JSでの開発が増えている • ライブラリのぞいて2万5千行くらい
  • 経緯 0 5000 10000 15000 20000 25000 30000 合計
  • 経緯 JSのメンテナンスコストが 日々増大していっている感じがする
  • 経緯 JSのメンテナンスコストが 日々増大していっている感じがする • スタイルがファイルによって異なる • コードを探すのが大変
  • 経緯 JSのメンテナンスコストが 日々増大していっている感じがする • スタイルがファイルによって異なる • コードを探すのが大変 • 影響範囲が予測できない • JSのUnitテストがない • コード変更が億劫に
  • 経緯 要はメンテナブルじゃない！
  • 経緯 要はメンテナブルじゃない！ メンテナブルにしたい！
  • 経緯 要はメンテナブルじゃない！ メンテナブルにしたい！ メンテナブル化←ｲﾏｺｺ
  • 経緯 要はメンテナブルじゃない！ メンテナブルにしたい！ メンテナブル化 プロ生愛媛←ｲﾏｺｺ
  • メンテナブルとは？
  • メンテナブルとは？ ちゃんとしてる なんかいい感じ
  • メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。
  • メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。
  • メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 • 変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
  • メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 • 変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
  • 読みやすい。を目指す
  • 読みやすい。を目指す 状況 • スタイルガイドがゆるい • その時代時代のスタイルで書かれている • PGの数だけ存在しているコーディング スタイル！
  • 読みやすい。を目指す 行ったこと • スタイルガイドの作成 • 静的解析 • 自動整形
  • 読みやすい。を目指す 行ったこと • スタイルガイドの作成 • 静的解析 • 自動整形
  • 読みやすい。を目指す – スタイルガイドの作成 スタイルガイドを 作成する必要がある？
  • 読みやすい。を目指す – スタイルガイドの作成 他所から輸入するのじゃだめ？
  • 読みやすい。を目指す – スタイルガイドの作成 他所から輸入するのじゃだめ？ NG • 既存コードとの兼ね合い
  • 読みやすい。を目指す – スタイルガイドの作成 おれおれスタイルガイドを作ってから チームに広める？
  • 読みやすい。を目指す – スタイルガイドの作成 おれおれスタイルガイドを作ってから チームに広める？ NG • 本当に良いスタイルなのか分からない • 大変
  • 読みやすい。を目指す – スタイルガイドの作成 おれおれスタイルガイドを作ってから チームに広める？ NG • 本当に良いスタイルなのか分からない • 大変 • おれが嫌われる・反感買う • チームワーク崩壊の恐れ
  • 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？
  • 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる
  • 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる • スタイルガイドの存在を脳裏に・・ • そういえばスタイルガイド決めたなー • 自分たちで決めたルールだから守らねば！
  • 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる • スタイルガイドの存在を脳裏に・・ • そういえばスタイルガイド決めたなー • 自分たちで決めたルールだから守らねば！ • おれが悪者にならない
  • 読みやすい。を目指す – スタイルガイドの作成 みんなで作ろう！スタイルガイド！
  • 読みやすい。を目指す – スタイルガイドの作成 作り方 • 各スタイルについて全員で議論 • 自分たちのスタイルガイドに記載する べき内容なのか。 • どう記載するのがベストか。
  • 読みやすい。を目指す – スタイルガイドの作成 作り方 • 各スタイルについて全員で議論 • 自分たちのスタイルガイドに記載する べき内容なのか。 • どう記載するのがベストか。 • 決まったスタイルは 即スタイルガイドに記載！
  • 読みやすい。を目指す – スタイルガイドの作成
  • 読みやすい。を目指す – スタイルガイドの作成 • 第I部 スタイルガイドライン • 第II部 プログラミング実践 • 第III部 自動化 • 付録 A JavaScriptスタイルガイド • 付録 B JavaScriptツール
  • 読みやすい。を目指す – スタイルガイドの作成 具体的な進め方 • 毎週1時間の輪講を行う • 一回で1章くらい進む • 1~4章なので4時間。約一ヶ月で完成する
  • 読みやすい。を目指す – スタイルガイドの作成 • 第I部 スタイルガイドライン • 1~4章 • 第II部 プログラミング実践 • 5~12章 • 第III部 自動化 • 13~20章
  • 読みやすい。を目指す – スタイルガイドの作成 たとえば
  • 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている • 小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC）
  • 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている • 小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC） • 一般論として、使用しているコア言語 に従った命名規則を常に使うべき
  • 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている • 小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC） • 一般論として、使用しているコア言語 に従った命名規則を常に使うべき • Google SproutCore Dojoもほとん どの状況でキャメルケース
  • 読みやすい。を目指す – スタイルガイドの作成 • 変数名は名詞で始まるようにすべき • 名詞で始めることで変数を区別するのに 役立つ
  • 読みやすい。を目指す – スタイルガイドの作成 • 変数名は名詞で始まるようにすべき
  • 読みやすい。を目指す – スタイルガイドの作成 • 関数は動詞で始めるべき
  • 読みやすい。を目指す – スタイルガイドの作成 • 関数は動詞で始めるべき
  • 読みやすい。を目指す – スタイルガイドの作成 • 関数の先頭は動詞にすべき • よく使われる動詞 動詞 意味 can ブーリアンを返す has ブーリアンを返す is ブーリアンを返す get 非ブーリアンを返す set 値を保存するために使 われる
  • 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき
  • 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき • 変数名からデータ型が分かるとよい • count,length,sizeは数値 • name,title,messageは文字列 • i,j,kはループの中で使用される
  • 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき • 変数名からデータ型が分かるとよい • count,length,sizeは数値 • name,title,messageは文字列 • i,j,kはループの中で使用される • 無意味な名前は避けるべき • foo,bar,temp
  • 読みやすい。を目指す – スタイルガイドの作成 このぐらい初歩的なところから議論
  • 読みやすい。を目指す – スタイルガイドの作成
  • 読みやすい。を目指す – スタイルガイドの作成
  • 読みやすい。を目指す – スタイルガイドの作成 大変だったところ • 好みの違いによる論争議論 • インデントの好み • function(){ vs function() { vs function () { • “ vs ‘ • 議論の基準を設けた • 既存コードの兼ね合い • メリット・デメリット • デグレリスク • それでも決まらないときは多数決
  • 読みやすい。を目指す – スタイルガイドの作成 問題点 • メンテナブルJavaScriptⅠ部の スタイルガイドラインの章だけでは網羅 できない • 足りないスタイルガイドを列挙して議論する
  • 読みやすい。を目指す – スタイルガイドの作成 よかったところ • スタイルで悩む時間がなくなる • レビューしやすい
  • できた！ スタイルガイド！ やったー
  • でも スタイルガイドに合わせて書くの 正直、めんどくさい
  • 何が正解なのか忘れる。
  • 機械的に確認できるところは 考えたくない！
  • 読みやすい。を目指す 行ったこと • スタイルガイドの作成 • 静的解析 • 自動整形
  • 読みやすい。を目指す – 静的解析 • JSHintを導入 • スタイルガイドに合わせてJSHintの オプションを調整
  • 読みやすい。を目指す – 静的解析 • 開発環境で解析できるようにする • Grunt • CI(Jenkins)に乗せる
  • 読みやすい。を目指す – 静的解析 CIの解析では、既存のコードで 発生している警告をすべて無効化 .jshintrcファイル
  • 読みやすい。を目指す – 静的解析 既存のコードをコツコツ直して 警告を有効化していく
  • 読みやすい。を目指す – 静的解析 jshintでチェックできる スタイルガイドは明示する
  • 読みやすい。を目指す – 静的解析 jshintでチェックできる スタイルガイドは明示する
  • 読みやすい。を目指す – 静的解析 大変だったところ • エラーですぎｗ • 数え切れない • 意味が分からない警告の調査
  • 読みやすい。を目指す – 静的解析 大変だったところ • エラーですぎｗ • 数え切れない • 意味が分からない警告の調査 問題点 • 終わらない警告つぶし • ローカルで走らせるのが手間
  • 読みやすい。を目指す – 静的解析 良かったところ • 勉強になった。 • CIでよくないコードを教えてくれるよ うになった。
  • 深く考えなくても 一貫性あるコードが書ける！
  • jsHintさん細かいこと指摘しすぎ めんどくさい
  • インデントとか、 一行の文字数とか
  • 読みやすい。を目指す • 行ったこと • スタイルガイドの作成 • 静的解析 • 自動整形
  • 読みやすい。を目指す – 自動整形 • jsbeautifierを用意 • スタイルガイドに合わせて オプションを設定 • gituhub https://github.com/einars/js-beautify • grunt-jsbeautifir https://www.npmjs.org/package/grunt- jsbeautifier
  • 読みやすい。を目指す – 自動整形 ▼Online JavaScript beautifier http://jsbeautifier.org/
  • 読みやすい。を目指す – 自動整形 問題点 • 差分が多いので危険 • コメントのインデントを縦にそろえてい る個所が崩れる • 問題個所がないか一応人力で確認する必 要がある
  • 読みやすい。を目指す – 自動整形 良かったところ • 新規に書くコードはスタイルガイドに 合った整形を行ってからコミットできる ようになった。
  • 美しい！ 整形素敵！
  • 差分多すぎ
  • 怖くてマージできない
  • メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 • 変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
  • 変更しやすい。追加しやすい。 を目指す
  • 変更しやすい。追加しやすい。 を目指す 状況 • Seleniumを使ったテストはあるけど JSのUnitテストは存在しない • コードの書き方（知識）が人それぞれ
  • 変更しやすい。追加しやすい。 を目指す 行ったこと • Unitテスト • 実践的JS勉強会
  • 変更しやすい。追加しやすい。 を目指す 行ったこと • Unitテスト • 実践的JS勉強会
  • 読みやすい。を目指す – 静的解析 • Mocha + expect.js + Sinon.JS でテストを書く • Karmaで実行・レポーティング
  • 読みやすい。を目指す – 静的解析 • テストテンプレートを自動作成 するスクリプトを用意 • ボタン一つですぐテストを書き始められる
  • 変更しやすい。追加しやすい。 を目指す – テスト
  • テストで安心！
  • テスト書きやすい コードって？
  • 変更しやすいJSって？
  • 変更しやすい。追加しやすい。 を目指す 行ったこと • Unitテスト • 実践的JS勉強会
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • 第I部 スタイルガイドライン • 1~4章 • 第II部 プログラミング実践 • 5~12章 • 第III部 自動化 • 13~20章
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 たとえば
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • 他のイベントでも、ポップアップを表 示したくなったら? • テストしにくい
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 改善1 アプリケーションロジックを切り離す
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
  • • showPopupのインタフェースから必要 なプロパティがわからない • clientX, clientYしか使っていない • テストしにくい 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 改善2 イベントオブジェクトを引き回さない
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • テストに MyApplication.showPopup(10, 10); と書けて大勝利 • eventオブジェクトに触る関数は イベントハンドラだけにするのがベスト • stopPropagationとか preventDefaultとかも handleclickの中に
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 みたいな感じの輪講
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • これは守ったほうが良いという内容は スタイルガイドに記載 • スタイルガイド ＋ プログラミング実践 • スタイルガイド → 総合的なコード規約
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 悪いところ • 物足りない
  • 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 良かったところ • チームの最初の一歩にちょうど良い • JS知識の底上げ
  • 学び + 今後の話
  • 学び チームに浸透させるには • 押しつけ感をださない • できるところからこつこつじわじわと • 自動化できるところは自動化しておく • たまに煽る
  • 今後やっていきたいこと① • 引き続き • 実践的JS勉強会 • jshint警告抑制を解除していく • 無理そうなところは インラインで警告抑制する • 全体では有効にする
  • 今後やっていきたいこと① • 引き続き • 実践的JS勉強会 • jshint警告抑制を解除していく • 無理そうなところは インラインで警告抑制する • 全体では有効にする • テストとかjshintを 開発環境で実行するのを もっと簡単にしたい
  • 今後やっていきたいこと② • 整形を自動化できないか
  • 今後やっていきたいこと② • 整形を自動化できないか • grunt-complexityで複雑なコード がプッシュされたら警告
  • ありがとうございました。 2014/ 0 6 /1 4