noob log.

組み込みSE兼プログラマの備忘録。

プログラマが知るべき97のこと まとめ 14

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

7.不具合にテストを書いて立ち向かう
不具合の対応策として、テスト駆動開発があります。
不具合の対応時には、必ず不具合を再現するテストコードを書いてから対応するとよいでしょう。
まず、不具合を再現し、バグの最小範囲を絞り込み、不具合が修正されたら通るテストコードを書きます。
その後、テストが不合格となることを確認し、修正し、再度テストを行います。
最後に、既存のテスト全てを実行し、他の部分を壊していないことを確認します。
この手順を踏むことで、バグ範囲の推測が合っているか明らかになります。
また、自分の弱点、気づきにくい点が分かります。
自動テストにしておけば、今後不具合が再発しても、テストが不合格となることですぐにわかります。
時間がかかるように感じますが、再発防止などいろいろな点を考えると、不具合にテストを書いて立ち向かうことは合理的で効率的な方法なのです。

 

10.名前重要
適切な名前を付けられるということは、その機能が正しく理解され、設計されているということである。
逆にふさわしい名前が付けられない場合、その機能が果たすべき役割を設計者自信も十分理解できていないということではないだろうか。
ソフトウェアの設計のアプローチとして、「まず名前から入る」というのは、あまり語られていない秘訣としてもっと広く知られてもよいように思います。

 

以上です。

自分の信条に近いもの、これからを考える上で非常に役に立つ助言が多く、ためになる本でした。

あなたも1冊、お手元にいかがですか?

プログラマが知るべき97のこと まとめ 13

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

97.ステートに注目する
ステート(状態)を厳密に管理しなければ、冗長なコードができてしまいます。
状態遷移図・表を作成しつつ開発することで、ステートが曖昧なコードができることを防げます。
ステートに注目して考えれば、コードをよりシンプルに、そして堅牢にすることに繋がります。

 

・日本人編
1.命を吹き込む魔法
プロジェクトにコードネームが無ければ、愛することはできません。
コードネームは命名の便宜だけに使うものではなく、チームをまとめるシンボルになります。
コードネームには、名前の由来が具体的で、身近なものを選びましょう。
コードネームはチームを結束する秘密の合言葉であり、姿の見えないソフトウェアに命を吹き込む魔法なのです。

 

2.ロールプレイングゲーム
「理想のプログラマ」になるために、本来の自分の性格、信念と衝突してしまうことも少なくないでしょう。
そういう時には、「理想のプログラマ」をロールプレイするのです。
「理想のプログラマ」ならどう振る舞うだろう、この問題はどう解決するだろうと常に考え、演じます。
しかし、演じなければならないのは「あなたのチームの理想のプログラマ」であることを忘れないでください。
勤務時間中は「理想のプログラマ」を演じてみましょう。本来の自分を変えるよりずっと簡単です。

 

4.プログラマが持つべき3つのスキル
プログラマが持つべきスキルを3つ挙げるとすれば、コードを読むスキル、テストをするスキル、デバッグをするスキルです。
これらのスキルは知識の獲得とは違い、実際に手を動かすことでしか身に着けることはできません。
身に着けるには、OSSのプロジェクトに参加することが良いでしょう。
フォーラムやメーリングリストで議論されているバグを修正してみることで、上記3つのスキルをバランスよく身に着けることができます。
いくつかバグフィックスをしていけば、スキル向上だけではなく、コミュニティにも受け入れられていくことでしょう。

 

5.快適な環境を追求する
プログラマは一生のうち、かなりの時間をコーディングに費やします。
快適な環境を追及することで、コーディングするための時間をより快適に過ごすことができ、一生のうち、かなりの時間が快適になります。
ちょっとした時間の投資は必要になりますが、それに見合った効果を得られるはずです。

プログラマが知るべき97のこと まとめ 12

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

88.コードは生涯サポートするつもりで書く
気持ちの持ち方、取り組む態度を変えるには、「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書くことがコツです。
これまでに書いてきたコードは、どんなものであっても、必ず今の自分の仕事に影響を与えています。
書かれたコードを見て、書いた人がどういう人か評価するので、常によくないコードを書いていれば、キャリアアップのチャンスも自然と失われていきます。
コードを書くときは、このコードは自分の今後の人生を決めると思って書くべきです。

 

91.良いプログラマになるには
良いコードは偶然できるものではなく、知識も経験もあるプログラマが最大限心を配って書いた時に生まれるものです。
良いプログラマになりたければ、常に次のことを心掛ける必要があるでしょう。
・「とりあえず動きそう」なコードは書かない。誰が見ても間違いなく正しいと分かるコードを書く。
・わかりやすく、保守しやすく、正しいコードを書く。本当に正しいかどうかはあらゆる手段を使って確認する。
・常に他のプログラマの存在を意識し、チーム全体の成果を最良にすることを考える。
・自分が扱ったコードは、最初に見たときより少しでも良いコードにする。
・絶えず新しいことを学ぶ。ただし、学んだことをむやみに使わず、適切と判断した場合にのみ使う。

 

92.顧客の言葉はそのまま受け取らない
顧客は、自分の希望をよく理解していないまま話す場合がある為、話されたことを鵜呑みにしてはいけない。
顧客に対し、早い段階から頻繁に質問を投げかけたり、何度も話しあうことで本当に欲しいものを理解することができる。
また、同じことを複数の人と話し合うことも有効です。
全く無関係だと思っていたことが実はつながっていたり、発言が矛盾することも珍しくありません。
開発するソフトウェアが複雑であるほど、このようなことは発生しやすくなります。
図や絵、画面のモックアップ、プロトタイプを作ってみるのも有効です。

 

93.エラーを無視するな
エラーを無視していては、いいコードは絶対に書けません。
コードからエラーを通知するには、以下の方法を試すといいでしょう。
・戻り値を使う。正しく実行されなかったときにはそのことを示す値を返すようにしておく。
・errnoを使用する。
・例外を使用する。例外を無視していてはいけない。
エラーを放置していると、不安定で、セキュリティ上問題があり、貧弱な構造とIFを備えたコードができてしまいます。
エラーチェックは屁理屈をこねず、必ず行い、エラーを適切に処置すべきです。

 

96.テストは正確に、具体的に
ユニットテストでは、動作が本来の要求に沿っているかを確認しますが、それを言い訳にテストが曖昧になってはいけません。
テストコードを単純にして理解しやすくするには、具体例を使うことが有効です。
テスト結果を1つ例として出し、それ以外の結果は全て正しくないとすることで、簡潔になります。
動きについての記述はただ正確なだけではなく、誤解の余地のないものにしなくてはなりません。

created by Randy_Hoo.