規模がそこまで大きくない開発案件をする場合って、コードを書く作業自体をすべて一人でしてしまうケースってあったりするんですけど、こういうのに慣れてしまうとコードが自己満足になって保守性の悪いものになってしまうことがあったりします。
当然、一人であればそれさえも気が付かないのですが、別のメンバーが保守することになったり、拡張していく際にプログラマを増やすといった場合にそのコード自体の出来が悪くて恥ずかしい思いをしたりもします。
つまりは、見られるコードを書くという意識付けって結構大事なんだなと思ったり。
一人でコードを書く弊害
一人でコードを書くことに慣れてしまうと自分の癖が出やすくなったり、他人が保守することを意識しないことから例えば下記のような弊害が出てきたりします。
・ コーディング規約が無視される（そもそも守る気もない）
・ 暫定的なコードが多い（やたらコメントアウトした処理が残っている）
・ 何でもかんでも作る（車輪の再開発的なものが多い）
・ ベストプラクティスを意識しないので処理が冗長（長大なライブラリが出来上がる）
・ フレームワークなどを取り入れない（開発の効率性が無視される）
・ 連携できない（固定化した環境でしか動かない）
・ 仕組みが古い（スキルアップが図れていない）
・ バージョン管理されていない（ファイルのコピーでバックアップ）
・ コメントがない（謎の関数群）
・ テストがあまい（自分の環境で動いたからOK）
出来上がるコードが他人から見ると非常に保守性の悪いものだったりするわけですが、現状そのコードを保守するのは自分だけだという思い込みもあったりして、当人にとってはあまりそういう風には思っていなかったりするわけす。
また、エンジニア本人にとっても、「あの人と組んで作業するぐらいなら自分一人でやった方が効率的だ」という偏見を持ってたりする人もいて、確かに一時的な作業で言えば効率的なのかもしれませんけど、出来上がったものが先々のシステムライフサイクルを考えてベストなのかどうかはプロジェクトマネージャとしてはよく吟味しないといけないことではあります。
他人が読むコードという意識付け
こういう状況が長く続くと、「ソースを書くエンジニアと読み書きするエンジニア」で書いたように他人のソースコードをそもそも読まないエンジニアを生む原因となったりもするんだろうなと思ったりします。
実際、自分の癖や趣味を満載に盛り込んだコードを書いたとしても、コードとしてあるべき姿を反映できていない以上は、コードそのものに対してもあまり興味を持っていないんだと思ったりするわけです。
ですから、他人のコードにも興味が持てないし、他人が自分のコードを読むことも意識しなかったり。
プロジェクトでは多くは仕様が実装通りかどうか、テストがパスしているかどうかにばかり意識がいき、コードがどうであるかなんてあまり意識されないのでエンジニアとしてもその意識が希薄になりがちというのもあるんだと思います。
コードを書くスキルを上げるには他人のコードを読むのが手っ取り早いと思うわけですけど、その際に自分のコードとの差異は何があるのかや、そもそも自分の書いたコードに対して羞恥心を持ったり他人のスキルに対して純粋にすげーと思う憧れ的なものや原理を追求する好奇心を持たないとなかなかレベルアップしないと感じたりします。
もちろん、体制的なところでその案件の開発に割り当てるプログラマに限界があることはよくあることです。
そんな場合でも、きちんとその人のコードをレビューする人をあてがうだけでも当人の意識も変わってきますし、結果的にできるコードも第三者によるレビューが反映されたものとなるため随分違ってくることなんではないかと感じたりします。
コードが共有されるべき意味というのはそういったところの効果も大きいのだと感じます。