Downloaded 109 times
More Related Content
![[Japanese] Style validator-html5etcstudy20151125](https://cdn.slidesharecdn.com/ss_thumbnails/style-validator-html5etcstudy20151125-151130083922-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
メンテナブルなJsってなんだろう
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. 経緯 サイボウズ Office • ここ数年JSでの開発が増えている •ライブラリのぞいて2万5千行くらい
- 12.
- 13.
- 14.
- 15. 経緯 JSのメンテナンスコストが 日々増大していっている感じがする • スタイルがファイルによって異なる • コードを探すのが大変 •影響範囲が予測できない • JSのUnitテストがない • コード変更が億劫に
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 •変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
- 25. メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 •変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
- 26.
- 27. 読みやすい。を目指す 状況 • スタイルガイドがゆるい • その時代時代のスタイルで書かれている •PGの数だけ存在しているコーディング スタイル！
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35. 読みやすい。を目指す – スタイルガイドの作成 おれおれスタイルガイドを作ってから チームに広める？ NG • 本当に良いスタイルなのか分からない •大変 • おれが嫌われる・反感買う • チームワーク崩壊の恐れ
- 36.
- 37.
- 38. 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる •スタイルガイドの存在を脳裏に・・ • そういえばスタイルガイド決めたなー • 自分たちで決めたルールだから守らねば！
- 39. 読みやすい。を目指す – スタイルガイドの作成 みんなで一緒に スタイルガイドを作る？ • 本当にプロジェクトに合ったスタイルを 見つけられる •スタイルガイドの存在を脳裏に・・ • そういえばスタイルガイド決めたなー • 自分たちで決めたルールだから守らねば！ • おれが悪者にならない
- 40.
- 41. 読みやすい。を目指す – スタイルガイドの作成 作り方 • 各スタイルについて全員で議論 •自分たちのスタイルガイドに記載する べき内容なのか。 • どう記載するのがベストか。
- 42. 読みやすい。を目指す – スタイルガイドの作成 作り方 • 各スタイルについて全員で議論 •自分たちのスタイルガイドに記載する べき内容なのか。 • どう記載するのがベストか。 • 決まったスタイルは 即スタイルガイドに記載！
- 43.
- 44. 読みやすい。を目指す – スタイルガイドの作成 • 第I部スタイルガイドライン • 第II部 プログラミング実践 • 第III部 自動化 • 付録 A JavaScriptスタイルガイド • 付録 B JavaScriptツール
- 45. 読みやすい。を目指す – スタイルガイドの作成 具体的な進め方 • 毎週1時間の輪講を行う •一回で1章くらい進む • 1~4章なので4時間。約一ヶ月で完成する
- 46. 読みやすい。を目指す – スタイルガイドの作成 • 第I部スタイルガイドライン • 1~4章 • 第II部 プログラミング実践 • 5~12章 • 第III部 自動化 • 13~20章
- 47.
- 48. 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている •小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC）
- 49. 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている •小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC） • 一般論として、使用しているコア言語 に従った命名規則を常に使うべき
- 50. 読みやすい。を目指す – スタイルガイドの作成 • ECMAScriptはキャメルケースで書か れている •小文字で始まり、その後に頭文字が大文 字で単語が続く（LCC） • 一般論として、使用しているコア言語 に従った命名規則を常に使うべき • Google SproutCore Dojoもほとん どの状況でキャメルケース
- 51. 読みやすい。を目指す – スタイルガイドの作成 • 変数名は名詞で始まるようにすべき •名詞で始めることで変数を区別するのに 役立つ
- 52.
- 53.
- 54.
- 55. 読みやすい。を目指す – スタイルガイドの作成 • 関数の先頭は動詞にすべき •よく使われる動詞 動詞 意味 can ブーリアンを返す has ブーリアンを返す is ブーリアンを返す get 非ブーリアンを返す set 値を保存するために使 われる
- 56.
- 57. 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき •変数名からデータ型が分かるとよい • count,length,sizeは数値 • name,title,messageは文字列 • i,j,kはループの中で使用される
- 58. 読みやすい。を目指す – スタイルガイドの作成 • 可能な限り変数名は短くすべき •変数名からデータ型が分かるとよい • count,length,sizeは数値 • name,title,messageは文字列 • i,j,kはループの中で使用される • 無意味な名前は避けるべき • foo,bar,temp
- 59.
- 60.
- 61.
- 62. 読みやすい。を目指す – スタイルガイドの作成 大変だったところ • 好みの違いによる論争議論 •インデントの好み • function(){ vs function() { vs function () { • “ vs ‘ • 議論の基準を設けた • 既存コードの兼ね合い • メリット・デメリット • デグレリスク • それでも決まらないときは多数決
- 63. 読みやすい。を目指す – スタイルガイドの作成 問題点 • メンテナブルJavaScriptⅠ部の スタイルガイドラインの章だけでは網羅 できない •足りないスタイルガイドを列挙して議論する
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70. 読みやすい。を目指す – 静的解析 • JSHintを導入 •スタイルガイドに合わせてJSHintの オプションを調整
- 71. 読みやすい。を目指す – 静的解析 • 開発環境で解析できるようにする •Grunt • CI(Jenkins)に乗せる
- 72.
- 73.
- 74.
- 75.
- 76. 読みやすい。を目指す – 静的解析 大変だったところ • エラーですぎｗ •数え切れない • 意味が分からない警告の調査
- 77. 読みやすい。を目指す – 静的解析 大変だったところ • エラーですぎｗ •数え切れない • 意味が分からない警告の調査 問題点 • 終わらない警告つぶし • ローカルで走らせるのが手間
- 78. 読みやすい。を目指す – 静的解析 良かったところ • 勉強になった。 •CIでよくないコードを教えてくれるよ うになった。
- 79.
- 80.
- 81.
- 82. 読みやすい。を目指す • 行ったこと • スタイルガイドの作成 •静的解析 • 自動整形
- 83. 読みやすい。を目指す – 自動整形 • jsbeautifierを用意 •スタイルガイドに合わせて オプションを設定 • gituhub https://github.com/einars/js-beautify • grunt-jsbeautifir https://www.npmjs.org/package/grunt- jsbeautifier
- 84. 読みやすい。を目指す – 自動整形 ▼Online JavaScriptbeautifier http://jsbeautifier.org/
- 85. 読みやすい。を目指す – 自動整形 問題点 • 差分が多いので危険 •コメントのインデントを縦にそろえてい る個所が崩れる • 問題個所がないか一応人力で確認する必 要がある
- 86.
- 87.
- 88.
- 89.
- 90. メンテナブルとは？ 読みやすい。変更しやすい。追加しやすい。 • 読みやすい • コードのスタイルが統一されている。 整っている。 •変更しやすい。追加しやすい。 • テスト • ドキュメントがちゃんとしている （賛否両論）
- 91.
- 92. 変更しやすい。追加しやすい。 を目指す 状況 • Seleniumを使ったテストはあるけど JSのUnitテストは存在しない •コードの書き方（知識）が人それぞれ
- 93.
- 94.
- 95. 読みやすい。を目指す – 静的解析 • Mocha+ expect.js + Sinon.JS でテストを書く • Karmaで実行・レポーティング
- 96. 読みやすい。を目指す – 静的解析 • テストテンプレートを自動作成 するスクリプトを用意 •ボタン一つですぐテストを書き始められる
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 •第I部 スタイルガイドライン • 1~4章 • 第II部 プログラミング実践 • 5~12章 • 第III部 自動化 • 13~20章
- 104.
- 105.
- 106. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 •他のイベントでも、ポップアップを表 示したくなったら? • テストしにくい
- 107.
- 108.
- 109. • showPopupのインタフェースから必要 なプロパティがわからない • clientX,clientYしか使っていない • テストしにくい 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会
- 110.
- 111.
- 112. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 •テストに MyApplication.showPopup(10, 10); と書けて大勝利 • eventオブジェクトに触る関数は イベントハンドラだけにするのがベスト • stopPropagationとか preventDefaultとかも handleclickの中に
- 113.
- 114. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 •これは守ったほうが良いという内容は スタイルガイドに記載 • スタイルガイド ＋ プログラミング実践 • スタイルガイド → 総合的なコード規約
- 115.
- 116. 変更しやすい。追加しやすい。 を目指す – 実践的JS勉強会 良かったところ •チームの最初の一歩にちょうど良い • JS知識の底上げ
- 117.
- 118. 学び チームに浸透させるには • 押しつけ感をださない • できるところからこつこつじわじわと •自動化できるところは自動化しておく • たまに煽る
- 119. 今後やっていきたいこと① • 引き続き • 実践的JS勉強会 •jshint警告抑制を解除していく • 無理そうなところは インラインで警告抑制する • 全体では有効にする
- 120. 今後やっていきたいこと① • 引き続き • 実践的JS勉強会 •jshint警告抑制を解除していく • 無理そうなところは インラインで警告抑制する • 全体では有効にする • テストとかjshintを 開発環境で実行するのを もっと簡単にしたい
- 121.
- 122.
- 123.
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 どういう方針で進めていくか