前回「入社2か月間で駆け出しエンジニアがつまずいた15のポイント」 tech.libinc.co.jp
という記事を書かせて頂いてから早いもので入社6ヶ月目になりました。 たくさんの方に読んで頂けたようでありがとうございます。 未経験 ~ 駆け出しの間は特に不安だったり想像のつかないことも多いかと思うので少しでも実際に働いて見た気づきなどをシェアできたらと思います！ 今回は前回に続き入社6ヶ月目でつまずいたポイントを4つ書かせていただきます！
とりあえず公式ドキュメントを参照する癖をつける
公式ドキュメントって読みづらいのでついついQiitaとかまとめブログに目がいきがちです。でも結局は公式のドキュメント見て調べた方が正確で早く作業も終わるのではないかと最近思います。 なんでその実装にしたのですか？と聞かれたときに、このブログに書いてあったので！では不安になってしまいます。（メソッドの挙動とか動かしながら手元で確認できるものであれば良さそうですが）
例えばメールアドレスのドメインの長さは何文字までOKなんだっけ？と調べたい時にはRFCを見ると公式の仕様を確認できます。RFCは基本英語ですが有名なプロトコルなどについてはボランティアで日本語翻訳されているものもあるみたいです。
（RFCはインターネット技術の標準化などを行うIETF（Internet Engineering Task Force）が発行している、技術仕様などについての文書群。）
「メールアドレス 長さ 仕様」などで調べるとメールの仕様はRFC2821に定義されているようなので確認すると、4.5.3.1 Size limits and minimumsで使用できる文字数が明確に定義されていました。こちらで日本語訳してくれています。
これでメールの最大の長さは
4.5.3.1.2. ドメイン ドメインの名前または数値の最大長は 255 オクテットである。
と自信を持って言えるようになりました! 英語を恐れず公式文書を読む気持ちもググり力の１つとして大切なのではと感じます！
コードを書くばかりがエンジニアではない
エンジニアとして働くまでは、業務の8~9割くらいはコードを書いているものかと思っていました。 実際に働いてみると思いのほかコードを書く以外の仕事もたくさんありました。 現在自分が所属している部署では、数日から長くても1、2週間くらいのスパンで機能を開発していくのですがその中には、
エンジニア視点でコメントしながら仕様書を作る --> 機能開発をどのように進めるか設計する --> コードを書く --> テストしたり関係者各所と最終確認する などリリースまでには複数ステップあり仕様決め~リリースまで「コードを書く」以外にも様々なタスクがあります。
その他にもコードレビューをしたり、パフォーマンスの改善やインフラのトラブルシューティング、セキュリティ対応など多岐にわたり実際にコードを書いているのは業務の4~5割くらいではないかと思います。
会社さんによってはずっとコードを書いてるよ！という場合もあるのかと思いますが、個人的には企画~リリースまで関われてとても勉強になっています。エンジニアは意外とコミュニケーションや調整力も必要な職種なのではと認識が変わりました。
この辺のことは以下の記事で詳しく紹介されています！ tech.libinc.co.jp
メソッド名の！と？に気をつける
Rubyのメソッド 名では、!は破壊的な作用を持ち、?はtrue/falseを返すという慣習があると思います。自分でメソッド の名前を付けるときにもオブジェクトを変更するメソッド は!をつけて、true/falseを返す場合は?を付けるようにしています。
?をつけたら最後true/falseを返せばOKと思いコーディングしていると、ついつい返す前にこそっりとオブジェクトを変更する危ないメソッド を書いてしまい
、一見真偽値を返すだけのメソッド で変更を加えるびっくりなメソッド になってしまい指摘されがちです。
例えば以下はlock_countが10以上だったらtrueが返ってくるだけなので問題なさそうです。
def account_locked? account.lock_count >= 10 end
以下はlock_countが10以上だったらtrueが返ってくるのは同じですがその前にこそっとlock_countに1を足しています。知らない人がメソッド 名を見てtrue/falseが返ってくるだけだと考えてしてしまうと
判定が狂ってしまいバグにつながりそうです。
account.lock_count += 1は別のメソッド にするなどaccount_locked?からは切り出した方が良さそうです。
def account_locked? account.lock_count += 1 account.lock_count >= 10 end
メソッド名を決める際に今までは数十秒考える程度でしたが、ロジックを書くついでにメソッド名を決めるのではなく、しっかりとメソッド名を考えることにも時間を取り、他の人が勘違いしないように気を配らなければと学びました。
三項演算子を効果的に使う
前回の記事でも三項演算子に触れましたが慣れてくるとif文をちょっとスマートにかけるようになります（自分は書けなかったので教えてもらったのですが。。）
例えば、メソッドaccount.lock_countが存在する時は文字列okを返したい、それ以外は'ng'を返したいときにif分でどのように書きますでしょうか？
自分は最初こんな風に書いていました。
return 'ok' if account.lock_count 'ng'
これでも動きますが、三項演算子を使うと以下のようにスマートに書けます
user.lock_count ? 'ok' : 'ng'
小さな改善ですがメソッド名と同じように、他人が読んだときに 迷いが生じないように気をつけたいです。
最後に
また9ヶ月くらいに書きたいと思います！