- ベストアンサー
プログラミングが苦手・・・悩んでいます
- ITヘルプデスクで働いている者ですが、プログラミングが苦手で悩んでいます。昔プログラマーとして働いた経験もありますが、読み解けないプログラムやロジックが浮かばないことが多く、新しい言語の習得も困難です。
- プログラミングの思考プロセスが分からず、頭の中が混乱してしまいます。特に新しい言語の仕様を覚えるのが苦手で、ヘルプやチュートリアルが分かりづらい場合が多く、情報収集が難しい状況です。
- 上司や他のプログラマーに頼ることが多く、単純な解答を聞いてしまうと自己評価が下がってしまいます。上達のためのヒントや思考法についてアドバイスをいただきたいです。
- sasa522
- お礼率59% (72/121)
- その他（プログラミング・開発）
- 回答数4
- ありがとう数2
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
こんにちは． 私はそれほど長い業務経験はないのですが，プログラミングは得意な方だと思っています． DBMagicという言語（というよりツール？）は知らないので，憶測で話をしてしまい申し訳ないのですが， かなり特殊な言語のようなので．最初はできなくても別に悲観する必要はないと思います． 上司の方も，昔は同じような経験をしていると思いますが，どうでしょうか． 普通，一度同じようなパラダイムの言語を学んでると，新しい言語を理解するのは早いですが，知らないパラダイムの言語はなかなか覚えられません． たとえば，C++で多くの経験を積んでいる人でも，Javaを学ぶのは楽だと思いますが， SQLやPrologのような言語を学ぶのは，結構苦労します． 次に新しい言語を学ぶ時ですが，私の場合とにかく適当なサンプルコードを写して実行させて動作を見たり， 改良しながら書き方を覚えていきます． 仕様書的な本は，ある程度プログラムが書けるようになって，理解を深めたいときくらいしか読みません． とにかく，「よくわからないけどこうすれば動く」というようなことをたくさん覚えて実務を積んで， 徐々に言語や開発環境に対して深い理解をしていくのが，新しいプログラミング言語を学ぶ近道だと思っています． （わからないコードを理解するのは，実行させて途中経過や最終的な結果を見るのが結局一番早いです．．） また，ロジックを考えるのは，言語依存ではない部分も多いと思うので，ご経験のある言語で実装されたアルゴリズムの本 を一冊読むと良いかもしれません（できれば名著と呼ばれる本を）． そこに書いてあるアルゴリズムが直接役に立つことは少ないと思いますが，参考にするべき考え方はたくさん学べます． 人並みの意見かもしれませんが，何か参考になれば幸いです．
その他の回答 (3)
- akaginoyama
- ベストアンサー率43% (37/86)
趣味のプログラマーですが 私も、長い事プログラムが上達せずに悩んでおりました。 最近急速にいままで理解できなかった部分が解るように なっていたので自己分析しておりました。 参考になればと思い投稿させていただきました。 ■プログラムが上達しなかった時 1.細部から入り全体を見ていなかった。一つの命令の理解を一つの解説等からその場で理解しようと やっきになっていた。 2.理解出来ない、ソースは打ち込まなかった。 ソースは理解できてから打つ物だと決めつけていた。 3.複雑に問題が絡んでいた。 命令が解らない＋アルゴリズムが解らない＋やりたい事がぼやけている と言った具合に複数の問題が絡んでいた。 とまあ、主な原因はこんな感じでした。 これらを下記の様に改善したら劇的に変わりました。 ■変わった点 1.全体を見る事でこう変わった いまやろうとしている事ではなく先に必要になる 部分の情報収集を休憩がてらやっておく事で、それに 取り掛かる時には用語等が頭の片隅にあり、解説を見た 時に何を言っているのかイメージがつきやすくなった。 さらに、全体を見て無理そうな部分を前もって把握出来 別のやり方を用意する準備時間が取れる様になった。 2.理解出来ない、ソースも打ち込む様になった。 解説書などは、英語から翻訳された物が多く、難しい表現 なので命令の動作を勘違いているケースが非常おおかった。 最近は野球やバスケットを習うように自身で実行することが 多くなった。これはキャッチボールと言う簡単な動作でも 言葉や文章で習う事を考えればどれほど複雑に書かないと いけないかを考えればよいと思います。 手の角度や力の入れ具合等数字で言われても理解出来ない様な 事に近い。 3.複雑に問題が絡んでいたのを問題整理、分解した。 2つ解らない部分があると2倍の時間がかかるだけと思っていたけ ど、実際にいくつかの作業でみると解決するのに4倍以上の時間 が掛かっていた。挫折した作業を思い出してみると３つあった。 一つの解らない所は、予想やトライアンドエラーでさほど苦労無く 解決出来る事にきずいたので、問題を一つに絞り込む事に全力を 使った、半年掛かっても解決できなかった問題もあっさりクリアできた。 忙しくても、上記の様に自信の問題を調査してみる事が最も近道だと 思います。 ■独り言 ちなみに、コードを入力してみるとか、問題を切り分けるとか 全体をみるとかと言う事はたくさんの本や人が言っていた気が しますが、私の場合は単に実践出来てなかったのです。 私は、まだ、たくさんの事も見落としていると思いますが みる目や聴く耳をもっと磨いて行きたいです。 お互いがんばりましょう。
- don_go
- ベストアンサー率31% (336/1059)
言語の仕様をマニュアルや参考書に書いてある単語や文脈の 意味を理解／推測しようとする事は案外効果が薄い物です。 単語の意味を追いかけるのではなく自分がやろうとしている 事を実現する為にはどうしたら良いかを考えるべきです。 例えば、日常的な挨拶の言葉を他国の言葉ではどう言うかと いう様に。 データベース処理にしても 1)データベースに接続する。 2)データベースをオープンする。 3)SQL文を作成して実行する。 4)データを取得する。 5)データベースをクローズする。 6)データベースの接続を解除する。 といったのが基本的な流れとなりますが、これを 1)トランプを棚から出してくる。 2)トランプをケースから出す。 3)指を鳴らす。 4)カードをめくって見る。 5)トランプをケースにしまう。 6)トランプを棚に戻す。 の様に、自分にとって身近な事に置き換えてみると、何を しようとしているかがイメージしやすくなります。 後は、マニュアルから該当するコマンドを探してくるだけ です。 ＃データベースの種類が変わったとしても基本的には同じ ＃様な事しかしていません。
- sgwjn
- ベストアンサー率70% (47/67)
このような考え方については、個々人によって適した方法は異なると思いますので、こうすれば良いと言った明確な答はないと思います。 個人的には、処理全体を初めは大きく、その後細かく分割して考えていくことが多いでしょうか。最初から実装レベルで細かく考えていくと、全体像を把握しにくくなりますから。 英語を訳すときに、文の頭から訳していくのではなく動詞以前（主語）、動詞（否定かどうかとか）、動詞以降（その他修飾とか）などのブロックに分けて考えるようなものです。 例えば、数字をソートするプログラムを作るとします。 大まかに処理を考えると、『入力』→『ソート』→『出力』となりますよね。 その次に、各処理をもう少し細かく考えます。 例えば、入力であれば 『入力値の受取』→『入力値の健全性検査』→ データをソート処理へ送る のようになると思います。 その後、また各処理をもう少し細かく考えて行き、最終的にプログラミング可能なところまで落とします。 この例で言えば、『入力値の受取』は、例えばCではscanf()を終了条件が満たされるまで繰返す方法などが考えられます。ファイルから読込むかもしれません。 『入力値の健全性検査』では、少なくとも数値に変換できない入力値はエラーとなるでしょう。エラーがあれば、メッセージを出力して処理終了となるかもしれません。 このように、慣れないうちは段階を踏んで徐々に細かいところまで考えていくようにすれば、自分の考えを少しずつまとめながら作業を進めていけるので良いのではないでしょうか。それに、この類の考え方は、フローチャートも比較的書き易いのではないかと思います。 あと、新しい言語を覚える時ですが、私は特にチュートリアルやリファレンスを読んで、詳細な言語仕様やAPIなどを覚えたりはしません。 一番最初は、各種変数と関数の宣言方法、代入文、演算子、条件分岐（if）や反復処理（for）の書き方を覚えるくらいです。基本的に、これだけ押さえておけば大体の処理は書けます。その後で、必要に応じて標準関数やクラス、言語特有の処理（ポインタ、構造体、継承とか）などについて調べていきます。 これもアルゴリズムの考え方と同じで、初めに大まかな基本を押さえて、必要に応じて徐々に細かく調べていくということです。 初めから一度に何でもかんでも手を出しても、効率は余り良くないですし、不要な部分にまで時間を費やしてしまうことも少なくありません。 初めてのこと、慣れないことについては、最初は最小限のことから始めて、必要なときに必要なことを調べる、それを繰返して段階を踏んで進んでいくのが、結局は一番効率が良いのだと思います。
