プログラミングを行う上での注意点は？

こんにちは。私は昨年4月からSEとして採用された22歳（♀）です。
現在は下積みとして、ひたすらプログラミングをする毎日です。
プログラミング自体は嫌いではなく、
自分の作ったものが思い通りに動いたときは"、やっててよかった"、と達成感で満たされます。
ただ、まだまだ経験が浅いこともあり、
設計書をもらっても何から手をつけてよいかわからず、

(1)とりあえず書いてみる
(2)バグだらけ
(3)先輩の手を煩わせてしまう

という悪循環に陥りかけています。
"もっと全体像を見ないとダメ""書けても動かないと意味がない"と
先輩からご指導いただいているのですが、
いったん作業に入ると、目先のことにとらわれうまくいきません。
そもそもアルゴリズムが苦手で、
効率のよいプログラムが組めない、という問題もあるのですが…。

そこで、皆さんがプログラミングを行う前、
あるいは最中に必ずされていること、心がけていることはなんでしょうか？
4月からは2年目に突入しますし、
7月から後輩が入ってくることも確定しています。
正直、先輩に頼れるのも今のうち、と焦っています。

現役プログラマーのかた、
あるは趣味でプログラミングをされているかた、どなたでもかまいません。
どうかご教授ください。

No.8 回答者： drg75 回答日時： 2009/02/13 07:27

以下を気をつけていれば大丈夫だと思います。

1.提出前にソース見直し
2.作りながら仕様書と合っているか確認
3.可読性を損なわない程度にコメントを多めに記述

土木建築と同じで安全確認を怠らないようにしましょう。

No.7 回答者： materi2 回答日時： 2009/02/01 08:33

おはようございます。

私が試用期間の頃よく言われたことです。
ただ動いて終わりでは駄目です。
私もループの中をどう書いていこうとか、if文をどう書こうかと
目先のことにとらわれがちでしたが処理全体の流れが頭に入ってないと駄目です。
また、変数も何に使う変数なのか頭に入ってないと駄目です。
あいまいな所にバグの可能性があります。

No.6 回答者： hisappy 回答日時： 2009/02/01 00:25

他の方の意見を否定するつもりではありませんが

逆向きな方向での回答をしてみたいと思います。
現状のやり方をもとにしての注意点と考えてもらえればと思います。

結局のところ、「バグだらけ」なのは
「とりあえず書いてみる」したものが不十分だったから。
ということになってしまいます。
では今の「とりあえず書いてみる」をどう変えていくかが鍵となります。

これを「とりあえず"全部"書いてみる」としてみてはどうでしょう。
・与えられた書類から読み取れる事は何か。
・書類で分からない点は何か。
・プログラミングの段階ならまず通常の処理は期待通り実行されるか。
・ループや条件分岐の判定は何が発生するか。→エラー処理対応へと展開できる。
・他の部分と連携や影響を与えたりするような部分はないか。
などなど。

言葉変えてみましょう。
・どう動くべきなのか。（正常パターン）
・そこでどんな条件がかかわってくるか。（判定系統）
・そこに怪しい条件やデータがついてきたらどうするか。（エラー系統）
・それらの仕様に関して、自分はどこまで理解できているか、
　不明点は何か、おかしいと感じた点は何か。

をとことん書き出すようにすれば
次の「どう整理されたらやりやすくなるか」ができ……るといいんですが。
なかなか書き出しみたらきりがなくなってきて
余計に手に負えない状況になる危険性もあります。

でも何か基盤となる点を押さえておかないと
次の改善点にはつながりません。

例えばプログラミングでも、
「正常ケースが動くものをつくってしまって
その後に粗探しをしてエラーケース対応の処理をいれる。」
というのも一つの手ですが、その場合でも
「どこのデータがどう関わって、どの条件とどんな時に・・・」
というのが自分なりにでも整理されてないと
『そもそもこれが正常ケースで動けているのか？』
ということになりますので、
まずは自分がその仕様書をどれだけ分かっているのかを確認してみてはどうでしょう？

No.5 回答者： swallow10 回答日時： 2009/01/31 22:56

設計書の粒度にもよりますが、その設計書がプログラミング仕様書などと呼ばれる、プログラムを日本語化したような設計書ではない限り、まず書いてみるはしない・できない、と思います。

