はじめに
こんにちは！Offers を運営している株式会社 overflow の
バックエンドエンジニアの takkun7171 です。
エルデンリングをクリアして、Apex のランクを再開したところ、
初のソロダイヤを達成しますた。齢 40 過ぎのオッサンでも、やればできるんだから！！w
さて、技術ブログなんですが、今回は技術というよりも
Web エンジニアとして個人的に大事だと思ってる、ノウハウ・心構えについて
書いてみようかなと考えてます。
初心者向けというわけではないのですが、
4 月ですし、新人エンジニアの方も増えるということで
初心者の方にも読んで頂きたいです。
そこそこ分量があるので、前後編に分けて、
前編はハードスキル中心、後編はソフトスキル中心で書いてみます。
後編の記事
自分はマネージャーでも CTO でもなく一介のエンジニアでしかありませんが、
Web エンジニア歴は気付けば 15 年以上経っており、それなりに経験も積み、辛酸も舐めてきました。
自分の経験からできるだけ普遍的に大事そうなことを抽出し、列挙してみました。
参考になる部分もあれば、全く参考にならない部分、
常識過ぎて言うまでもない部分もあると思うのですが、
何かしら読んでる人のお役に立てれば幸いです。
【要件定義・仕様について】
仕様を考えるときは使う人のことをちゃんと考える
使う人に寄り添って考えて、脳内でユーザの使用してるところをシミュレーションして機能・UI を考えましょう。
機能に価値を持たせるのは使ってくれるユーザです。結局エンジニアもユーザとか社内の人達とか、人に寄り添わないと良い仕事は出来ません。
仕様を考えるときは最初にそもそもを考える
要件定義して仕様を考えるとき、依頼された内容を鵜呑みにはせず、
そもそもを考えましょう。そもそもこの機能いるの？とか
この機能じゃなくて、こういう機能じゃダメなの？とか
最初にここを考えておかないと、終盤で根底から覆されかねないです。
逆に最初の方で根底から覆せれば、相当のショートカットになります。
たたき台やmockは早めに作る
人間って解像度が上がると、色々物を言い出す生き物 です。
大きな方針が決まったら、細かい話はせずにたたき台や mock を
早めに作ったほうが良いです。
たたき台や mock を作ってから話したほうが、解像度が高いので具体的な話をしやすくなり、
結果として無駄を減らせます。
【コードを書く時に気をつけること、可読性について】
リーダブルコードに書いてあるように可読性の高いコードを書くように心がける
可読性の高いコードとは、何なのかというと
理解するのにかかる時間が短い、人間の脳に優しいコードのことです。
他人や、1 年先の全てを忘れてしまった自分が読むことを想像し、
できるだけ短い時間で理解できることを意識して書きましょう。
可読性が高ければバグを産みづらく、変更が容易いのでメンテナンス性が高くなります。
負荷に差がないなら、より優れたコードは可読性の高いコードです。
リーダブルコードのリンク
まさに普遍的な名著です。もし読んでない場合は一読を。。
変数名や関数名はわかりやすくする
名前を見ただけで、変数や関数が大体何なのかわかるような名前にしたほうがいいです。
逆に get_xx っていう関数名なのに、内部では更新処理をしてるみたいな
名前と実態が違う、みたいな状況は絶対に避けましょう。
2 回以上使うなら変数にしたほうがいいですが、
1 回しか使わないとか変数にする必要がないところは、
変数にしないほうが読みやすいです。(やや個人的な主観)
更に細かいことですが、変数の定義する箇所は
なるべく最初に使う箇所の手前がいいと思います
(そうできない場合は仕方ないです)
定義した箇所のすぐ下で使われたほうが読み手は読みやすいはずです。
ガード節を多用する
この記事が自分の言いたいことを簡潔にまとめてくれているので見てください。
if 文のネストはクソ読みづらくて、バグの温床になるので、極力やめましょうということですね。
関数書くときも、どんどん return していくほうが読みやすいです。
コメントを適切に使う
コメントは書かなくても分かる場合は書かなくていいと思います。
逆に様々な理由により、
パッと見て理解が難しいコードを書かざるを得ない場合は
必ずコメントを書きましょう。
あと関数を書くときも、この関数が何なのか
さらには使用例、主にどこでどのように使うかなどは
書いておくと読み手の理解の助けになると思います
unless !hoge みたいな書き方しない
二重否定みたいな if 文を書くと可読性下げるので止めましょう。
高校の時の古文の二重否定みたいな言い回しをする必要はないですね。
ワンライナーとか特殊な文法の書き方はしない
ワンライナーとか特殊な文法の書き方は可読性を下げるので
書きたい衝動に書かれてもなるべく書かないほうがいいです w
特に黒魔術的な文法の書き方をしたくなるときが
長いエンジニア人生の中で 1 度くらいあるかもしれませんが、止めましょう w
ただし他の人のコードを読むために、そのような文法があることを知っておく必要はあります。
関数名は名前空間が違っていても、なるべく同じ名前にしない
A モデルと B モデルで名前空間が違うから
同じ名前のメソッドにしてしまうこと、あるかもしれませんが
できるだけ止めたほうがいいと思います。
何故ならば同じ名前の hogehoge メソッドを作った場合、
検索すると A モデルと B モデルの hogehoge メソッドが
両方出てきてしまうからです。ググラビリティが低くなるとかそういう類の話です
なお変数は仕方ないと思います。
ログのoutputは日本語でいい
もし一緒に働いているメンバーに外国人の方が混ざっているなら
英語でいいと思いますが、皆無なら日本人の方が多いなら、日本語でいいと思います。
ドキュメント・コメントが日本語なのに、ログだけ英語にする必要はないと思います。
日本語の方がわかりやすいです。日本語バンザイ
リファクタリングも行うが、他人のコードのリファクタは慎重に行う
可読性向上のために、リファクタリングを行っていきたいですが、
特に他人のコードのリファクタは、往々にして思わぬ落とし穴があり
バグを産む可能性高いので慎重に行います。
書いた本人にレビューしてもらったほうが無難です。
【コードを書く時に気をつけること、可読性以外について】
N+1を避ける
rails だったら includes などで N+1 を避けましょう。
これもこの記事がわかりやすいです。
また rails に関して言えば、Vue など front 側にデータを渡す時に便利な Serializer がありますが、
親や子のデータを取得する sql 処理は N+1 の温床になりやすいため、なるべく書かない方が良いです。
DBからデータを大量に取得する場合はfind_eachを使う
DB からデータを大量に取得する場合、メモリを一気に使ってしまい、負荷が心配、、
ということがあると思います。
rails の場合、find_each を使って、少しづつメモリを展開して処理しましょう。
当たり前だけど、DBからデータ取得する際に適切にindexが張られているかチェックする
特に大量のデータを取得している場合、index が張られてないのは
問題になるので、適切に index が張られているかチェックしましょう。
当たり前ですけど、大切なことです。
while文は怖いので書かない
while 文を書く場合、break を必ず書くと思いますが、
今は break してても変更によって break しなかったら。。
などと考えると怖いです。
なので while っぽいことをしたいときでも
1000.times とか絶対に無限ループしないコードを
書いておいたほうが、精神衛生上いいと思います。
君子危うきに近寄らず。
【スクレイピング・クローラーについて】
できればAPIを使う
スクレイピングについては注意事項が多く、
さらには API と違って、サイト側の変更を能動的に検知して、
都度修正する必要があるので保守が大変です。
あくまで API で取得できない場合の最後の手段として、スクレイピングを利用します。
以下、ルールを遵守することを前提として、コード上意識してることを書きます。
サイトの変更耐性を意識し、なるべくidとかnameで取る
多少サイトが変更されても、データが取れるように
なるべく id とか name などの selector で取得します。
出来ない場合は class。
何番目の div という取り方はサイトの変更に
弱いのでなるべく避けます。
変更されること前提にエラー検知仕込む
前述の通り、
API と違い、サイトが変更されて、コードの修正が度々必要になるのは
クロールの宿命です。
絶対に取得できるはずのデータが取得できない場合は
サイトが変更されたかもしれないので、Bugsnag などでエラー検知を仕込んでおきましょう。
サイトの変更前提で、変更に素早く気付いて、素早くコード修正するのが理想です。
【障害、バグ対策について】
大きい機能をリリースする際は休日や祝日の前は避ける
金曜などにリリースして、土日に障害は起こった場合、
土日に対応せざるを得なくなります。
さらに月曜になって、障害が発覚した場合は土日を挟んだことで
被害が拡大してしまいがちです。
大きいリリースは経験上、金曜は避けて月曜とかにやったほうがいいと思います。
メール周りや決済などお金が関わってくる箇所などヤバそうな箇所は特に入念にテストする
メール周りや決済などお金が関わってくるところで障害が起こった場合、
ユーザに直接的に迷惑をかけることになり、甚大な被害になる可能性があります。
メール周りや決済などお金が関わってくるところは特に入念にテストしましょう。
他にもヤバそうな箇所があれば、そこを入念にテストしましょう。これにより、
甚大な被害を起こす可能性がグッと減るはずです。
次回予告
次回の後編はソフトスキル中心で書く予定です。
個人的に大事にしている考え方や姿勢を、頑張ってまとめますのでご期待ください。
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion