thoughtMichael UnoPosted on December 13, 2019 by Michael Uno 誰かのコードを読むっていうのは、書いた人のロジックを読むということとほぼ同義。他人のロジックを理解するっていうのは、相当な精神的忍耐力を要求される。 Add a Postscript
例えば、パラメーターにブーリアンの値を渡す時に、ある処理を適用させる時は true、させない時は false ってのが普通だけど、それを逆に考える人がいる。処理を適用させない時は true を渡せとか。それでもドキュメンテーションにしっかり記載せれていれば、まだ問題ないんだけど、ドキュメンテーション書く人がコード書いた人とは別の人だったりして、勘違いして、仕様とは逆の説明書いてたりする。これマジ勘弁。 なので、動いたらあとはなんでも良いっしょって考えは、公開するプログラムの場合はあんまりよろしくない。で、利用する人口が増えれば増えるほど変更が難しくなるので、ほんと、最初にきちんとしてないと、後々大変な目に遭う。 で、得てして、最初に完成の全体図って見えないケースが殆どで、これやりたいけどどうすんだろ、ってネットで検索して、動いたからそのコード使い回すとかよくある話なんだけど、そこをきちんと丁寧に移植しないと、オープンソースの場合は、後になって手を加えようとする人が相当な苦労することになる。 ま、チームでコードレビューしながらっていうのが良いんだろうけど。 だから、最初の設計に入る時に、その辺り指摘してくれるベテランのデベロッパーがいればいい。出版における編集者の役割りみたいな。ソロでやると視点が狭まるのでその辺りは不利。 Elaborate
例えば、パラメーターにブーリアンの値を渡す時に、ある処理を適用させる時は
true、させない時はfalseってのが普通だけど、それを逆に考える人がいる。処理を適用させない時はtrueを渡せとか。それでもドキュメンテーションにしっかり記載せれていれば、まだ問題ないんだけど、ドキュメンテーション書く人がコード書いた人とは別の人だったりして、勘違いして、仕様とは逆の説明書いてたりする。これマジ勘弁。なので、動いたらあとはなんでも良いっしょって考えは、公開するプログラムの場合はあんまりよろしくない。で、利用する人口が増えれば増えるほど変更が難しくなるので、ほんと、最初にきちんとしてないと、後々大変な目に遭う。
で、得てして、最初に完成の全体図って見えないケースが殆どで、これやりたいけどどうすんだろ、ってネットで検索して、動いたからそのコード使い回すとかよくある話なんだけど、そこをきちんと丁寧に移植しないと、オープンソースの場合は、後になって手を加えようとする人が相当な苦労することになる。
ま、チームでコードレビューしながらっていうのが良いんだろうけど。
だから、最初の設計に入る時に、その辺り指摘してくれるベテランのデベロッパーがいればいい。出版における編集者の役割りみたいな。ソロでやると視点が狭まるのでその辺りは不利。