O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

30.311 visualizações

Publicada em

Publicada em: Software
  • Seja o primeiro a comentar

メンテナブルな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

×