「プログラマが知るべき97のこと」を読んで個人的に為になった部分まとめ
「プログラマが知るべき 97 のこと」を読んで見て、
その中で個人的にエンジニア人生で活かせそうなものをいくつか厳選してみました。
備忘録的な感じなので、私も後で見返す予定です。
ボーイスカウト・ルール
ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分ではなかったとしても、きれいにしてからその場を去る、というルールです。
この簡単なルールを皆が守るだけで、少なくとも今よりシステムの品質が低下することは防げるでしょう。逆に、時間が経つごとにシステムの品質は徐々に向上していくはずです。これは開発に関わるチームの全員が、自分の担当する小さな部分だけでなく、システム全体の質に目を向けるということにもつながるでしょう。
その通りですが、無理のない程度でもコード修正の際にこのルールを実施していれば、徐々にコードは整理されていくので、最終的には安定かつ可読性の高い綺麗なコードになりますね。
関連箇所の把握にもなるのでコードの理解も進みますし、新しい発見や勉強の機会もいくつか生まれるような気がしています。
コードに書けないことのみをコメントにする
書いていることが技術的に誤っているわけではないが、コードに何か価値を加えるわけでもない、そういうコメントは、一種の「ノイズ」とみなすことができます。コードに書かれていることをただオウム返しにするだけで、何の情報もつけ加えていないコメントはノイズでしょう
ノイズのようなコメント、情報の誤ったコメントがコードベースに大量にあると、やがてプログラマはコメントのすべてを無視するようになります。ただ読み飛ばすという人もいれば、コメントが画面から消えるよう対策を講じる人もいます。プログラマという人種は皆、問題を回避することに長けています。
本来コードを見ればわかるはずのことをコメントに書かなくてはならないのは、コードの構造や書き方を見直す必要があるということです。メソッドやクラスの名前がわかりにくいからコメントを書くというのなら、名前を変えてしまった方がいいでしょう。関数が長くて分かりにくいせいでコメントが要るのなら、関数を小さく分割して、どういう関数かがすぐに分かる名前を個々につける方がいいでしょう。コード自身にできる限り「語らせる」ようにするのです。
エンジニアになりたての時はオウム返しコメントもやっちゃってましたし、今も気を抜くとしてしまう。。
まずコメントが必要になること自体、構造や書き方を間違えている可能性があるので、コメントが必要になったらまずそもそもを疑ってみるのがいいですね。
コンテキストの部分だったり、何かの事情があり特殊な処理をしている時など、コード上で表現できない箇所のみコメントをすることで、より価値のあるコメントができますね。
DRY 原則
「DRY（Don’t Repeat Yourself：繰り返しを避けること）原則」は、プログラミングに関して守るべきとされている原則の中でも特に重要なものと言っていいでしょう。
開発者は、アプリケーションの中に何らかの「重複」があれば、また、重複が起きそうであれば、それを察知する必要があります。そして、適切なプラクティスや抽象化によってそれを排除する必要があるのです。
重複によりコードベースが大きくなれば、開発に携わる人間がシステム全体を完全に理解することも難しくなります。特に困るのはコードに変更を加える時です。どこかに変更を加えた場合、それとロジック等が重複している箇所にも同様の変更が必要かどうか確認しなければなりません。
基本的に同じような処理をする際は関数などのコンポーネント化しておくと、再利用がしやすい他、テストや修正コストが圧倒的に少なく済みますね。
重複した処理を別の箇所で書くのはバグの温床になりやすい。
余分なコードは決して書かない
「より少ないことは、より豊かなこと（Less is more）」。言い古された格言ですが、確かに真実です。
たとえば、一部のコードを削ることで、かえってコードベースの質が向上するということもあります。私も実際にコードベースをそういう方法で改良したことがあります。
今日のソフトウェア開発は、YAGNI（You Ain’t Gonna Need It.：それは多分、必要ない）をはじめとする XP（eXtreme Programming）のプラクティスに従って行われることが増えています。ただ、人間のすることなので、どうしても時々は、プラクティスに従わずに作業をしてしまうことがあるのです。
・余計かもしれないが、面白そうだと思えた
・将来必要になるかもしれないと思った。そのためにはいま書くのがベストだと思った
・必要かどうか判断に迷った。顧客に判断を仰ぐべきだったが、それよりも実装してしまう方が簡単だと思った
・余分な機能を正当化するため、議論を経ておらず、ドキュメントにも書かれていない要件をプログラマがでっちあげた
これもありがちなパターンではありますよね。。
今必要ない機能を書いてしまい、変に依存しているので修正するのに時間がかかったり、謎のバグを生んでしまったり、基本的には運用コストが上がるデメリットしかないですね。
本当に必要な機能だけ実装をするようにするのと、実装するとしてもミニマムかつ簡潔な形で実装をすることが重要なのかなと思いました。
プロのプログラマとは？
プロフェッショナルなプログラマの最大の特徴は 「自分が責任を取る」という態度、責任感です。プロのプログラマは、まず自分のキャリアに責任を持ちます。責任の取れないような見積りやスケジューリングは決してせず、作る製品の質にも責任を持ちます。ミスがあれば、必ず自ら対応します。他人に責任を押しつけるようなことは一切しない、それがプロです。
これはプログラマ関わらずどの職種にも当てはまることだとは思いました。
自身の選択や発言などに責任を持つことで、必然的に知識を蓄える必要が出てくるのでスキルアップにも繋がりますし、より大きい仕事を任せてもらえるのではないでしょうか。
「イエス」から始める
私はテクニカルリーダーという立場になったばかりの頃、自分の役目は、プロダクトマネージヤやビジネスアナリストから来るバカげた要求をはねつけ、自分たちのチームの素晴らしいソフトウェアを守ることだと思っていました。何か要求が来た時には、それを「受け入れるべきもの」ではなく、常に「却下すべきもの」と捉え、その前提でほとんどの会話を始めていたのです。
しかし、あるとき私は突然悟ったのです。「ノー」でなく「イエス」という返答から始めるようにすれば、それだけ物の見方は大きく変わり、仕事の進め方も変わるだろうと。それからというもの、「イエス」から始めることは、テクニカルリーダーに不可欠な態度だ、とまで考えるようになりました。
「イエス」から始めるようにする、という簡単な変化だけで、私の仕事への取り組み方は劇的に変わりました。わかったのは、「イエス」という返事の仕方にも多くの種類があるということです。たとえば、誰かが「このアプリケーションのウィンドウを全部、円形で半透明にしてくれたら嬉しいんだけど」と言ってきたとします。こういう要望は、「バカバカしい」と即座に拒否することもできます。そうはせずに「どうしてですか」と尋ねるようにすると、その方が良い結果になることが多いのです。尋ねてみると、円形で半透明のウィンドウが欲しいと思う、何か切実な理由が本当にあるかもしれません。どうしても「ウィンドウは円形で半透明であること」と定められた規格に準拠しなくてはならない、ということもあり得ます。要望に応え、規格に準拠できるようにすれば、その顧客から大口の契約が取れる可能性もあります。
たとえ同じシステムでも、それに対する見方は人によって違います。そうした認識のズレが、要望をバカげたものに思わせるのかもしれません。要望された時に、相手に「なぜ」と問う代わりに、自分に「なぜ、こういう要望が出るのだろう」と問いかけてみるのも有効です。すると、最初に「バカバカしい要望」と思ったのがそもそも間違いだった、とわかることもあります。最終的には、自分だけで判断せずに、社内の他の人の意見も聞いて意思決定をすべきでしょう。重要なのは、「イエス」と言って要望に応えるのは、必ずしも顧客のためだけではない、ということです。そうすることは自分自身や開発チームにとっても役立つのです。
非エンジニアやユーザーの方と会話をしていると、コンテキストがわからなかったり、何がしたいのかわからないことがたまにあります。
それを否定するのは簡単ですが、背景を確認して「イエス」の前提で考えてみることにより、自分が今まで見えなかった景色や新しい発見、成長の機会も生まれそうですね。
他者への思いやりを意識したコーディング
プログラマは 1 人で作業することが多いので、どうしても、問題を自分 1 人だけで解釈し、その解釈だけを頼りにコードを書いてしまいがちです。多くの場合、プログラマはどこかのチームに属してはいますが、結局は一人一人が孤立してコードを書くことになります。孤立して作業をしていると、このコードはいずれ他人によって使用され、実行されるのだということを、つい忘れがちになります。他人がコードを拡張することもあれば、自分の書いたコードに依存して誰かがコードを書くこともあるということを忘れてしまうのです。ソフトウェア開発の「社会的側面」は見過ごされやすいのです。
誰かが書いたコードの質は、必ず他の誰かが書くコードの質に影響します。もし私が質の低いコードを書いてしまったとしたらどうでしょうか。その場合は、誰か他の人が非常に質の高いコードを書いていたとしても、私のコードを利用した途端に悪影響を受け、同じレベルにまで質が低下してしまいます。その悪影響を減らすためのテクニックは多数ありますが、悪影響がなくなることはありません。いずれにしろ、他の人に本来する必要のないことをさせてしまうのです。自分の世界に没入して他人のことを一切考えなければ、そういう事態に陥りやすいでしょう。
自分のコードはすでに質が高いと思っていても、他のプログラマの存在を意識すれば、より良くする方法が見つかる可能性があります。他人の存在を意識したコードとはどういうものでしょうか。多分それは、一見しただけでは、単なる良いコード、クリーンなコードと区別がつきません。しかし大事なのは、コードそのものの質ではなく、他への影響です。他人の存在を意識すれば、他人の書くコードにも当然良い影響を与えることになります。チームの同僚のことを考え、思いやりを持ってコードを書けば、それは同僚たちにとって価値あるコードとなり、いずれ自分にも良い影響となって返ってきます。
どうしても 1 人で作業するとなると、自分を中心とした考え方になってしまいがちですよね。。
仲間が書いたコードの質に自分もかなり影響を受けたことがあるので、他の人に良い影響を与えられるよう、コードの質を高める努力は継続する必要はありますし、もし若手のエンジニアが入ってきた時にも、チーム全体のコードの質に影響してしまう可能性があるので、しっかりとコーチングをする必要があると思いました。
最後に
「プログラマが知るべき 97 のこと」はきのこ本で無料で読めるようになっているので、
もし時間があるエンジニアは読んで見てはいかがでしょうか。
Discussion