7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

株式会社うるる(ULURU)Advent Calendar 2024

Day 12

エンジニア歴30年の、私が気をつけていること

Last updated at Posted at 2024-12-12

まえおき

この記事はうるるAdvent Calendar2024の記事です。

 株式会社うるるで、エンジニア(Ruby on Rails)をしている松原です。
Qiitaアドベントカレンダーの企画として、何かこうかな〜と悩みました。技術的な事は皆さん書かれるだろうし…
 少し悩んで、30年エンジニアやってきた経験と、多くの新人さんを教育してきた経験から、チームでの開発において自分が心がけていて、新人さんにも話してきた事を改めてまとめたいと思います。

軽く経歴紹介

 Appleコンピューターが産声を上げた少し後に、MSXで一般家庭にもパソコンが普及し始めたタイミングでパソコンに触れ初め、一時はデザイナーを志すも、就職氷河期で、就職できずエンジニアの道へ。
Cやアセンブラ(マシン語)から始まり、色々な言語での開発を経験し、アナログ〜3Gの携帯関連の開発、Webサービス、スマホアプリ〜と色々と携わってきました。
うるるへは2024年10月1日にjoin。

心構へについて

心構へと書くと大袈裟になっちゃいますが、私がエンジニアとして心がけていた事を書いてみます。

何故?を考える

 1番目は、何故?を考えるです。
開発者にタスクとして作業が回ってくる時は、作業が細分化された状態で分担する事が多いと思います。
 その状態では、携わっているプロダクトのゴールが見えづらい状態になり、目先のタスクの作業を淡々とこなす事になりがちで、近視眼的な視野に陥りやすいかと思います。
自分の携わる箇所が、切り出された一部だったとしても、そのプロダクトの修正が

  • 何故行われるのか?
  • 誰の為に行うのか?
  • 完成するとどういうメリットがあるのか?

等を常に気にする事によって、自分の作業の結果(効果)が見えてモチベーションも上がるかと思います。

プロダクトに対して、ここはこうしたら良いのでは?という視点も生まれ、プロダクトへの視点がより自分ごととして捉えられる 様になるかと思います。

こだわりすぎない、意見は幅広く聞く

 2番目は、こだわりすぎないです。
エンジニアはこだわりを持つ方が多い印象です。それは経験に基づいた言語だったり、ロジックだったり、開発手法だったり人様々です。
これは開発に限った事ではないですが、こだわり過ぎると、新しい技術や新しい物などを触れる機会を逃してしまう事にもなります。

 色々な意見を幅広く聞き受け入れた上で、自分の中で意見を咀嚼して理解した上で、考えを整理する事を心がけています。

先入観こだわりを捨てて、意見を幅広く聞き、新しい言語や手動取り入れる事で、新しい視点から見る事ができたり、逆に今までのやり方の良い所が発見できたりする事もあるので、いらぬプライドは捨てるに限る です。

理屈(論理)だけで物事(実装)を進めない

 3番目は、理屈(論理)だけで物事(実装)を進めないです。
何か実装で困った時に、ネットを探すと色々な開発の記事があり、サンプルコードも沢山載っていたりします。
XXXの処理が遅いや、こうすると速くなる、というふうな記事があった場合、私は常に自分で実際に試して効果を見極めてから採用する様にしています。

記事を鵜呑みにしないで実際に試して、メリットデメリットを把握してから採用するのが肝要です。逆に、記事を読んでも、先入観に邪魔され記事を全く信用せず試さないのも非常に勿体無いです。
何かを試して得た経験は、後々どこかで活かせると思います!

アイデアは幅広く出す

 4番目は、アイデアは幅広く出すです。
私は、デザインの専門学校を出ているのですが、そこではいかに沢山のアイデアを出すかが求められて、課題に対して、10~30は当たり前にアイデアを出す事が求められます。
エンジニアになってからもその癖が残っており、開発に限らず、常にこうしたら?を考える様にしています。

開発の場合は、何か課題に対して色々なアプローチがある場合、考えられるアプローチ案は、例え捨て案だったとしても可能な限り出すのが良いです。

現時点では無理なアプローチ(例:ライブラリが対応していない、OSが違う等々)でも今後状況が変わってできる様になる事も多々あります。その為色々と調べてアイデアを沢山出しておく事は、エンジニアとして引き出しを多くする事でもあります。
頭を柔軟にして、是非色々なアイデアをひねり出しましょう!

ゴールはスタート

 5番目は、ゴールはスタートです。
あるスパンでプロダクトを完成リリースして終わりではなく、リリースした後に、本当にそれでよかったのか再考する事が大切です。
期間の関係で、本当はこうしたかったけど、できなかった、時間が無くてリファクタリングできなかった…等々、エンジニアとしては多少はあると思います。

