人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

●質問者: jar2
●カテゴリ:コンピュータ インターネット
✍キーワード:あなた プログラマー プログラム ポイント 拡張
○ 状態 :終了
└ 回答数 : 9/9件

▽最新の回答へ

1 ● hijk05
●16ポイント

1.可読性

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

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

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

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

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


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

◎質問者からの返答

ありがとうございます。

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

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

お願い致します。


2 ● tak
●16ポイント

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


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

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



現実的には、

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

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

◎質問者からの返答

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

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


3 ● ふるるP
●16ポイント

可読性。

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

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

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

◎質問者からの返答

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

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

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


4 ● pahoo
●16ポイント

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


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

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


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

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


たとえば‥‥

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

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

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

◎質問者からの返答

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

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

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

ありがとうございます。


5 ● dev_zer0
●16ポイント

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

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

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

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

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

です


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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

◎質問者からの返答

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

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

ありがとうございます。


1-5件表示/9件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