プログラマの三大美徳
プログラマは怠慢、短気、傲慢であれ
怠慢
楽をするのであれば、手間を惜しまない気質のことです。
コードやテストの自動化など、めんどくさいことはコードで行います。
業務やプロジェクトでは、めんどくさいと思う何回も繰り返すものがあります。そういったものを自動化して怠惰であれるようになりましょう。
短気
上手く動かなかったらコードをかき直したりする気質です。
また、今ある問題に着目せず、今後起こりうる問題を想定したコードを書きます。
コードの動作が遅い、動作がおかしいなどの面で短気となり、すぐに修正しましょう。それらのコードを残すのは負債となりえます。
傲慢
高いプライドを持つ気質です。
レビューされても指摘する場所が無いほどのコードを書きます。
プロフェッショナルの意識を持ちましょう。コードは時として汚いものになりますが、意識をすることで常にキレイな状態に保てます。
エゴレスプログラミング
プログラミングでエゴを捨てます。
うぬぼれやプライドを捨てて、仲間にコードを見せる、コードを見る時に、自分のほうが優れているという考えを捨てより良い物を作るということに価値観を置きましょう。
エゴレスプログラミングには十戒があります。
- 自分自身も間違いを犯すということを理解し、受け入れる
- 書いたコードは自分自身ではない
- どれほど極めても、上には上がいる
- 相談をせずにコードを修正しない
- 自分よりスキルが劣る人にも尊敬と敬意と忍耐を
- 世界で唯一変わらないものは、変わるということだけ
- 権威は地位ではなく知識から生じる
- 信じるもののために戦い、負けを正直に認める
- 部屋に籠もりきりではダメ
- 人にやさしく、コードに厳しく
手法
曳光弾
骨格コードを作りましょう。
これは、最初に動作する土台を作るということです。
土台をつくっておけば、骨格のコードに肉付けをしていくだけになり、開発が進んでいく時の指標となります。
また、動作する土台なので、ユーザーからのフィードバックも得られます。
土台を作っておけばテストやデバックもやりやすくなります。
## 防御的プログラミング
こうなるかもしれないという意識を持ってプログラミングをします。
プログラミングでは外部から関数の値を渡されたり、外部ソースからデータを取得したりします。そうなった場合、不正な値がもし入ってきたときにはソフトウェアはエラーを出すかもしれません。
そうならないように、不正なデータが入ってきても大丈夫なように初めからバリデーションなどを使って値を精査するような仕組みを作りましょう。
ドッグフーディング
自分で開発したソフトウェアを、自分で使いましょう。
ソフトウェアを開発するということは必ずユーザーが存在します。ソフトウェアが使いにくいものであった場合、ユーザーは使ってくれなくなります。そうならないためにも自分自身がユーザーの視点に立ち、ユーザー目線で開発をしましょう。
ラバーダッキング
プログラミングでバグや不具合、上手くいかないことが起きたら、誰かに説明してみましょう。
話すということは、相手にわかりやすくするために現在の状況を整理しなければなりません、それが自己解決に繋がります。
コンテキスト
文脈を上手く使いましょう。
- コードの読み書きに使用する
- コードには、書く人と読む人が居ます。書く人は、変数名や関数名やコメントで読む人にコンテキストを構成します。そうすることでコードの責務、何をしているのかがわかりやすくなります。
コードを書く時にコンテキストを与えると、思考が迷子になりにくいです。ソフトウェアではたくさんのコード、モジュールが複雑に絡み合って作られています。コンテキストがあることによってその複雑に絡み合ったコードやモジュールを読み解くことが出来ます。
法則
コンウェイの法則
アーキテクチャを設計してから組織を編成しましょう。
組織を編成してからアーキテクチャを設計すると、人に偏った設計となり、属人性が高くなること。小ミュニケーションにズレが生じる可能性があります。
アーキテクチャを設計し、プロセスを作ってから、組織をそれに当てはめましょう。
割れた窓の法則
悪いコードは許してはいけません。
悪いコードが一つでもあれば、そこから悪いコードが増えます。
「あの部分はこう書いてたからこれでいいか」や「とりあえず動くから処理は遅いけどいいか」などを許すことになります。
そうなった場合、ソフトウェアの品質は地の底に落ちます。
悪いコードは、常に修正し残さないようにしましょう。
80-10-10の法則
高水準のツールやソフトウェアは開発するとユーザーの求める80％を実現することができます。しかし、100％を満たすように開発をすると、とたんに開発が立ち行かなくなります。
ソフトウェアの問題解決を狭いものにしましょう。狭くすることにより、問題を的確に捉えることができ、狭くしたことによってソフトウェアの開発も比較的短くすることが出来ます。
ジョシュアツリーの法則
チームの共通言語を作り、使用していきましょう。
チームの言っていることが、例えばスマートフォンであれば「iPhone」「アンドロイド」「スマホ」「携帯」など様々な言葉でスマートフォンを説明されると、混乱をきたします。
こういったように、チーム内でよく使用する単語などは共通化し、コミュニケーションを円滑に進むようにしましょう。
ヤクの毛刈り
問題の本質を見極めます。
問題というのは芋づる式で出てきます。
〇〇が動かない -> ライブラリを入れてない -> バージョンが古くて入れられない -> OSのアップデート -> 〇〇がOSに対応していないので動かない
という風に、問題を芋づる式に解決していこうとすると、問題の本質を解決出来ず、時間だけが浪費していきます。
こうなった場合には早々に切り上げましょう。別のツールで動くかもしれませんし、互換性のあるライブラリがあるかもしれません。
もし、問題に立ち向かう場合は、一つ一つ丁寧に精査していくことです。今行った作業はなんなのか、作業をしたことで何が解決して何が問題になったのかを、書き留めたりしながら一歩づつ行うことで、やがて問題の本質が見極められます。