ソフトウェアエンジニアとして、決してすべきではないのこと 10選
参照リンク：
https://favtutor.com/articles/donts-for-software-engineer/
ソフトウェアエンジニアになって5年以上になりました。これは私を専門家にすることはできませんが、十分な間違いを犯していると確信しており、皆さんと共有することができます。以下はソフトウェアエンジニアとして、永遠にすべきではない10のことです。
1）完璧主義者であること
完璧なものなどありませんし、「完璧なコード」のようなものも存在しないと信じています。
ソフトウェア開発は反復プロセスです。コードを作成し、テストし、フィードバックを得て、リファクタリングして、繰り返します。今日はうまくいったものが明日はうまくいかなくなるかもしれません。したがって、ソフトウェアは柔軟で変更しやすいものであるべきです（これがソフトウェアと呼ばれる理由です）。
プロフェッショナルであることは完璧主義者であることとは異なります。ほとんどの場合、最適に優れているようなものです。
2）「リファクタリングする時間をください！」
リファクタリングとは、コードの外部動作を変更せずに既存のコンピュータコードを再編成するプロセスを指します。リファクタリングしないコードは次第に理解しにくくなり、他の開発者には使用できなくなります。
開発者は、作成されたコードは機能を実装した後、常にリファクタリングされるべきであることを知っています。しかし問題は、非技術メンバーがこれらの詳細に関心を持っていないことである。彼らはよく「私たちは急速に発展している会社なので、もっと機能を追加することに集中してほしい」と言いますが、すぐにコードの維持が難しくなり、「コードをリファクタリングする時間をください」と懇願せざるを得ません。
リファクタリングのために余分な時間や日数を費やす必要はありません。リファクタリングを機能実装の一部にしてください。
3）「レガシーコード」の意味を誤って理解する
Web開発生態系は目まぐるしく変化します。前のWebプロジェクトはNext.jsバージョン10を使用していたと記憶しています。そのプロジェクト開発期間中、Next.jsは第11版をリリースし、新機能と改良をもたらします。突然、第10版はレガシープロジェクトになったような気がします。
多くの人は「レガシーコード」の意味について一定の誤解を持っており、「レガシーコード」は「旧コード」を意味すると思っているが、事実はそうではない。「レガシーコードを効果的に処理する」の著者Michael Feathers氏は、レガシーコードはテストが書かれていないコードだと述べている。テストできないコードはリファクタリングできません。リファクタリングできないコードは維持できません。
Next.jsの「旧」プロジェクトは実際にはかなり良いテストカバー率を持ち、すべてが良好に動作しています。これらは「レガシーコード」ではなく、「良好なコードを維持する」ことです。新しいツールばかり追いかけて時間を無駄にしないでください。Githubは今でも17年の歴史を持つRuby on Railsを運行していることを忘れないでください。
4）関数的プログラミングが最も良い
関数式プログラミングは非常に斬新で、多くの若者が試しています。しかし、これはどこでも関数式プログラミングを使うべきではありません。
例えば、Flutterプロジェクトがある場合、UIレイヤで関数式プログラミングを使用するのは良いアイデアではありません。不必要な再レンダリングのため、UIレイヤが純粋な関数コードを使用しすぎるとパフォーマンスの問題が発生します。Flutterはオブジェクト指向プログラミングなので、この方法で使用する必要があります。
これは、関数的プログラミングを完全に避けるべきではありません。上記の例では、トラフィック論理層は関数的プログラミングを使用するのが適切であるべきである。実際の状況に応じて、適切なツールを選択するだけです。
5）ベストプラクティスに盲目的に従う
ソフトウェア開発のベストプラクティスには、クリーンなアーキテクチャ、SOLIDの原則、DRY、KISS、YAGNI、TDD、BDD、CI/CDなどがあります。これらのベストプラクティスを提案する意図はすべて良いが、盲目的に従うべきではありません。
例えば、テスト駆動開発（TDD）は、コードが期待通りに動作することを保証する良い方法です。しかし、ClojureやPythonのようなインタラクティブプログラミング環境（REPL）をサポートする言語を使用している場合は、TDDをすべて採用する必要はないかもしれません。
TDDの唯一の目的は、できるだけ早くフィードバックを得ることです。テストを書かずにフィードバックを得ることができれば、TDDは必要ありません（ただし、テストは書くべきです）。
6）孤独に奮闘する
「問題解決能力」をアピールすることに熱心な初級開発者をたくさん見たことがある。彼らは常に他の人が解決した問題でもがいている。このような人にならないでください。車輪を再発明しないでください。
偉人は往々にして巨人の肩に立つ。
チームで仕事をするときは、経験豊富なチームメイトに学ぶことができます。彼らはあなたの「巨人」です。彼らの肩に飛び乗って、時間を無駄にしてから地面に跳ね返さないでください。目標はより高い巨人を狙うことです。
7）自覚のないまま「フロー」に陥る
「フロー」を経験したことがありますか? 完全にタスクに没頭し、エネルギーに満ちて集中している心の状態です。プログラマーにとって「フロー」に陥ると、コードが勝手に書き込まれ、自分が媒介者になるような感覚になります。つまり、ゾーンに入っているのです。
ただし、注意してください。コードを書きすぎる可能性があります。フロー状態にあるときに、過剰にエンジニアリングしていることによく気づきます。私だけでなく、「Clean Code」の著者である Robert C. Martin も、フロー状態にあるときに非生産的になることを経験しました。
意図的に流れを断ち切るには、「ポモドーロテクニック」を使うことをお勧めします。これは、25分間作業して5分間休憩する時間管理法です。集中力を維持し、燃え尽き症候群を防ぐのに役立ちます。
8）体を動かすのを忘れる
ソフトウェアエンジニアの仕事は楽ではありません。パソコンの前に座ると数時間、キーボードをたたいたり、画面を見つめたりすることがよくあります。「心の流れ」に入ると、自分の健康を忘れやすくなります。しかし、健康が最も重要であることを覚えておいてください。健康な体がなければ、いくら頭が良くても無駄だ。
30分ごとに（トマト作業法を採用すれば25分ごとに）体を動かすことに注意しなければなりません。立ち上がって、背伸びをして、あちこち歩いて、水を飲みます。これはあなたが集中して、倦怠感を避けるのに役立ちます。
9)プログラミングの楽しさを忘れる
初めてプログラミングを試みたとき、とても興奮しました。毎日コードを書いたり、問題を解決したり、新しいことを勉強したりします。
しかし、時間が経つにつれて、プログラミングの楽しさを忘れてきました。「きちんとしたコード」を書くことに執着しすぎて、ベストプラクティスに従って、「難題」を解決します。他の人や会社のコードに従うことに疲れているので、自分のコードを本当に書くことはできません。私の創造力はどこに行きましたか。
プログラミングの楽しさを常に覚えておくべきです。これは難しいことを知っていますが、できるだけ時間を見つけて自分のプロジェクトをして、新しい知識を学ぶべきです。勤務時間中に、手元のプロジェクトでは使用できなくても、チームメートとエキサイティングな新技術を交流してみましょう。これは動力を維持し、インスピレーションを引き出すのに役立ちます。
10）ソフトウェア エンジニアではなく「コーダー」であること
「コーダー」と「ソフトウェアエンジニア」には違いがあります。コーダーはコードを書く人であり、ソフトウェアエンジニアはコードを使用して問題を解決する人です。
プログラマーになるべきではない 2 つの理由があります:
いわゆる「コーダー」は将来 AI に取って代わられるでしょう (実際、すでに取って代わられつつあります)。これは多少議論の余地があるかもしれませんが、悲しいことに事実です。
人々はあなたのコードに興味があるのではなく、あなたが彼らの問題をどれだけうまく解決できるかに興味があるのです。
コードをツールとして使う「問題解決者」になりましょう。問題を理解し、最善の解決策を見つけ、コードを使ってそれを実装します。それがソフトウェア エンジニアの仕事です。
結論
これらは、ソフトウェア エンジニアとして絶対にやってはいけないと私が個人的に考える10のことです。これらは私の個人的な経験に基づいているため、すべての人が同意するとは思いません。しかし、皆さんの役に立つことを願っています。