どうもこたにんです。
コーディングに正解を求めるのか
Kotlinコードを書いたり、Terraform書いたりしてて、ふと思ったんですよね。
コーディングに正解はあるのか
特にTerraform書いてて感じたんですよね。
文法としての正解があり、定義同士のつながりにも正解がある。
必要な機能を満たすために書き上げられるコードは、誰が書いても同じものになる。
書き方が厳密で、そこにアルゴリズムも存在しないため、正解があるなと。
（linterで解決するようなコーディング規約的な部分は省略します）
一方Kotlinでサーバサイドコードを書いてると、そこには正解がないように感じたんですよね。
アーキテクチャ的に、アルゴリズム的に、こうした方が良いというベターな解、「最適解」のようなものはあります。
ただそれは「正解」かと言われると、「今この場面このアーキこのリポジトリにおいては正解」と言わざるを得なくて。
言語ルールはあれど、動作を満たすためのコードにはいくらでもアレンジの余地があり、そこに必ずしも正解はない。
なので、コーディングに正解があるのかと言われると、ときによると。
広い意味では「正解はない」と、わたしは思うわけです。
コーディングに正解を求めるのか
ただ、業務でコードを書いている、コードを見ている上では、正解を求めます。
機能的な正しさは大前提として、先ほどの「今この場面このアーキこのリポジトリ」における正しさを求めます。
環境にもよりますが、コード品質と承認プロセスにおいて、レビュワーとレビュイーという関係性が存在するためです。
レビュワーはレビュイーの正誤を判定しなければならないし、レビュイーはレビュワーが出す正解を求めます。
コーティングの正解を知りたいのか
とりわけ、コーディングにおいて成長をしたいと感じるレビュイーは、自分のコードや考えが正解であるかを知りたいです。
それに対してレビュワーは正誤判定をして導いてあげなければならない場面も多いです。
正解を示すことで、今後類題が出てきた時の考えのきっかけになるし、正解を知っているからこそ自分なりの最適解を導くことができるようになります。
正解を示すことで、考え方に制限をかけることになるかもしれませんが、それでも正解を知ることで次の思考に進むことができます。
守破離というやつです。
レビュワーにおいても、正解を求めることすなわち、自身の思想を整理して一意に定めて表現することになります。
その思想の整理がどれだけ大変で、どれだけ価値のあることなのか、レビュワーであればわかることでしょう。
正解を出すことがコーティングなのか
正解が必ず存在する場面もあるし、正解はなく最適解の場面もある。
ときには正解を出すことが求められるし、ときには正解は要らないかもしれない。
そのときの最適ではない、正解ではないコーティングをしたとしても、機能的に満たしていれば正解の振る舞いをする。
正解を出すことがコーティングではないのかもしれない。
間違ってもコーティングだし、正解でもコーティング。
自分のコードは正解なのか、行動しないとわからない。
