人(ユーザーとエンジニア)のための開発を行えるように
人のための開発をしたい
みなさんこんにちは!たかぽんです😄
もうすぐ27卒の人はもちろん、それ以外の学年のみなさんもサマーインターンや夏のエンジニアイベントが始まりますね!
私もサマーインターンやハッカソンが決定しつつ、楽しみすぎてずっとコードを触っている状態です💦
今回はコーディング以外で、サマーインターン前に「自主学習」や「インターン・ワークショップ」の中で得たことを書いていきます!
※技術的なことはあんまり書いていないです
これから大切にしたいこと・学んだこと
-
そもそも、なんのためにコードを書いているのか
-
コードの命名規則
-
相手を意識した書き方
-
可読性の大切さ
-
-
サマーインターンで活かしたいこと
なんのためにコードを書いているのか
初めに「なんのためにコードを書いているのか」という話です。
もちろん「開発が楽しいから」という理由もありますが、ここまでの学びで、僕がこれから大事にしたいのは、「人のための開発を行う」ということです。
実務ではクライアント様からお金をいただき、プロダクトを開発する立場である以上「人のための開発」になると思います。
では社会に出た時、求められるエンジニアとはどんな人か。
今の自分なりに考えると、やっぱり 「細かいところに気づけるエンジニア」 だと思っています。
「細かいところに気づく」必要性
-
安定したアプリやサービス を作るため
個人開発では、好きなように、好きなロジックで書くことができます。
ですが、お金をもらってユーザーに対して開発を行う、すなわち安全で信頼できるプロダクトを届ける必要があります。
バグだらけのアプリやサービスなんて使いたくありません。
また「正常に動くが不安定なもの」も使いたくありません。 -
ユーザーに安心を届けるため
昨今、アプリを使用するとなると個人情報をお預かりし、プロダクトを提供することも多いです。
その中でリロードが長すぎる、頻繁にアプリが落ちる、エラーが出る、といったアプリに情報を預けるのは怖すぎますよね。
※つまり、最初に考えるべきは「ユーザー(人)のための開発」 です。
では細かいところに気づくとはなんでしょうか?
コードの命名規則
では細かいところに気づくとはなんでしょうか?
1つに、コードの命名を鉄則するということだと考えています。
命名規則というと「変数名」や「関数名」、「コメント」など様々なものがあると思います。
チームで開発する以上、自分の書いたコードが他人にもすぐに理解される必要性があり(可読性)、この可読性でプロジェクトの進捗や、機能追加など今後のプロセスに大きな影響が及びます。
以下では、特に次の2点を意識してみました。
- 変数名や関数名が冗長でないこと
- コメントって果たして必要なのか
- 他にもインデントやタイポしないなどあると思います。(ここでは書きません)
また、「コードの見やすさ===エンジニアへの思いやり===人のための開発」にもつながると考えています。
開発の中でこういった変数名や、チームの決め事に一番時間をかけるべきなのではないかとも思ったりします。
1.変数名や関数名が冗長でないこと
冗長すぎる(同じ意味の単語が複数あるなど,,,)変数名はメンテナンスのときにかえって混乱を招きます。
下記だとどこまでが変数名か(関数めいか)長くわかりずらすぎます。
# × 冗長すぎる例
def get_user_data_from_database
# 処理内容…
end
user_data_from_database = get_user_data_from_database`
2.コメントって本当に必要なの?
実際コメントが必要なところはあると思います。
例えば、あるプロジェクトで「この期間だけ開催するキャンペーン」などがあれば追記する必要はあると思います。(この関数、クラスってなに?となるので)
ですが、命名規則を固めていれば、変数や関数を見ただけでどんな処理であるか、ということがわかるはずです。(というかわかるものにすべき)
仮にコメントを書くとすると、機能やロジックを変更した時にコメントも修正しないといけないという二重での修正が必要で手間がかかります。
なので、命名規則を言語特性のものや、チームでしっかりと話し合い、固めて行く必要があると思います。
以下はロジックを変更した時に、コメントも変更したものです
元のRuby
# 配列内の整数をすべて足し合わせて返すメソッド
# 引数 numbers: 整数の配列(例: [1, 2, 3])
# 返り値: 配列内の合計値(例: 6)
def sum_all(numbers)
total = 0
numbers.each do |n|
total += n
end
total
end
# 使い方の例
p sum_all([1, 2, 3, 4]) # => 10
変更後のRuby
# 配列内の「偶数のみ」を足し合わせて返すメソッド
# 引数 numbers: 整数の配列(例: [1, 2, 3, 4])
# 返り値: 配列内の偶数の合計値(例: 6)
def sum_all(numbers)
total = 0
numbers.each do |n|
total += n if n.even?
end
total
end
# 使い方の例
p sum_all([1, 2, 3, 4, 5, 6]) # => 12 (2 + 4 + 6)
サマーインターンで活かしたいこと
サマーインターンでは、言わずともコードの細かいところに気づき、すぐに修正や提案ができるようになりたいです
ですが、技術力がまだまだ足りてなさすぎるので、技術力を高めつつ、日頃の開発から「人のための開発」というところを意識して開発していきたいと思います。
こういった気遣いのできるエンジニアというところも意識しサマーインターンやチーム開発で経験を積み、夏明けには今よりも自信を持った学生エンジニアになりたいと思います!!
まとめ
以上の理由から命名規則を大切にし、開発者やユーザーを思いやる開発をすべきだと考えました。
まだまだ未熟ですので、間違いだらけ、日本語おかしすぎの記事になっているかと思いますが、多めに見てください😢
「ここ違うよ」や「私はこう思う」などあれば教えていただきたいです!!(私の成長のためと記事修正のため)
ありがとうございました!!
Discussion