良いプログラムを書くためには

質問

今回、プログラミングの上達方法に関してアドバイス頂きたく質問しました。
現在、ソフトウェア開発の仕事に就いていてCやJavaなどでプログラムを書いたりしています。主にCで書くことが多いです。与えられた課題に対して動くプログラムは作れるのですが、先輩などからプログラムが汚いとよく指摘されます。
指摘される事柄は色々ありますが、何点か挙げるとまずモジュール分割が上手く出来ていない。1000行位の動くプログラムを書き始められた頃は、共通の処理などの関数が分割されておらず、同じ処理がやたら多いなど、余計な処理が多くコードに無駄が多いと指摘されました。それを改善したところ、今度は無駄に関数の分割が多くなり、読みにくいなどの指摘を受けました。
その他にも、例えば関数の中で、for(条件式)の条件式を上手く工夫すれば、for()の中で、余計な条件分岐などが減るなどの、細かい記述に関しても指摘を受けます。

質問はプログラムを作成する上で、大きな観点からだと、どのようにすれば綺麗にモジュール化などが出来るのか、モジュール化だけではなく、ソフトウェアの設計全般に関してです。また細かいことで、いえば先ほどのfor()の様に、文法を上手く使いこなすためにはどうすればよいか。本などのサンプルコードでは、forならfor、ifならifの説明など、主に単独の説明が多いように思えます。関数の中で、各文法同士を上手く使いこなし、他人が見ても読みやすいコードなどを書きたいです。
先輩からは、他人のソースコードを見ることなどと言われますが、何か他人のソースコードを見る上でも、上で挙げた指摘を改善するための見方とか、他にも自分でプログラムを作る場合に、こういう事に注意しながら作るといいなど何か改善するアドバイスがあれば宜しくお願いします。また参考になる書籍やサイトなどもあったら教えて頂くと助かります。
長くなりましたが宜しくお願いします。

回答No.6

noname#88772 · ベストアンサー

こんにちは。

問題の解決についてプログラミングを行うにあたって以下の流れを通ります。
[読解] → [処理の分解] → [コーディング]

質問者さんはコーディングについての上達を目標とされているようですが、
プログラミング自体の上達にあたり、
上の流れの [読解]→[処理の分解] を鍛えることをお勧めします。
これはプログラム設計にあたります。

コーディング自体を鍛えると小手先のテクニックに凝ってしまいがちになります。
プログラムの全体を捉えることが重要です。

各流れは以下のようになります。

読解：
以下のことをハッキリさせる
　・問題を解決するために必要とされるアウトプットは何か
　・問題を解決するにはどのようなもの（データ等）が必要か

処理の分解：
以下の順序で処理を細かくしていきます。
　１．問題解決の大まかな処理の流れを考える
　２．処理を実現するにはどのような処理の流れに分解すればいいか考える
　３．分解した処理について２．の処理を繰り返し、他人でも簡単に解るレベルまで噛み砕く
この段階で同じ処理が出てきたりしますので一つの関数にまとめたりできます。

コーディング：
　・分解した処理を各言語に変換する

後参考に、コーディングについて私の場合はこうします
・各関数は１００行程度に収めます
・main() では処理の項目の一覧を書く程度、または一関数のみにしています
・必要と思われるコメントは必ず入れます
・各関数の先頭コメントには用途、入力、出力、返り値を書きます
・他の人が見ても解るよう、可読性を重視して書きます
・各関数は他のプログラムにも応用できるように書きます

ご参考までに。

お礼

コーディングを行う前の設計が重要だということは解っていま
したが、ではどういう風に考えていけばよいのか。という点が
曖昧でした。

よってyuji_syamiさんが教えて頂いた段取りの方法はとても参
考になります。この方法で設計を仕上げて、コーディングに入
る。
そういうプログラム作りに変えてみます。

ありがとうございました。

回答No.5

choconamacream

Javaなどのオブジェクト指向系で言ったら、「デザインパターン」ですね。クラス名、メソッド名などの命名規則なども含めて、デザインパターンの本に記載されているコードを参考にしていけば、まず外れることはないでしょう。もっとも、「デザインパターン」もまた万能のツールではないのですが、それを否定する人は余程のベテラン設計者でもない限りいないはずです。（それこそ、オブジェクト指向設計者さん達の試行錯誤による集大成とも言うべき代物ですから。）

>関数の中で、各文法同士を上手く使いこなし、他人が見ても読みやすいコードなどを書きたいです。

ただ、上記のようにもおっしゃっていることから、「データ構造とアルゴリズム」に関しても一通り体系的に理解しておくことが必要であるように思われます。

>先輩からは、他人のソースコードを見ることなどと言われますが、何か他人のソースコードを見る上でも、上で挙げた指摘を改善するための見方とか、他にも自分でプログラムを作る場合に、こういう事に注意しながら作るといいなど何か改善するアドバイスがあれば宜しくお願いします。

Cなどで言ったら、Linuxカーネルとか、ネット上に転がっている大規模のオープンソースソフトウェアでしょうか？（ブラウザとか。）

ただ、質問者さんの場合はもう既に実務に入られているわけですから、一番に参考にすべきは「同じ開発チーム内の先輩方のソースコード」だと思います。ちなみに、どの先輩方を参考にするかは以下を元にしてください。

