結論から言うと、筆者が思う良いコードとは
・要件（機能要件、非機能要件）を満たした上で、ルール（コーディング規約や、ある一人ないし限定されたコードレビュアーチェック）が守られているコードの事
・良いコードを心掛ける理由は、要件を満たすためのルールだから
という回答を出した。
いきなり、何言いだしているんだろうと思っている読者が多いと思うが、以下その経緯などを記載していく。
〇経緯
筆者も色々な作業を通して、なんとなく良いコード、悪いコードという物が分かってきたと思っている。
そして、基本的には良いコードを書いたほうがいいのだろうと思っていた。
しかし、世の中には、筆者が思う悪いコードが書かれているプロジェクトでも、売り上げが立っているプロジェクトは存在するし、逆に良いコードで書かれているプロジェクトも、売り上げが散々なプロジェクトも見てきた。
このような現実がある中、
「プロジェクトに利益をもたらす為には」⇒「良いコードを書いたほうがいいのか？」
という疑問を持つようになり、その為の筆者なりの答えを出すために、諸々考察や人に意見を聞いたりしてみた。
〇プロジェクトに利益をもたらすとは
こうは書いたが、良いコードを書いたからプロジェクトの利益が上がったというのは、可視化するのは難しい。
利益をもたらすとは、少なくても要求されている仕事をこなすことだと思う。
エンジニアが要求されている仕事は、「要件を満たした成果物を作ること」だと思う。
要件には「機能要件」と「非機能要件」がある 。このトピックについては、筆者もあまり詳しくないのだが、
ここの説明が分かりやすい。
機能要件は、実装すべき内容で、非機能要件は、実装した内容の性能の事と、とりあえず簡単に理解する。
つまり、要件を満たすためには⇒良いコードを書いたほうがいいのか？、を解決する。
〇良いコードの定義
各々が思う良いコードというものはあるし、世の中にはベストプラクティスと言われている物や、先人たちの知恵（デザインパターンなど）が存在する。これは事実だと思う。
ただ、それらは「思想」と同じものだと思う。つまり、普遍的な物差しで判断できるものではない。
適切な場所へのデザインパターンの適用が良いコードだという考えは、例えそれが実質的に正解だったとしても、それはそのデザインパターンの思想と同じ思想と、たまたま個々人が持っているに過ぎなかっただけと思う。
更に、良いコードとは、環境にも左右されてしまうと思う。ハードの制約によって変化されるという面があるように思える。
つまり、普遍的な良いコードという物は、「人の思想」と「環境に左右」される為、定義するのは難しいということになる。
〇良いコードを定義するには
普遍的な良いコードは定義できない。とはいえ、各々が良いと思っているコードをそれぞれが使用してしまうと、同調できる物もあれば、対立する物も出てきてしまうだろう。このような状態は、無秩序と呼べる状況であるといえる。
無秩序の状態では、機能要件は満たせるかもしれないが、非機能要件である
・【2】性能/拡張性・・・どれだけ快適に使えるか？利用者が増えても大丈夫か？
・【3】運用/保守性・・・アフターサービスはきっちりとされているか？
・【4】移行性・・・引っ越しや、乗り換えは簡単にできるのか？
このあたりの対応が、その人それぞれの内容になってしまい、それは要件を満たしていることにはならないのではないかと思う。
これを解決するには、秩序（＝良いコードの定義）を作ってしまうしかない。そして、その作られた定義を全員が守っていく、というルールにしてしまう。
「コーディング規約」や「コードレビュアーチェック」という物が、このルールに該当する物になると思う。
そうすれば、良いコードを書いているかどうかの指標は「要件を満たした上で」「ルールを守っているか否か」に集約される。
〇まとめ
「要件を満たすためには⇒良いコードを書いたほうがいいのか？」
この問いについては、「要件を満たすためには、良いコードを書いたほうがいい」ではなく、「要件を満たしているコードの事を、良いコードと呼ぶ」という答えを出した。
つまり
・要件（機能要件、非機能要件）を満たした上で、ルール（コーディング規約や、ある一人ないし限定されたコードレビュアーチェック）が守られているコードの事
・良いコードを心掛ける理由は、要件を満たすためのルールだから
という結論にたどり着いたのだ。
これに関しては、個人個人の意見や反論があると思うし、それで当然だと思う。
重要なのは、自分で考えて自信をもって答えられる回答があるかどうかだと思う。
皆さんが思う「良いコード」と、それを行う「理由」はなんですか？
