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

プログラム未経験で、これからJAVAを習うのですが、プログラムは書かずに、ネットから拾ってくるという人がいて、このやり方を身に付けると飛躍的に覚えますか?逆にこのやり方はまったく知識が付かないやり方ですか?もちろん基本出来ないと無理だとは思いますが・・

A 回答 (4件)

現在は一応プログラミングで飯を食べています。



ただ単に拾ってきて、それを何も考えずに・何も修正しようとせずに使っていたらいつまでたっても進歩しません。拾ってきたものがどうやって動作しているかを考えて、自分なりに改良(改造)を加えていくことで、知識も増えていくと思います。

私はプログラミング始めたときには、雑誌に掲載されていたBASICで書かれたゲームを必死で入力して、じぶんなりに考えて改造して楽しんだものです。
    • good
    • 0

まずは、自分がおもしろそうと思うプログラムを見つけて、それを真似ることが最初だと思います。


「まねる」がポイントで、ちょっとずつアレンジしていかないと駄目です。
たとえば、練習でよくある「もぐらたたき」なんかでも、ポイントのつけ方を変えてみたりとか、やりたいことが出てくると思うんです。
その「やりたいこと」を元のプログラムに反映させるために、自分で色々調べて試す、調べて試す、の繰り返しだと思います。
    • good
    • 0
この回答へのお礼

ありがとうございます。参考になりました。

お礼日時:2006/01/26 14:34

本などを読んで基礎を覚える事は重要です、


しかし、本に載っているサンプルコードを書いて動かすよりも
自分の作りたいプログラムをネットや本を使って調べながら作ると大変だけどプログラムが身に付くと思います。

そういう意味では人の書いたコードをもとに作りたいプログラムに変更するのはありだと思います。
だけどちょっとした値を変更したり見栄えを変える程度では意味があまりないでしょう。
あくまでもそのプログラムをもとに自分の欲しい機能を追加したりいらない機能を削除した方が良いです。

また、他の人のプログラムを見る事自体が勉強になると思います。
上手い人のコードなら尚更です、どんどん真似て理解してテクニックを盗みましょう。

とりあえず自分で調べながら変更していく事は上達の早道だとは思いますよ☆

だけどプログラムの内容によっては変更禁止のプログラムなどあると思うので
拾う時には注意しながら広いましょう。
(勉強目的ならアリかもしれないけど嫌がる人は嫌がります。)
    • good
    • 0

システム屋さん、いわゆるシステムエンジニアの卵をやっていた者です。



その経験から言わせてもらうならば
「書籍やネットなどの情報源を駆使できるならば、
 極端な話、その言語について全く知らなくても大丈夫」
です。

他の方も言っているとおり「ネットから拾ってくる」のは
一つの手段にすぎません。
問題は「必要としているもの、つまり『利用できるプログラム』
 を見つけ出し、必要な形に"改造できる”事」です。

そのためには「そのプログラムはなぜそういう組み方をされているのか」
読めるようになる必要があります。

・一見無駄な処理に見えるけれど、ワザワザそうしてある理由。
(これの小技が『switch文のdefault節は空でも明示する。』)

・無くてもOKな処理だけれど、律儀に入れてある処理。
(これの定番が『変数は使用する直前に初期化する。』)

・一見ただの空行だけれど、なぜかそこだけ行が多い。
(メンテナンスのために、段落のような意味合いがあったりする。)

というような、言語で決められた規則の他にも
そのプログラムを組んだプログラマの個人的な決め事や
作成中の仕様変更に柔軟に対応できるようにするための技法など
「そのプログラムが語らんとしている事」を『読み取ろうとする努力』が
必要なのです。

もちろん「動けばOK」なだけの組み方をしたソース(プログラム)にも
出会うしょうが、それはそれでちゃんと読んであげれば
「ソースが悲鳴をあげている」のも分かるようになります。
その悲鳴が聞こえるようになれば、「原因不明のバグ」も
見つけられるようになります。

なので、始めのうちは

・参考にするプログラムを真剣に読んで
・自分なりの決め事を積み重ねていき
・必要に応じて入手したプログラムを、自分の決め事に変換していく

試行錯誤と繰り返していけば「飛躍的に上達」することでしょう。

極端な話になりますが、私の実話をお話します。

[その1]
その時作成していたプログラムにおいて、あるロジックが必要になりました。
しかし、なかなか希望に合う「参考プログラム」すら見付かりません。
仕方が無いので、『こんな順序で処理していけばいいだろう』という
イメージを『コメント文で組んでいきました』。
そして、そのコメント文に対応する命令に変換していきました。
(この変換が一般的に言われている「コーディング」の部分。)
当然その言語には存在しない命令を要求するコメントがでてきます。
そして再びコメント文を考え直し、命令へ変換していきます。
その結果、「コメント文の方が行数の多いロジック」が完成しました。
もちろん期待通りの動きをするものが出来上がりましたが、
そのプログラムを見た人からは「作文してんじゃないんだから」という
コメントを頂きました。

[その2]
・表示対象となる項目がいくつかあります。
・その表示順序を設定します。
・その項目を表示する、しないの設定もできます。
・でも「最終的にどうするのか」が不明確だったりします。
・しかもその仕様が決まるのは「しばらく先」です。
・でも「その仕様に『即』対応できる」ように
   プログラムを用意しておかねばなりません。
などという「表示順序の設定画面の『イメージ画面』しかない」
という状況でのプログラミングでした。
そのため、修正量が少なくなるようにコーディングしました。
その結果「一見すると『無駄に英数字が列挙された』switch文」になりました。
なので、その経過を知らない人にも「仕様が混沌としていた歴史」を
語ってくれるロジックとなりました。


一説では、プログラミングは調理に例えられます。
「ソースの出来が、完成するもの(プログラム)の出来を左右する。」
かららしいです。
拾ってきたプログラムと会話するような感じでいれば、
きっとプログラムの方から教えてくれるようになってくれます。
    • good
    • 0
この回答へのお礼

ありがとうございます。参考になりました。

お礼日時:2006/01/26 14:34

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