プログラマーの方に質問です。


あなたにとって良いプログラムとは何でしょうか?

信頼性、可読性、効率性、拡張性など様々な視点がありますが
最も重視しているポイントとそれを書く時に気をつけてる事。コツみたいなものを教えてください。

回答の条件
  • 1人2回まで
  • 登録:2009/03/30 12:15:54
  • 終了:2009/04/06 12:20:13

回答(9件)

id:hijk05 No.1

hijk05回答回数1307ベストアンサー獲得回数232009/03/30 13:19:24

ポイント16pt

1.可読性

 誰が読んでもわかる書き方

2.エラーが検出できること

 エラーが起こったときに、原因が判明できること

3.仕様変更に耐えれること

 ある程度の仕様変更があっても、変更箇所が一部分ですむようになってること


あしたをつかめ 平成若者仕事図鑑 プログラマー 誰でも使えるシステムを作れ [DVD]
教育
B000FA4WRW

id:jar2

ありがとうございます。

出来ればもう少し具体的に

何故それが重要だと思うのかとそれを実現する為のコツみたいなものをご教示いただければ幸いです

お願い致します。

2009/03/30 14:49:15
id:TAK_TAK No.2

tak回答回数970ベストアンサー獲得回数792009/03/30 15:03:50

ポイント16pt

個人的な回答でいいなら、"よい"プログラムの一番の条件は「独立性」です


そのプログラムを使用するために他のモジュールなどを要求せず、

他のモジュールの仕様変更の影響を受けないことです。



現実的には、

仕様変更などが生じるとシステム全体が影響を受けたり、あるプログラムのある一部だけ使いたいのに、

他も全部必要になるということは多いので、こういうことはなくしたいのです。

id:jar2

分かりやすい解説ありがとうございます。

独立性が担保されてるとたしかに仕様変更にも対応しやすいですね。

2009/03/30 15:27:13
id:frkw2004 No.3

ふるるP回答回数192ベストアンサー獲得回数212009/03/30 17:40:20

ポイント16pt

可読性。

読めなければ始まらない。

また、プログラムに書かれていることが全て理解できれば、その他のことは付随して可能になる。

読みやすくするためにプログラム言語は発達している、といえるでしょう。

id:jar2

可読性でモジュールの粒度やメンテナンス性が向上する。

たしかにその通りだと思いました。

コメント欄への追記もありがとうございます。

2009/03/31 18:29:43
id:pahoo No.4

pahoo回答回数5960ベストアンサー獲得回数6332009/03/30 18:46:23

ポイント16pt

標準化ルールに則っているもの


会社単位で、またはプロジェクト単位で、チーム開発のための標準コーディングルールやコーディングガイドラインがあるはずです。それに沿って書かれているプログラムが良いプログラムです。

それ以外の(悪い)プログラムは、受け入れ試験をパスできません。


標準化ルールに従えば、信頼性、可読性、効率性、拡張性などの要件はすべて満たすはずです。

逆に、そういう標準化ルールが無いのであれば、プログラムをつくるまえに、標準化を策定します。


たとえば‥‥

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)

  • 作者: ハーブ サッター アンドレイ アレキサンドレスク 浜田 光之
  • 出版社/メーカー: ピアソンエデュケーション
  • メディア: 単行本

id:jar2

たしかに大きな組織で開発する場合は標準化が必要になってきます。

どこまで細かく標準化して、どこまでを個人の裁量に任せるかはバランスだと思いますが

標準化も重要な評価指標ですね。

ありがとうございます。

2009/03/31 18:32:54
id:dev_zer0 No.5

dev_zer0回答回数332ベストアンサー獲得回数252009/03/30 18:52:23

ポイント16pt

google君に「良いプログラム」と聞くと色々出てきますが

商用のプログラムで重要なことは

 ・仕様どおりに書かれていること

 ・テストがしやすい作りであること

 ・適度なログが入っていること

です


自分が楽したい為に作るような使い捨てのスクリプトなどとは違い、

お金が絡んでくるプログラムはいきなりソースコードを書くことはありません

仕様書・設計書などのドキュメントがまず作られて、それを元にしてプログラムは作成されます

# 火を噴いたプロジェクトだといきなりソースを作って、納品時に設計書を書く場合もありますが

# 本来はドキュメントを作ってからソースは作るべきです。

大きなシステムの場合は複数のプログラムが組み合わさっているので

いきなりソースを追うのは手間がかかり、ドキュメントからソースを追いかけるのが定石です。


また、作ったプログラムはテストする必要があります。

関数やメソッドがやけに長かったり、クラスに色々な責任を持たせたり、

引数が複雑怪奇だとテストに非常に苦労し、そもそも結果の確認も面倒になります。

テストしやすいプログラムは必然的にある程度の粒度になり、

各モジュール間の結合度が低くなる可能性が高いです。


実際システムが稼動すると何らかのトラブルが発生します。

そのトラブルがハードなのかソフトなのか、ソフトならば自分のシステムがおかしいのか

他人のシステムがおかしいのかのトラブルの切り分けを迅速かつ確実に行う必要があり、

その手がかりは多くの場合はログになります。

そして、自分のシステムがおかしい場合、ログからソース解析に入ることになります。


ぶっちゃけ、自然言語と同じでたくさん書いて、たくさん読んでみないと

良い文章、悪い文章はわかりません。

自分が小学生の頃の作文は今読み返すと未熟であるように、

私が新人の頃に作ったプログラムは赤面モノです。

たくさんプログラムを読み書きしていると自然とコツがわかってきます

id:jar2

文章と同じでたくさん書いて、たくさん読むというのは良いですね。

プログラマー教育の体制を作って、あとは裁量に任せるというふうに理解しました。

