search

wasiotakahiro / funappap

0 stars 1 forks source link

DIVE INTO CODE 標準チェックをすべてクリアしよう #3

Open norotime opened 6 years ago

norotime commented 6 years ago
主な対象分野 チェックリスト 理由 参考URL
コントローラ アソシエーションメソッドを使いましょう。 よくない例として、アソシエーションメソッドを使わずに何行もコツコツ書くということが挙げられます。悪い例：blog = Blog.new(blog_params)blog.user_id = current_user.idblog.saveこれをアソシエーションメソッド（定義されていれば）を使い改善するとこうなります。改善例：blog = current_user.blog.build(blog_params)blog.save既に存在する便利なメソッドを使い、コードをシンプルにしていく習慣は、ずっと持ち続けてください。 https://railsguides.jp/association_basics.html#has-many%E3%81%A7%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%82%8B%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89-collection-build-attributes
コントローラ redirect_toの引数オプションを使いましょう。   https://api.rubyonrails.org/classes/ActionController/Redirecting.html#method-i-redirect_to
コントローラ createメソッドの仕様を理解して使おう。 createメソッドは、newとsaveに酷似しています。createで良い部分はcreateを使いましょう。 https://api.rubyonrails.org/classes/ActiveRecord/Persistence/ClassMethods.html#method-i-create
コントローラ メソッド名等は文字列表記ではなく、シンボル表記を使いましょう。 シンボルを使うメリットは3つです。1. 新しく文字列を生成しない分やや効率がよく、比較も高速。2. 文字の意味がはっきりするのでコードが読みやすくなる3. immutable なので内容を書き換えられる心配がない大抵のメソッドはシンボルの代わりに文字列を引数として渡すこともできるようになっています。 https://docs.ruby-lang.org/ja/latest/class/Symbol.html
コントローラ ビジネスロジックは、原則的にモデルのメソッドとして実装しよう。 ビジネスロジックとは、データ操作のアルゴリズムのことです。例えば、- データの検索- データの並び替え- データの加工などです。これらは、コントローラがやるべきことではなく、そのデータを担当するモデルが専業でやるべきことです。複数のコントローラからその専業のモデルに処理が流れることを想定すれば、コントローラに書いてしまうと、冗長化してしまうことがわかります。イメージがつき難い場合は、「銀行の処理の流れ、分業体制」を想像して、考えてみましょう。 http://ossforum.jp/node/932 https://tech.nikkeibp.co.jp/it/article/COLUMN/20080610/307218/
コントローラ コントローラには、原則的に CRUD 以外のアクションはつくらないようにしよう。 コントローラは、ユーザが行う画面上の操作（CRUD処理がほとんど）をモデル等に指示を出してさせて、ビューに処理を受け渡していく役割を担います。そのため、コントローラには、CRUD以外のアクションは書かないことが重要です。ビジネスロジックはモデルに記述し、コントローラにはできる限りオリジナルのアクションは定義しないように心がけましょう。もちろん例外はあるため、困ったらDICメンターに相談してください。 https://www.slideshare.net/tkawa1/learning-rest-from-rails-style
コントローラ/モデル コントローラやモデルの共通の処理は、それぞれのconcernを使いましょう。 複数のコントローラに同一のメソッドを複数記述している場合に検討しましょう。 https://api.rubyonrails.org/classes/ActiveSupport/Concern.html
コントローラ/モデル returnを書かなくて良い場面では、書かないようにしよう。 Rubyメソッドの戻り値は return に渡した値です。return が呼び出されなかった場合は、 body の最後の式の値を返します。 body の最後の式が値を返さない式の場合は nil を返します。 https://docs.ruby-lang.org/ja/latest/doc/spec=2fcontrol.html#return
その他 イシューをコミットメッセージでクローズしよう。   https://help.github.com/articles/closing-issues-using-keywords/
テーブル 非NULL制約を原則は全てのカラムにつけよう。 NULLは特殊な値で空白とも異なります。NULLと空白が混在しているとSQL文が冗長になったり、検索効率が落ちることがあります。 https://www.postgresql.jp/document/10/html/ddl-constraints.html#id-1.5.4.5.6
バージョン管理 コミットメッセージには、何のための作業をしたのかを正確かつ具体的に記述しよう。 チーム開発をはじめるとGitHubリポジトリにプッシュされたコミットとそのメッセージを他のエンジニアが読み、それを参考にコードレビューをすることになります。適当に書いていると迷惑に思われますし、自分も逆の立場でそう思うことになります。 https://gist.github.com/mono0926/e6ffd032c384ee4c1cef5a2aa4f778d7
ビュー 行間の調整は br ではなくCSSで実装しよう。    
ビュー 特定のアクションからの処理を分岐させたい場合は action_nameを使おう。 どの（コントローラの）アクションからの処理なのかは、既に用意されたメソッドがあります。 https://api.rubyonrails.org/classes/AbstractController/Base.html#method-i-action_name
モデル 色々な時刻メソッドがあることを理解して使おう。 日付の文字加工をするためのメソッドは充実しています。車輪の再発明はやめましょう。 https://api.rubyonrails.org/classes/Date.html
モデル データ集計や並び替え用のActiveRecordメソッドを使おう。 日付の文字加工をするためのメソッドは充実しています。車輪の再発明は辞めましょう。 https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html
モデル データベースと関係ないモデルを作ることができるので、必要があれば使おう。 本来、モデルとは、データベースのテーブルと等しい存在という意味ではなく、アプリケーション内で使うリソースがモデルになります。そのため、テーブルが存在しなくてもモデルは作って良いですし、データベースに保存する必要のないモデルは、ActiveRecordを継承する必要はないのです。ただ、多くの場合データベースに保存することになるため、Railsではデフォルトでモデル＝テーブルかのようにActiveRecordを継承するように設計されています。 https://railsguides.jp/active_model_basics.html#model%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB
ルーティング rootメソッドを必ず使おう。 メソッドがあるのにベタ書きするのは、機械があるのに手動で行うに等しいことです。 https://api.rubyonrails.org/classes/ActionDispatch/Routing/Mapper/Resources.html#method-i-root
ルーティング rootは最上段に定義しよう。 ルーティングは上から順番にチェックされ、該当した時点で処理が次に流れます。最もアクセス数が多いURLを最初にルーティングチェックすることは、最も効率が良い処理になります。  
ルーティング resourceやresourcesをできるだけ使ってルーティング設定しよう。 URL設計のRESTfulを実現するための最もシンプルな形は、Railsのresourcesやresourceだけを使ったURLです。（例外はあります） https://api.rubyonrails.org/classes/ActionDispatch/Routing/Mapper/Resources.html https://www.slideshare.net/tkawa1/learning-rest-from-rails-style
ルーティング ネストしたURLを定義する際はshallowを使おう。 使用例として、検索機能用のURL、ブログに紐づくコメントなどのネストしたリソースのURLが挙げられます。 https://railsguides.jp/routing.html#%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B
ルーティング/コントローラ %i記法を活用しよう。 無理に使う必要はありませんが、コード量の削減やコードの追加をする際に楽です。 https://docs.ruby-lang.org/ja/latest/doc/spec=2fliteral.html#percent
全般 ハッシュロケット記法は使わずにシンボル表記にしよう。 ハッシュロケット記法（ => ）Ruby1.8時代の古い書き方です。シンボル表記の方が内部処理が効率化できるため、シンボル表記に統一しましょう。  
全般 生成しただけで何も使わないファイルは削除しよう。 使わないファイルを置いておくと、「何か書いているかもしれない」と未来の自分やチームメンバーが確認をする手間につながります。一回一回は小さいですが、何回も続くとストレスになります。  
全般 Rubyスタイルガイドを遵守しよう 「レイアウト」と「構文」は必須です。これができていないとまともにコードを書こうとしている人と思われません。 https://github.com/fortissimo1997/ruby-style-guide/blob/japanese/README.ja.md
全般 Google HTML/CSS スタイルガイドを遵守しよう これができていないとまともにコードを書こうとしている人と思われません。他にも様々な文献がインターネット上にあります。できるところから、はじめましょう。 https://google.github.io/styleguide/htmlcssguide.html
全般 JavaScriptスタイルガイドを遵守しよう これができていないとまともにコードを書こうとしている人と思われません。他にも様々な文献がインターネット上にあります。できるところから、はじめましょう。 https://developer.mozilla.org/ja/docs/Mozilla/JavaScript_style_guide
norotime commented 6 years ago

@wasiotakahiro

DIVE INTO CODE 卒業生は Webエンジニアのプロのスタートラインに立てる人です。

限られた期間に与えられた課題を突破することは重要ですが、現場ではコードの可読性や品質も重視されます。 また、採用選考時にテストコードの実装ができることを必須としている会社も多く存在します。 ここに記載されているリストは、現場配属される前にすべてできていて欲しいことやもっていただきたい一般的な考え方です。 卒業＝新たなスタートです。ぜひすべてクリアして羽ばたいていきましょう。