また、運用を始めると、開発時には見えていなかった問題が出てくる事もあります。

  • 想定外のアクセスの多さがでエラーが発生する
  • メモリ不足でアラートがでる
  • 速度が遅いと苦情が来た

プロダクトをリリースしてゴール(終わり)ではなく、より良いプロダクトにするスタートを切ったという認識を持つ様にしています。
心残り、後悔、大いに結構、より良いプロダクトにする為に活かしましょう!

実装について

今度は、実際の実装について気をつけている事を書いてみたいと思います。

誰でもわかりやすい記述を心がける

 1番目は、誰でもわかりやすい記述を心がけるです。
エンジニアは、こだわり強い人が多いので、自分の書いたコードにもこだわり持つ人が多かったりします。
また、できるエンジニアの方ほど、さらっとコード書いて内容も把握しているので、変数名が簡単なアルファベットだったりしても、記憶から何やっているか説明できたりします。

簡単な変数名の例:

def hoge
  a = [10, 20, 11, 31]
  t = 0
  a.each do |d|
    if t.zero?
      t = d
      next
    end
    t += d
  end
end

私は忘れやすい し、色々な事を並行してやっていると、あれ?これなんだっけ?になりがちです。
なので、コードを書く時は分かりやすい変数名、分かりやすい関数(メソッド)名を工夫してつける様にしましょう。

分かりやすい名称の例:

def calc_total_array_count
  array_date_list = [10, 20, 11, 31]
  total_data = 0
  array_date_list.each do |decimal_data|
    if total_data.zero?
      total_data = decimal_data
      next
    end
    total_data += decimal_data
  end
end

その他には、if-elseで何個も繋げるより、switch(case)文で分岐したり、同じ処理を何回もかかず1回で済ますとか、ifのネストが深くなりすぎる場合は、メソッド化してコードをシンプルにする等々

自分が解るコードを、誰でも理解できる訳ではないことを肝に命じる

コメントは適宜入れる

2番目は、コメントを適宜入れるです。
言語によっては、メソッド名やメンバー(変数)名をきちんと与えれば、コメントは不要という考え方もあります。
しかし、あまり馴染みのない処理の場合は、簡単でも良いので、日本語でコメントを書いておくと可読性がグッと上がるので、他の人がコード読む手助けになります。

適度に日本語でコメントいれましょう、だって日本人だもの…

ちなみに、私は英語と海外の人にアレルギーはあまりなく、原宿に勤務していた時は、何故か海外の人に道聞かれる事が多くて、単語と身振り手振りで道案内してました。無害そうな顔しているからかな?

実装方法は何通りも考える

 3番目は、実装方法は何通りも考えるです。
アイデアを沢山出すのと同じ感じですね。実装でコードを組む場合、同じ事をする場合でも色々な書き方ができます。
色々と書いた上で、その処理に一番あっていると思われるコードを選択するのが良いと思います。

これは頭の柔軟さも試されるし、引き出しの多さも試されますね。
色々な実装方法を書いていると、新しいアイデアや気づきもあったりするので、おすすめです。
特に新人エンジニアさん!

偶数奇数を判定するコードの例

# 記述1
guusuu_kisuu = ''
if moto_data % 2 == 1
  guusuu_kisuu = '奇数'
else
  guusuu_kisuu = '偶数'
end

# 記述2
guusuu_kisuu = if moto_data % 2 == 1
                 '奇数'
               else
                 '偶数'
               end
# 記述3
guusuu_kisuu =  moto_data % 2 == 1 ? '奇数' : '偶数'

# 記述4
guusuu_kisuu = '奇数'
guusuu_kisuu = '偶数' if moto_data % 2 == 0

# まだまだありそう

共通な処理は、まとめてライブラリ化する

4番目は、共通な処理は、まとめてライブライ化するで。
色々な人が、同じプログラムをいじっていると、同じ様な処理がバラバラに色々なところに書かれがちですね。
例えば外部APIにHTTP送信する処理があちこちに書かれている状態で、HTTPの送信周りで不具合があると、メンテナンスがとっても面倒だし、テストもそれぞれ行わなければならないし、と工数ばかりかかってきてしまいます。

こういう共通な処理は、一箇所にまとめて実装して、各機能から起動すれば、上記の様な時でも修正は1箇所ですし、テストも1箇所行えば良いし、メリットがデメリットを上回ると思いますがどうでしょう?

まとめ

色々と書いちゃいましたが、全部私ができてきるか?というとできてません!
できてないので、自分への戒めの為にもまとめてみました。
これが全てのプロダクトに当てはまるとは思っていませんが、それほど外してもいないのでは?と思っております。

物事は正面からだけみても、ある1面しかわからないので、色々な角度から眺めてみましょう!
新しい発見があるかも?

7
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?