ありがとうございます。

2009/03/31 18:35:07
id:hijk05 No.6

hijk05回答回数1307ベストアンサー獲得回数232009/03/30 23:07:34

ポイント15pt

>何故それが重要だと思うのかとそれを実現する為のコツみたいなものをご教示いただければ幸いです

>標準化ルールに則っているもの。

標準化ルールに沿うだけのプログラムは、新人さんでもかけます。

でも、よいプログラムである確率は低いです。

標準化ルールというのは、たとえば日本語は標準語を使いましょうということです。

プログラムというのは標準語で書かれていたらよいプログラムではなくて、話す内容が優れてるかどうかにあるからです。

>標準化ルールに従えば、信頼性、可読性、効率性、拡張性などの要件はすべて満たすはずです。

満たせません。1000pt賭けてもよいです。

id:jar2

標準化ルールがダメなものであれば要件は満たさないということでしょうか?

2009/03/31 18:38:47
id:yasuho No.7

yasuho回答回数7ベストアンサー獲得回数02009/03/30 23:49:26

ポイント15pt

バランスのいいプログラム。

要求される機能や実行されるマシン環境において、ユーザの求める機能が過不足なく実装されていて、適切なパフォーマンスで実行できるプログラムは、良いプログラムであると思う。

言い換えれば、使っていて心地よいプログラム、とでも言うかな。


振る舞いが首尾一貫しているプログラム。

ある一定のポリシーや設計思想で作られたプログラムは何かをした時のアクションが想像しやすく、ユーザに安心感と信頼を与える。

これが出来ていないプログラムほど不安なものはない。


上記が達成できているのであれば、それは読みやすく信頼性の高いプログラムになっているはずだ。


もちろん不意なデータ入力でもクラッシュしない堅固性があることは言うまでもない。

id:jar2

たしかにバランスは重要な視点ですね。

設計思想があって結果が予想しやすいプログラムは、細かいところまで読む必要がないので安心できます。

ありがとうございます

2009/03/31 18:42:42
id:Kityo No.8

キチョー id:Kityo回答回数159ベストアンサー獲得回数122009/03/31 13:46:49

ポイント15pt

 現役プログラマーです。

 信頼性、可読性、効率性、拡張性…(学問としては確か7つある)のどれとも絡みますが、シンプルなこと・簡単で分かりやすいこと…でしょうか?

 バグを回避する最良の方法はプログラムを書こうとしないことですが、僕の職業の場合は原則として書かないとメシのタネになりません。

 楽勝だと思って書いたものでさえしばしばバグを含むのですから、難しいと感じて苦労して書いたものがバグを含まない筈がありません。シンプルで分かりやすいものを書くべきだと考えています。

 1関数は10ステップ以内、制御構造は出来れば1関数に1つ以内にする、少なくとも関数単体では新人さんが読めないような難しいものを書かない…簡単でシンプルで間違えようもなさそうな部品の組み合わせで全体を構成するようにする…と言うことを心掛けて、100点満点中80点くらい実践しています。


 実行コードに直接反映される部分ではないですが、コメントは非常に重要です。嘘を書かないようにすること、分かり易く書くこと、他の場所(設計書やヘッダファイルなど)に書いてある内容に対して正確な参照先を示すこと…などを、コメントを書くときに重視しています。


 最終的な結果に対して重要かどうか分かりませんが、個人的には次のようなことも心掛けています。

  • コメントを先に書き、実コードはその後に書く
  • 関数1つ書き終えたら、コンパイル確認する
  • 出来れば、関数テストも1つ書き終えるごとに行う
  • 手元でテストしてない関数については、その旨コメントする
  • その他保留事項等は、決まったマークをつけてコメントする
  • コメントは、後で読むヒトのために書く


 他人に見直しをして貰う(レビューを受ける)ことは、最終的な結果に対して重要です。←これが一番重要かも知れません。

id:kazuki_t No.9

kazuki_t回答回数5ベストアンサー獲得回数02009/04/02 01:53:13

ポイント15pt

そのプログラムの商売の仕方によって結構変わると思います。

データベースのようなミドルウェアを作っていたときは、10年以上保守しなきゃいけなかったりするので保守性・拡張性を考えられているか、結構慎重に設計します。

ウェブサービスを作っていたときは、速くコーディングできるのが良いプログラム。いろんな要望に応えてどんどん作っていって、ごちゃごちゃになってきたところで再構築。

一般則としては、機能や処理を如何にわかりやすく整理して分割していくか、に気をつかう…かな。

  • id:frkw2004
    ちょっと追加します。

    モジュールの粒度とか、メンテナンス性とかテストしやすさとかありますが、それらは全て、可読性にかかっています。

    文章と同じです。
    句読点の少ない文章(スパゲッティコードです)は読みづらいし、適当なところで段落が必要だし(適当なサイズのモジュール化)。

    適当な長さで、適当な意味合いで一塊として理解できる部分でモジュール化する。
    きちんと理解できる範囲でモジュールされていると、テストも分かりやすくなります。

    ただし、文章と同じで、いい文章でも読み手の力量によって、読みやすい/読みにくい、というのがあります。コンパイラ相手ならいくら難しい計算方法でもかまいませんが、ソースをメンテナンスするプログラマがアルゴリズムを理解できない、というのは別な問題です。
    それはプログラマが精進しなければいけないことでしょう。

  • id:Kityo
     自分も1つ追加します。
     コーディングの作業の大部分(持論では7割がた)は「名前を決めることである」ことを意識して、それに注力します。
     関数名、変数名、ファイル名などなどに、内容に見合った分かりやすい綴りを使うように心掛けます。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません