【週報】駆け出しフロントエンドエンジニアの雑記 ~1/15

  • このエントリーをはてなブックマークに追加
  • LINEで送る

こんにちは!りょた(@Ryo54388667)といいます(^o^)

現在、都内のIT企業で駆け出しフロントエンドエンジニアとして働いている僕が、1週間の学びや気づきをつらつらと書いていきます。

1 「この人いつもいるなー」という人が信頼を得られる納得の理由

結論は、システムエラーはいつ起こるかわからないから、です!

この話は、とある先輩エンジニアの方から教えていただきました。

「始業の15分まえには必ず出勤しましょう。」

新人研修では必ず言われることだと思います。

僕自身、このとき思ったのは、

「そんな小学生に伝えるような、分かり切ったことを言わんといてくれ。。」

こう思っていました。こう思ったのは僕だけではないと信じたいですが。。^^;)

しかし、先輩エンジニアの方の話を聞いて、心を改めないといけないなと感じました。

その先輩エンジニアの方は、始業に必ず会社にいたそうです。人身事故や交通障害など、電車の遅延のあるときでも、どんなときでも必ず始業前に会社にいるように心がけたそうです。

すると、そのエンジニアの上司から

「朝、お前は絶対いるよな(笑)だから、仕事を任せられるんだよ。どんだけ技術が高くても、現場にいなければ対応が難しい場面も多々ある。朝絶対に出勤している、ということは実は結構大事なことだよ。」

そうやって先輩エンジニアは信頼を得ていたそうです。

すごく納得しました。

まさに、凡事徹底、当たり前のことを当たり前にできる、それが求められているんだなと感じました。



2 常に省略はできないかを考える

例えば、条件分岐の問題があるとします。

問題

20以上なら処理1 → 20以上かつ30未満なら処理2 → … 

解答1

if ( num >= 20 ){処理1} else if (num >= 20 && num < 30 ) {処理2} else if …  

解答2

if ( num >= 20 ){処理1} else if ( num < 30 ) {処理2} else if …  

この2つの解答の大きく違う部分はif文の条件の部分です。

問題文をそのまま記述すると解答1になります。しかし、実際は解答2のほうがより良いとされる記述です。

if文で始めの条件で、num >= 20 とあるので、それ以降の処理は num >= 20 が前提となります。なので、記述する必要がないんですね。

これは簡単な例ですが、

この考え方は非常に重要だと思いました。

省略できそうな部分がどこか、同じコードを繰り返し書いてはいないか。

常にこのようなことを頭の片隅に置きながら、コードを書いていきたいと思います(^o^)

  • このエントリーをはてなブックマークに追加
  • LINEで送る