まずは、設計書をみっちり読む。
類似の処理が他の機能にあり、そこのソースが完成してれば、それを見せてもらう。
全体の流れを把握し、共通化できる箇所があれば切り出し、インターフェースを固める。迷ったら、類似の機能と統一を図る。

最初のうちは、「書く」というより「コピペする」といった感じでコーディングすると、勉強にもなりますし、強いモジュールができると思いますよ。

No.4 回答者： arain 回答日時： 2009/01/31 15:46

No.2です。

少し追記します。

>こんにちは。私は昨年4月からSEとして採用された22歳（♀）です。
とあり、
>設計書をもらっても何から手をつけてよいかわからず、
さて、SEなら知っておくべき（知っていて当然の）ことですが、質問での「設計書」とは
ａ．概要設計書
ｂ．基本設計書
ｃ．機能設計書
ｄ．詳細設計書
ｅ．単体試験設計書
ｆ．結合試験設計書
ｇ．総合試験設計書
ｈ．その他設計書
のいずれでしょうか？

「設計書」が「仕様書」であったり、ａ／ｂ、ｂ／ｃ、ｃ／ｄ、ｆ／ｇについては、
それぞれ企業によりニュアンスが同じであったり違ったるする場合もありますが、
少なくとも、
大雑把な概要（こんなものを作りたい）という設計
　↓
作るために必要な機能や使用するデータ等の洗い出し
　↓
機能を実現するための詳細な検討
という流れは同じです。
渡された設計書によっては、その下の仕様書について設計する必要もあります。
この時点で問題があれば、さらに上の設計書について再検討する必要があります。
この「設計／検討」を行わずに
>(1)とりあえず書いてみる
だと、
>(2)バグだらけ

また、「プログラムのための設計書」には、「デバッグのための設計書」が対になって存在します。
××と設計した
　↓　
だから、○○と△△について試験しないといけない
となります。

例えばＣ言語で、引数一つと戻り値がある関数を設計したと仮定します。
その場合、
・引数の妥当性（関数で利用できる範囲内か、不正値だったらどうするか）
・戻り値の正当性（正常、異常などで適切な値を返しているか）
といった試験が必要になります。
「機能」を実現するには「複数の関数を組み合わせて」実現する場合がおおくあります。
ここで、「関数の試験」をすっ飛ばして「機能の試験」を行った場合、どれだけ厄介なことになるかについては、説明するまでもないと思います。

No.3 回答者： singlecat 回答日時： 2009/01/31 14:58

みなさん仰ってますが、「とりあえず書いてみる」はダメです。

仕様書は処理のポイントが書いてあるだけですから、
それを具体化する仕事がプログラミングです。

変な例ですが、建物に例えると
１Ｆに玄関と応接間、２Ｆにキッチンとリビング、３Ｆに子供部屋....
という要望書があった場合に、敷地の図面も見ずいきなり子供部屋の設計をするのか...という事です。
まず、資料全てに目を通して、頭の中でイメージを興し、必要な部分はフローチャートやユースケース図などで具体化してから作業に取りかかってください。

No.2 回答者： arain 回答日時： 2009/01/31 14:47

>(1)とりあえず書いてみる

は絶対にしない。

>設計書をもらっても何から手をつけてよいかわからず、
設計書を「熟読」する。
この際に、
・分からないことはそのままにしない。恥と思わず質問する
・自分の「理解」が正しいか、他の人に確認してもらう
・「頭の中だけ」で考えない。必ず必要やしょりや手順（手書きでも何でもいいので）を書き出してみる。

>(2)バグだらけ
は内容を理解していないから発生する最たるもの。

プログラムとしては
・条件分岐がある場合、「条件と一致しない場合」について問題ないか
・ループ処理のループ条件は本当に大丈夫か
・「なんの処理を行っている（行っているつもり）」なのかコメントはしっかりとつける

No.1 回答者： number44 回答日時： 2009/01/31 14:42

「とりあえず書く」から始めてはダメです．

まずは簡単なフローチャートのようなものを書いてみた方がいいと思います．
一度どのような流れで全体が動くのかということを明確にしてから，詳細をつめていき，それが終わってから書き始めます．

プログラミングに慣れてしまえば特にフローチャートを意識しなくても書けるようになりますが，多くの経験が必要です．

また，チェックポイントを作りながらプログラミングした方がいいですよ．プログラムを処理ごとに分割して，処理結果が正しく出ているかをそのつどprintなどで確認するクセをつけておけば無駄なバグは減ります．