Downloaded 109 times
Recommended
![[Japanese] Style validator-html5etcstudy20151125](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fstyle-validator-html5etcstudy20151125-151130083922-lva1-app6891-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Viewers also liked
Similar to メンテナブルなJsってなんだろう
メンテナブルな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を用意•スタイルガイドに合わせてオプションを設定• gituhubhttps://github.com/einars/js-beautify• grunt-jsbeautifirhttps://www.npmjs.org/package/grunt-jsbeautifier
- 84.読みやすい。を目指す– 自動整形▼Online JavaScriptbeautifierhttp://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 どういう方針で進めていくか