はじめに
昨今スクールも増え、エンジニアも増えてきたなと思います(非常に良いことだと思う)。
ただスクール後のエンジニアの方のレビューをさせていただくと、
技術力以外の部分で「スクールで教えといてあげてよ」みたいなことが多かったので、
未経験・初心者のエンジニアの方が実務で作業する前に意識しておいたほうがいいことをザッとまとめました。
個人的な意見なので、「うちのチームにはこの項目要らない」などあるかもしれません。
また網羅はできてないと思うので順次足していくかと思います。これも入れたほうがなどあればコメントお待ちしています。
また
- チーム開発したことのない人
- 我流コード書いてる人
にも参考になればと。
内容
インデント
普通に考えたら揃えるだろとか思ってしまうのですが、なんで？ってくらいインデントがテキトーな人が多い気します。
インデントがズレてると読みにくいのと、Hamlなどインデントによって意味が変わる言語もあるので普段からインデントのズレは気にしましょう。
書き方の統一
書くコードに統一性がないと自分も他のメンバーも読みにくいです。
文化的なもので正解はないのでそれぞれの企業の文化に合わせて統一性のあるコードを書きましょう。
CSSを例に出すと、
- カラーコードは大文字か小文字か
- クラス名はハイフンかCamelかSnakeか
- CSSを書く順番
など。他にも下記のような半角スペースの取り方も。
users.map{ |user| user.name }
users.map{|user| user.name}
users.map { |user| user.name }
上述したように正解はないのでとにかく統一しましょう。先輩方の既存のコードがある場合はそれを見て合わせる、自分1人で書く場合も自分の中でルール付けしましょう。
DRYか
最初から綺麗なコードを書くのは無理(私もまだまだ書けてない。。)ですが、
常にいいコードを書こうとはしてください。
明らかに同じコードなのに何度も書くのはやめましょう。
= User.find(params[:id]).name
= User.find(params[:id]).address
↓
- user = User.find(params[:id])
= user.name
= user.address
テキトーなコードで恐縮ですが、せめて上記のように1ファイル内でDRYじゃないかどうかは誰でも気にできるので気にしましょう。
(サンプルはDRY以前にSQL的にもよくないですがサンプルなので気にせずで)
DRYを指摘されるなら、
ここはヘルパーメソッド・モデルメソッドを使おう、モジュールでまとめよう
みたいな指摘をされるくらいがよいと思います。
シンプルか、わかりやすいか
上のDRYに似ているのですが、個人的にはコードは書かなければ書かないほどよいと思っています(文化によるかも)。
そもそもバグはコードを書くから生まれるので、コードが少なければ少ないほどバグは生まれにくいためです。
user_names = users.map{ |user| user.name }
user_names = []
users.each do |user|
user_names.push(user.name)
end
上記は一例ですが、同じ挙動を作るにも複数の実現方法があります。
よりシンプルでわかりやすいコードを選択するためにも、
- 複数の実装方法を考える
- それぞれのメリット・デメリットを考える
- 一番いい実装方法で実装
みたいにするとよいと思います。
補足ですが、私の場合そもそもコード書いて開発しなくてもスプレッドシートで対応できるなど代替案があり
そちらのほうが良さそうであればそちらを提案します。
わかいやすい、正しい英語を使う
英語はそもそもある程度できたほうがエンジニアとして有利なのでやったほうがいいです。
日本語だとどうしても情報が少ないので基本的に英語でググり英語の情報を読むことが多いですし。
プログラムを書くときにわかりにくかったり、間違ったりした英文法を使っていると、メンバーが意図を解釈できず、理解するのに余計なコストが生まれるので
わかりやすい、正しい英語を使いましょう。
メソッド名の付け方などは有名な『リーダブルコード』を読むのがいいと思います。
コミットの粒度は細く
明確なルールを作りにくいので難しいのですが、コミットはある程度細かい単位でやりましょう。
何かあったときに戻りやすいのと、レビューもやりやすいです。また、体調を崩して作業途中で引き継ぐ際にも引き継ぎがしやすくなります。
例えばとある機能を作るときには下記のように分けるなどです(大きい機能であればもっと細くする)。
- バックエンド
- フロントエンド
- 自動テスト
1ブランチ1作業
1つのブランチには基本的に1つの作業しか含まないようにしましょう。
AとBの作業があって同じブランチで両方作業した場合、どちらかの機能開発で詰まると両作業ともリリースできなくなってしまいます。
AとBの作業でブランチを分けておけば仮にAの作業が詰まってもB作業のリリースには影響しなくなります。
レビュー依頼はこまめに
これはエンジニアだけでなく仕事をする上で共通かと思います。
一度にすべてのコードを書いてレビューを依頼してそもそもの実装の方針から直しが必要な場合かなりの時間をロスすることになります。
対策として、
「こんな感じで実装しようと思うのですがどうですか？」
「まずは裏側だけコード書きました」
のようにステップごとにレビューを依頼すると効率的かと思います。
質問はやりたいことから順に伝える
「こういうコードを書いてるんですけどうまく動かないので教えてほしいです」
のような質問が時々あるのですが、回答者もゴールがわかってないと答えを出せません。
なので、
「これこれこういうことをやりたいです(ワイヤー、デザイン、ブラウザを見せながら)
ただここの部分がうまく動かずこのようなエラーが出てしまいます。
どうやって解消したらよいですか？」
みたいな感じで聞いてもらえると回答者も答えやすいと思います。
加えて現状のURLや、どんなデータや状況でエラーが起こっているのかも伝えられるとなおよしです。
ヘルプは早めに
スプリントを1週間単位で進めている場合、スプリント最終日にヘルプを求められても先輩も別作業があり教えることができない場合もあります。
作業が納期までに間に合わなそうであればなるべく早くヘルプを求めてもらえると先輩や上司も助けやすいかと思います。
おまけ(できたらなおよし)
メソッドやモジュールがあるか気にする
何度も使うような処理はすでに先人たちがモジュール化やメソッドを作ってくれてる可能性が高いので、
先人に質問するなり自分で探すなりするとよいかと思います。
意図を想像する
これは実装はもちろん設計やデザイン含めてのことです。
「なぜこのボタンは赤色なのか」
「なぜソート順はIDで降順なのか」
「なぜこのコードはここに書いているのか」
「なぜ変数名はこれなのか」
など作者の意図を汲み取るとより綺麗なコードが書けるようになったり、設計者やデザイナーとのやり取りもスムーズになったりします。
また「こっちのほうがいいのではないか」のような議論を自分からできるようになります。
作業の前提条件を確認する
その作業は何のためにやるのか、いつまでにやらないとまずいのか、など作業の背景や条件を事前に把握しておきましょう。
例えば「CSVダウンロードできるデータを特定の条件で並び替えられるようにする」という作業があったとき、ダウンロードしたCSVファイル側で並び替えたほうが効率がいいという場合もあります。
そんなときに何も確認せずただ言われたことをやっているだけだと時間を無駄に使ってしまいますが、
エンジニアからCSVで作業したほうが早いのでそちらでお願いしますと言えると全体効率が上がります。
また、「打刻システムと集計システムを作る」ようなタスクがあり、納期に間に合わなさそうな場合、
両機能を言われた通りの納期で作ろうとすると間に合わないか、いわゆるデスマになります。
なので「間に合わせるのであれば、ここの機能やギミックは後回しにさせてほしい」というようなやり取りや、
「打刻システムだけ納期に間に合わせて事前にリリースして打刻のデータを作れるようにする。集計システムはその月が終わるまで使わないだろうからそれまでに作業する」のような段取りを提案できると誰も苦しまずに作業を進めることができます。
まとめ
実務として、さらにチームとして開発する場合、ただコードを書いて動けばいいというわけではないです。
コードの品質の向上、開発の進め方など技術以外の部分も意識できているとより即戦力になるかと思うので試しに気にしてみてください。
もちろんここに書いてあることが正解ではなく、企業の文化によって異なることもあるとは思うので
その場合は文化に合わせるなり、より効率的な方法があれば文化を変えるなりしていくのがいいと思います。