メンテナブルなJsってなんだろう
- 1. メンテナブルなJSってなんだろう 松元 @datomotu 2014/ 0 6 /1 4
- 8. 経緯
- 11. 経緯 サイボウズ Office • ここ数年JSでの開発が増えている • ライブラリのぞいて2万5千行くらい
- 15. 経緯 JSのメンテナンスコストが 日々増大していっている感じがする • スタイルがファイルによって異なる • コードを探すのが大変 • 影響範囲が予測できない • JSのUnitテストがない • コード変更が億劫に
- 16. 経緯 要はメンテナブルじゃない！
- 20. メンテナブルとは？
- 24. メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 • 変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
- 25. メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 • 変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
- 26. 読みやすい。を目指す
- 27. 読みやすい。を目指す 状況 • スタイルガイドがゆるい • その時代時代のスタイルで書かれている • PGの数だけ存在しているコーディング スタイル！
- 35. 読みやすい。を目指す – スタイルガイドの作成 おれおれスタイルガイドを作ってから チームに広める？ NG • 本当に良いスタイルなのか分からない • 大変 • おれが嫌われる・反感買う • チームワーク崩壊の恐れ
- 38. 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる • スタイルガイドの存在を脳裏に・・ • そういえばスタイルガイド決めたなー • 自分たちで決めたルールだから守らねば！
- 39. 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる • スタイルガイドの存在を脳裏に・・ • そういえばスタイルガイド決めたなー • 自分たちで決めたルールだから守らねば！ • おれが悪者にならない
- 41. 読みやすい。を目指す – スタイルガイドの作成 作り方 • 各スタイルについて全員で議論 • 自分たちのスタイルガイドに記載する べき内容なのか。 • どう記載するのがベストか。
- 42. 読みやすい。を目指す – スタイルガイドの作成 作り方 • 各スタイルについて全員で議論 • 自分たちのスタイルガイドに記載する べき内容なのか。 • どう記載するのがベストか。 • 決まったスタイルは 即スタイルガイドに記載！
- 44. 読みやすい。を目指す – スタイルガイドの作成 • 第I部 スタイルガイドライン • 第II部 プログラミング実践 • 第III部 自動化 • 付録 A JavaScriptスタイルガイド • 付録 B JavaScriptツール
- 45. 読みやすい。を目指す – スタイルガイドの作成 具体的な進め方 • 毎週1時間の輪講を行う • 一回で1章くらい進む • 1~4章なので4時間。約一ヶ月で完成する
- 46. 読みやすい。を目指す – スタイルガイドの作成 • 第I部 スタイルガイドライン • 1~4章 • 第II部 プログラミング実践 • 5~12章 • 第III部 自動化 • 13~20章
- 48. 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている • 小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC）
- 49. 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている • 小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC） • 一般論として、使用しているコア言語 に従った命名規則を常に使うべき
- 50. 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている • 小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC） • 一般論として、使用しているコア言語 に従った命名規則を常に使うべき • Google SproutCore Dojoもほとん どの状況でキャメルケース
- 51. 読みやすい。を目指す – スタイルガイドの作成 • 変数名は名詞で始まるようにすべき • 名詞で始めることで変数を区別するのに 役立つ
- 55. 読みやすい。を目指す – スタイルガイドの作成 • 関数の先頭は動詞にすべき • よく使われる動詞 動詞 意味 can ブーリアンを返す has ブーリアンを返す is ブーリアンを返す get 非ブーリアンを返す set 値を保存するために使 われる
- 57. 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき • 変数名からデータ型が分かるとよい • count,length,sizeは数値 • name,title,messageは文字列 • i,j,kはループの中で使用される
- 58. 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき • 変数名からデータ型が分かるとよい • count,length,sizeは数値 • name,title,messageは文字列 • i,j,kはループの中で使用される • 無意味な名前は避けるべき • foo,bar,temp
- 62. 読みやすい。を目指す – スタイルガイドの作成 大変だったところ • 好みの違いによる論争議論 • インデントの好み • function(){ vs function() { vs function () { • “ vs ‘ • 議論の基準を設けた • 既存コードの兼ね合い • メリット・デメリット • デグレリスク • それでも決まらないときは多数決
- 63. 読みやすい。を目指す – スタイルガイドの作成 問題点 • メンテナブルJavaScriptⅠ部の スタイルガイドラインの章だけでは網羅 できない • 足りないスタイルガイドを列挙して議論する
- 64. 読みやすい。を目指す – スタイルガイドの作成 よかったところ • スタイルで悩む時間がなくなる • レビューしやすい
- 67. 何が正解なのか忘れる。
- 70. 読みやすい。を目指す – 静的解析 • JSHintを導入 • スタイルガイドに合わせてJSHintの オプションを調整
- 71. 読みやすい。を目指す – 静的解析 • 開発環境で解析できるようにする • Grunt • CI(Jenkins)に乗せる
- 76. 読みやすい。を目指す – 静的解析 大変だったところ • エラーですぎｗ • 数え切れない • 意味が分からない警告の調査
- 77. 読みやすい。を目指す – 静的解析 大変だったところ • エラーですぎｗ • 数え切れない • 意味が分からない警告の調査 問題点 • 終わらない警告つぶし • ローカルで走らせるのが手間
- 78. 読みやすい。を目指す – 静的解析 良かったところ • 勉強になった。 • CIでよくないコードを教えてくれるよ うになった。
- 82. 読みやすい。を目指す • 行ったこと • スタイルガイドの作成 • 静的解析 • 自動整形
- 83. 読みやすい。を目指す – 自動整形 • jsbeautifierを用意 • スタイルガイドに合わせて オプションを設定 • gituhub https://github.com/einars/js-beautify • grunt-jsbeautifir https://www.npmjs.org/package/grunt- jsbeautifier
- 84. 読みやすい。を目指す – 自動整形 ▼Online JavaScript beautifier http://jsbeautifier.org/
- 85. 読みやすい。を目指す – 自動整形 問題点 • 差分が多いので危険 • コメントのインデントを縦にそろえてい る個所が崩れる • 問題個所がないか一応人力で確認する必 要がある
- 87. 美しい！ 整形素敵！
- 88. 差分多すぎ
- 89. 怖くてマージできない
- 90. メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 • 変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
- 92. 変更しやすい。追加しやすい。 を目指す 状況 • Seleniumを使ったテストはあるけど JSのUnitテストは存在しない • コードの書き方（知識）が人それぞれ
- 93. 変更しやすい。追加しやすい。 を目指す 行ったこと • Unitテスト • 実践的JS勉強会
- 94. 変更しやすい。追加しやすい。 を目指す 行ったこと • Unitテスト • 実践的JS勉強会
- 95. 読みやすい。を目指す – 静的解析 • Mocha + expect.js + Sinon.JS でテストを書く • Karmaで実行・レポーティング
- 96. 読みやすい。を目指す – 静的解析 • テストテンプレートを自動作成 するスクリプトを用意 • ボタン一つですぐテストを書き始められる
- 98. テストで安心！
- 99. テスト書きやすい コードって？
- 100. 変更しやすいJSって？
- 101. 変更しやすい。追加しやすい。 を目指す 行ったこと • Unitテスト • 実践的JS勉強会
- 103. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • 第I部 スタイルガイドライン • 1~4章 • 第II部 プログラミング実践 • 5~12章 • 第III部 自動化 • 13~20章
- 106. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • 他のイベントでも、ポップアップを表 示したくなったら? • テストしにくい
- 109. • showPopupのインタフェースから必要 なプロパティがわからない • clientX, clientYしか使っていない • テストしにくい 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
- 112. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • テストに MyApplication.showPopup(10, 10); と書けて大勝利 • eventオブジェクトに触る関数は イベントハンドラだけにするのがベスト • stopPropagationとか preventDefaultとかも handleclickの中に
- 114. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 • これは守ったほうが良いという内容は スタイルガイドに記載 • スタイルガイド ＋ プログラミング実践 • スタイルガイド → 総合的なコード規約
- 115. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 悪いところ • 物足りない
- 116. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 良かったところ • チームの最初の一歩にちょうど良い • JS知識の底上げ
- 117. 学び + 今後の話
- 118. 学び チームに浸透させるには • 押しつけ感をださない • できるところからこつこつじわじわと • 自動化できるところは自動化しておく • たまに煽る
- 119. 今後やっていきたいこと① • 引き続き • 実践的JS勉強会 • jshint警告抑制を解除していく • 無理そうなところは インラインで警告抑制する • 全体では有効にする
- 120. 今後やっていきたいこと① • 引き続き • 実践的JS勉強会 • jshint警告抑制を解除していく • 無理そうなところは インラインで警告抑制する • 全体では有効にする • テストとかjshintを 開発環境で実行するのを もっと簡単にしたい
- 123. ありがとうございました。 2014/ 0 6 /1 4
Editor's Notes
- #4: 世界中のチームワークを良くすること Mission 世界中のチームワーク向上に貢献する Vision 世界で一番使われるグループウェアメーカーになる CoreValue 顧客体験のすべてにおいて「Fast&Easy+Entertain」を
- #5: 新卒サイトのキャプチャ 世界中のチームワークを良くすること Mission 世界中のチームワーク向上に貢献する Vision 世界で一番使われるグループウェアメーカーになる CoreValue 顧客体験のすべてにおいて「Fast&Easy+Entertain」を
- #6: グループウェア ホームページのキャプチャ
- #15: コードを書くときにこれが原因でどんなやりにくさがあるか 探すのが大変とか。影響範囲がわからない。JSのUnitテストはない 周りに合わせてスタイルを整える
- #16: コードを書くときにこれが原因でどんなやりにくさがあるか 探すのが大変とか。影響範囲がわからない。JSのUnitテストはない 周りに合わせてスタイルを整える
- #64: 既存のコードを確認 多数決
- #71: 問題を強調（覚えきれねぇ） CIにのせる
- #73: えらーでまくる
- #75: どういう方針で進めていくか