アプリ版:「スタンプのみでお礼する」機能のリリースについて

他の人が作ったC#のプログラムを理解し、改良して自分のプログラムを作ろうとしていますが、なんかよくわからないです。
(まだDelphiとかC++だったらわかる気がするんですが)
作った人には聞けないです。
なんかいい方法とか、コツってありませんか?
漠然とした質問ですみませんが、答えていただけたら嬉しいです・

質問者からの補足コメント

  • つらい・・・

    回答ありがとうございます。
    「仮定を作って...」ですか...
    ま、やるしかないですね。
    やってみます。

    No.1の回答に寄せられた補足コメントです。 補足日時:2016/09/18 09:18
  • つらい・・・

    回答ありがとうございます。

    >「C#が、新しい概念を取り込んで作られた次世代の言語です。」
    ビジターパターンというのが使われています。
    (これはなんとなくわかったのですが)
    >C#の文法が理解できていない(よく分からない命令がある)のなら、C#の勉強をするのが良いと思います。

    > でも、C#の文法を知っていて、1つ1つのコードが何をやっているのか分かるのに、全体としてコードが何やっているのか理解できないなら、コードをながめて考え続けるしかない気がします。
    とりあえず、コードを眺めてみます。

    No.2の回答に寄せられた補足コメントです。 補足日時:2016/09/18 09:22

A 回答 (5件)

No.2です。



他の回答にありますが、プログラムの全体的な動きは、こんなアルゴリズムで動作しているのでは?という「仮定を作って」全体像の把握ってのは大切だと思います。
また、ソースコードを見ただけでは、全体像が得られないこともあるので、入手可能なドキュメントをいろいろと探しまわって、それらの情報も加味すると理解も早くなると思います。

また、C#はRubyとかRuby on Railsの思想の影響を受けて、オブジェクト指向を超えた考え方をする言語になっていると思います。
だから、「オブジェクト指向」だけの知識でソースコードを読んでいたら、コードは理解できず、当然ながら、どう修正したらいいかも分からないはずです。

まあ、こんなこと書く私もオブジェクト指向だけの知識でC#のソースを理解しようとして挫折し、改めてC#の書籍を何冊か追加購入して勉強し直した経験からなんですけどね。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

まずC#の本を何冊か追加購入して勉強しなおします。

お礼日時:2016/09/24 14:44

No.1です。



> 「仮定を作って...」ですか...

 そうです。
 先にも書きましたが、授業の課題や趣味で作成した物ではなくお客様や自社の実務向けシステムなのでしたら、開発担当者が居なくなっても保守・改良・流用が可能なように開発時に仕様書を作成してから製造し、試験終了後に試験中の変更・修正をそれらに反省させることも行っているはずです。でないと請け負った開発会社としての責任を負えませんから。
 お仕事で今の解析をされていて、そういった書き物が整備されていない、書き物の作成基準や開発作業全体の標準が規定されていない、または有っても実際に運用されていない場合は転職を考えられてもよいかもしれません。
 設計・製造・試験でのドキュメントやコメントの整備はそれくらい基本的なことです。

 で。
 1本のプログラムにしろ、それらばがとまったソフトウェアにしろ、時に人間系まで含めたシステム全体にしろ、それぞれの「機能」を規定しているはずです。出ないと作れませんから。
 それと見れば「こういう操作をするとこうなる」、「こういうデータを入れるとこういうデータが出て来る」という入手力がわかるはずです。
 それを見れば自分なりに「その場合、自分ならこんな手順で処理する」という何らかの考え(処理アルゴリズム)が浮かぶと思うのですが。。。
 それが浮かばないという事でしたらソフトウェア技術者としての勉強不足、訓練不足、センス不足、、、のいずれかということになります。その場合、ヘルプをお願いするのが順当です。でないと解析工程を守れず工期遅れが生じます。

 今から30年以上昔、勤めていた会社が海外の会社から買い取ったOS(アセンブラ記述)の改版の仕事に参加したことがあります。
 仕様書は割と大雑把な感じで、ソース上のコメントもスラングがあったり洒落的な言い回しがあったりで十分意味を理解できない箇所が多かったです。
 しかしデータ構造に関する資料はほぼ完ぺきに整備されていたため、これを頼りに担当部分である約20Kstepを計画の3ヶ月で何とか読み下して改版前の仕様書と改版後の仕様書を整備し、製造作業に入りました。
 アセンブラだと関数やクラスは無いですし、レベル名や変数名の長さの制約も大きい。そもそもレジスタの何番を何の目的で使用しているかも使用箇所のソースを見ただけでは何だかサッパリです。
 それに比べC言語以降のいわゆる高級言語は様々な名称をより自由に指定でき自然言語により近い形で表記できるので読みくだしやすいです。
 C#は確かに独特のクセがあるとは言え所詮は人がプログラミングのために作った言語です。英語を知らない人が英語を読むのとは違います。オブジェクト指向言語の「オブジェクト指向」の部分を頭に置いておけばハードルの高い言語ではないと思います。
 マイソフトの常で自分流に変に崩してあるところが少々やっかいなクセなのですかね。(^^;

参考まで。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

まずC#の本を何冊か追加購入して勉強しなおします。

お礼日時:2016/09/24 14:44

>なんかいい方法とか、コツってありませんか?


そうですね、
「なんかよくわからないです。」... その辺を如何に人に伝えるのがコツですかね。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

まずC#の本を何冊か追加購入して勉強しなおします。

お礼日時:2016/09/24 14:43

>>なんかいい方法とか、コツってありませんか?



ソースにコメントがあれば、それを参考にします。
でも、C#で書かれたソースは、DelphiやC++で得た知識だけでは、理解できないと思います。
その理由は、C#が、新しい概念を取り込んで作られた次世代の言語です。
1つ、2つの命令が分からないだけなら、なんとか理解できても、そんな箇所が4つ、5つとあることも多いです。
そうなれば、全体としての動きが理解できなくなってしまいますからね。

なので、C#の文法が理解できていない(よく分からない命令がある)のなら、C#の勉強をするのが良いと思います。

でも、C#の文法を知っていて、1つ1つのコードが何をやっているのか分かるのに、全体としてコードが何やっているのか理解できないなら、コードをながめて考え続けるしかない気がします。
この回答への補足あり
    • good
    • 0

まず、その処理部分全体の機能を仕様書などから把握する事。

ソースプログラムのヘッダに説明コメントなどがあればそれも読む事。
 次に機能を前提に入力と出力を把握する事。
 そして、機能・入力・出力から「たぶんこんなアルゴリズム」という仮定を作り、それを踏まえてソースコードを読む事。その際、コメントも活用する事。
 読んでいて自分が最初に立てた想定と違う展開の場合は都度実際のロジックを仮定にフィードバックさせ仮定を更新しながら読む事。

 漠然と「ある変数にある変数を足し込んだ」といった感じにロジックを追っていても「なぜそうなのか?」は見え難いです。
 お仕事でプロが作られた物なら仕様設計、試験設計に関する各種仕様書があるはずですし、製造時にはソースプログラムを書くに当たってのコメント規約などもあって保守の備えがされているはずですが。。。

参考まで。
この回答への補足あり
    • good
    • 1

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!