プログラミング初心者が知っておくべきエンジニアに必要な思いやり
ども、カニカマです。カナダでアプリとかを作ってます。
今日は自分がITエンジニアになった時に、早く知っとけばよかったなぁと思ったことです。
いいエンジニアは思いやりがある
どれだけ頭のいいエンジニアでも、人のことを考えられないエンジニアは全然いいエンジニアとは言えないと思ってます。
どう言うことかというと、もちろん性格的なこともあるんですが、それよりもコードにも性格とか思いやりって表れるんですよね。
他人に配慮できるエンジニアの方が良いコードを書いてくれる可能性が高いと思います。
良いコードってなに?
良いコードとはずばり、読みやすいコードだと思います。
そもそも優秀なエンジニアが書いたコードは読みやすいコードが多いです。
いちいち頭の処理を使わなくてもいい書き方をしているし、コメントも残してくれているので、「ん?これはどういう意味だ?」っていうのが少ないですね。
多くのエンジニアにとって仕事の多くの時間は人のコードを読んでる時間です。書いてる時間よりも読んでる時間の方が圧倒的に長いと思います。
なので自分が書いたコードは、人が読む大前提で書かなければいけないんですよね。それはもちろんチームの人間であったり、もしかしたら3ヶ月後の自分かもしれない。
その読んだ人のカロリーを使うようなコードはできるだけ避けたほうがいいわけです。読みにくいコードは読む人の時間を奪うし、バグにつながりやすい。
相手のことを気遣ってコードを書くことは、生産性の観点からも品質の観点からも最重要項目なのかなぁと思います。
例えばついつい将来のことも考えて、今は必要のない機能や拡張の用意までやっちゃうのってあるあるだと思うんですね。そのせいで複雑化してしまうみたいな。オーバーエンジニアリングとも言えます。
そして今の自分しかわからないコードが爆誕してしまう。
でも今必要のないものは必要のないし、いらないものは削ったシンプルでわかりやすいコードの方が優先度高いかなぁと。
プログラミングわからない人のために、めちゃくちゃ頑張って日本語で例えてみます。
こんなメールが来たらどう思いますか?
わからん!わからん!何言ってるかわからん!
みたいなことがダメダメコードでは起こっているんですね。要は
って言いたいだけです。
こんな感じで、四字熟語みたいに短く意味を伝えれる便利だけど難しいやつっていうのはコードでもあってそれを知ってればコードが短くなる。
でも短ければいいって言うわけでもないんですよね。
うーん、上手く例えれてるのかこれは??
読みやすいコードを書くには
まぁそんなことは置いといて、プログラミングの世界ではそういうのは避けましょうねっていうのがありまして。「気遣い」や「思いやり」っていう抽象的なものではなくて、方法論としてというかマナーとしてある程度語り継がれている。
例えば、
・変数、関数の名前は意味のある分かりやすい言葉にしましょう
・if節はネストしないで早期リターンしましょう
・マジックナンバーダメですよ
・意味のあるコメント書きましょう
とかあたりが基本の細かい話としてあります。
こういうのがキチンと考えられているコードは読みやすいし理解しやすいです。
人のために、将来の自分のために読みやすいコードになっているか。
そういうことをエンジニアなら早めに覚えておいた方がいいなぁと思います。フレームワークの使い方よりもよっぽど大事なことです。
例えば、エンジニアになったらまず読まなければいけない本、リーダブルコード。
もうちょっと実践的なコードガイドラインの本。
こういうのを読んだことあるとないでは全然違うコードになると思います。
というわけで
出来るだけシンプルに読みやすいコードを書きましょう。
そして誰が読んでも分かりやすく書きましょう。
コードの可読性、つまり読みやすさはプロダクトの品質、チームの生産性やスピード、拡張性などいろんなところに影響します。
って昔の自分に言ってやりたいですね。
もちろんその方法を初心者の時は知らなかったので、こういう本で知っといたほうがいいよねって話でした。
最近は複雑な処理になりそうだったら、いかにシンプルにわかりやすくなるかを意識しております。
シンプル・イズ・ベストです。
ではでは。
この記事が気に入ったらサポートをしてみませんか?