Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

30,156 views

Published on

Published in: Software
  • Be the first to comment

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

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

×