・よく指摘を受ける先輩（→自分を否定することになるので、あまりとやかくは言われなくなると思います。）
・その業務に長年携わっている先輩（→ベテランの方ですから、なぜそのようなコードにしているのかなど、ちゃんと理由を持っているはずです。）
・机の上がいつも綺麗な先輩（→几帳面さは、ソースコードにも現れます。）

お礼

Javaでプログラムを組むこともあるのですが、胸を張って
オブジェクト指向を使いこなせているとは言えません。
アドバイスの通り、オブジェクト指向も勉強し直します。

社内で、先輩のソースコードを参考にする際のアドバイス
も参考になります。
ありがとうございました。

回答No.4

don_go

質問の文章はgusu123さんの先輩の方々から指摘されている
のと全く同じ理由で、とても読みづらい印象を受けます。

改行が少ない文章は、区切れがどこに有るかを解り難くし
それだけでも読みづらい印象を与えます。
同じ語句の繰り返しと論点のまとまりのなさは、理解を
妨げると共に、読む気を失わせる原因にもなります。

自分が質問を受ける立場になった時に、読みやすいと感じる
かどうか？
もしも、自身が読みづらいと感じるようであれば、他の人に
とってもやはり読みづらいと思って下さい。
単に、思い付くまま単語を並べるだけではなく、何度も読み
返し推敲する事を日常的に試みる様にして下さい。
やがては読み易い文章を短時間で書ける様になります。
＃プログラムを作成する場合も同様です。

先輩からいろいろ指摘を受けていて、改善してみても別の事を
指摘されるとの事ですが、不具合の方向が真逆の両端をいったり
きたりして、改悪を繰り返しているだけです。
本や他人のソース等を見て、多すぎたり少なすぎたりしない
様にいろいろと試行錯誤をして適当な所を探し出して下さい。

人間が楽に認識できるのは画面上で上下に１画面分スクロール
するぐらいの範囲内といった話もあります。
モジュールの大きさを決める際の参考の１つにしてみては？

また、数年後の自分は他人と同じという気持ちでプログラム
を書く事が必要です。
＃自分自身で数年前に作成したプログラムであっても、他人
＃が書いた物の様に感じる事は良くあります。

お礼

ご指摘ありがとうございます。

確かに、私の文章と比べて、don_goさんの文章は、一瞬見ただけで、
読みやすいと思わせてくれます。
文章、プログラムともに人に見せる前に、自分自身が本当に読みに
くくないか。
何度も推敲する様に心掛けます。

指摘して頂いた当り前の事が、プログラムや文章を上達させるコツ
でもあると感じました。
当り前のことが、まず出来ていない点も指摘して頂き、参考になり
ました。
ありがとうございました。

回答No.3

R32C

古い本ですが、Myers本のひとつですが、「ソフトウエアの複合・構造化設計」
を入手可能ならお勧めします。
オブジェクト指向どころかC言語すらメジャーでなかったころの本ですが、
モジュール分割に関して、強度、結合度というものさしを用いてモジュールの
分割方法について、説明しています。

お礼

モジュールを分割することは、プログラムのロジックを考える過程でもかなり大きな悩みとなっています。
紹介してもらった本で、モジュールの分割を体系的に学べそうなので読んでみようと思います。
ありがとうございました。

回答No.2

noname#259269

とりあえず「Cプログラミング診断室」という書籍を推奨しておきます。
http://www.pro.or.jp/~fuji/mybooks/cdiag/

頑張ってください。

お礼

紹介してもらったサイトを一部見させてもらいました。ソースコードがあり、悪い点を修正して学習する形態となっているようですね。
人のソースコードをあまり見たことが無かったのですが、こういう書き方だと汚いソースコードになるのかと思いました。
さらに改善策も紹介されているようなので、大変参考になります。
さらに読んでいきます。ありがとうございました。

回答No.1

tgook

一応、ソフトウェア設計を仕事やプライベートでやっている者です。
参考になるかは分かりませんが、
私はソフトウェアを作成する時、いきなりコードを書くのではなく、
最初は紙に以下のようなことを箇条書きに書きます。
(1)どういう動きをするものを作るのか？
(2)インプットは何？
(3)アウトプットは何？
(4) (2)から(3)を得るにはどういう処理が必要？
-> その処理の中に共通の動きをするものはある？
(あればリユース可能にする)
-> 関数化を検討
(関数は処理の内容ごとに分類。関数内の処理も一連の流れを決めて、その流れを守って作る。)
(5)デバッグ

あとは、コーディングやって、単体テストや結合テストなどをします。

コーディング作業は、やっぱり見易さを重要視して作業します。
(特にTabキーによるインデントや一行空けるなど。コメントも分かりやすく簡単に1行にまとめる。)

こんな感じです。
何が正解かはやってみないと分かりません。
ただし、私でも1つだけ言えるのは、どんなソフトウェアを作るときでも、それは仕様書で決められている通りの、正しい動作をするものでなければならないということです。
納期やコストも大切ですが、上記に関しては手を抜いてはいけません。

お礼

プログラムを書く前に、大まかにプログラムの構成などは紙に書きますが、tgookさんが行っているような手順は踏んでいませんでした。
これからプログラムを書く前には、アドバイスを頂いた手順も参考にして作っていきます。ありがとうございました。