https://zenn.dev/offers/articles/20220425-universal-attitude
こんにちは！Offers を運営している株式会社 overflow の バックエンドエンジニアの takkun7171 です。 エルデンリングをクリアして、Apex のランクを再開したところ、初のソロダイヤを達成しますた。齢 40 過ぎのオッサンでも、やればできるんだから！！w
さて、技術ブログなんですが、今回は技術というよりも Web エンジニアとして個人的に大事だと思ってる、ノウハウ・心構えについて 書いてみようかなと考えてます。
初心者向けというわけではないのですが、 4 月ですし、新人エンジニアの方も増えるということで 初心者の方にも読んで頂きたいです。
そこそこ分量があるので、前後編に分けて、 前編はハードスキル中心、後編はソフトスキル中心で書いてみます。
自分はマネージャーでも CTO でもなく一介のエンジニアでしかありませんが、 Web エンジニア歴は気付けば 15 年以上経っており、それなりに経験も積み、辛酸も舐めてきました。 自分の経験からできるだけ普遍的に大事そうなことを抽出し、列挙してみました。
参考になる部分もあれば、全く参考にならない部分、 常識過ぎて言うまでもない部分もあると思うのですが、 何かしら読んでる人のお役に立てれば幸いです。
使う人に寄り添って考えて、脳内でユーザの使用してるところをシミュレーションして機能・UI を考えましょう。 機能に価値を持たせるのは使ってくれるユーザです。結局エンジニアもユーザとか社内の人達とか、人に寄り添わないと良い仕事は出来ません。
要件定義して仕様を考えるとき、依頼された内容を鵜呑みにはせず、 そもそもを考えましょう。そもそもこの機能いるの？とか この機能じゃなくて、こういう機能じゃダメなの？とか 最初にここを考えておかないと、終盤で根底から覆されかねないです。 逆に最初の方で根底から覆せれば、相当のショートカットになります。
人間って解像度が上がると、色々物を言い出す生き物 です。 大きな方針が決まったら、細かい話はせずにたたき台や mock を 早めに作ったほうが良いです。 たたき台や mock を作ってから話したほうが、解像度が高いので具体的な話をしやすくなり、 結果として無駄を減らせます。
可読性の高いコードとは、何なのかというと理解するのにかかる時間が短い、人間の脳に優しいコードのことです。
他人や、1 年先の全てを忘れてしまった自分が読むことを想像し、 できるだけ短い時間で理解できることを意識して書きましょう。