プログラミング上級者のプログラミング風景

[ターボ]

おはようございます。

私は趣味でプログラミングをしているのですが、CかC++かJavaかC#でプログラミング上級者もしくはプログラマがプログラミングをしているところを見たいのですが、Youtubeとかで探してみたのですが、見つからず、プログラミング上級者とか実際のプログラマはどんな風にプログラミングするのかなぁ。と思いまして、投稿しました。

誰か、プログラミングしているところが見れるサイトとか有ったら教えて欲しいのですが、実際にプロのプログラマやプログラミング上級者がどんな風にプログラミングするのかすごい興味があります。プログラミングしている姿とか。

誰か詳しい人がいらっしゃったらURLとか紹介して欲しいです。

よろしくお願いします。

[たいちう]

ご要望に沿うか判りませんが、、、
[BBvideo 425,350]http://www.nicovideo.jp/watch/sm8517855[【プログラミング】テトリスを1時間強で作ってみた【実況解説】][/BBvideo]

[softya（ソフト屋)]

どんな物を見たいのかいまいちわからないのですが？
プログラムを組むのが早い人ととかの実況動画はyoutubeで探せると思います。
プロの人の組み方が見たいと言う話だと作業の大半は設計とか打ち合わせが中心なので、そんな作業の動画になると思います。あったとしてですけどね。

とりあえず早く組んでみる系。
[youtube][/youtube]
えっ早すぎ。これは手で打ち込んでない気が。
[nico]http://www.nicovideo.jp/watch/sm5278848[/nico]


ちなみに、
「「テトリスを1時間強で作ってみた」動画の投稿者にインタビュー──「プログラミングの楽しさ伝えたい」：ITpro」
http://itpro.nikkeibp.co.jp/article/Int ... 04/340019/

[ターボ]

たいちうさんsoftya（ソフト屋)さん返信ありがとうございます。

二人ともとても参考になりました。

ありがとうございました。

[ISLe]

一般的にプログラミング＝コーディングという感覚なんですかね。

わたしもsoftyaさんのおっしゃるように、プログラミング時間の大半はノートやメモ用紙に向かって唸っています。

知識や経験がたくさんあるひとはボキャブラリーが豊富です。
例えばフェードイン/フェードアウトの演出を実装しようとしたとき、『フェードイン/フェードアウト』を単語で理解できるわけです。
そうやって引き出しを増やしていくと、次に書くコードが用意されているかのようにサクサク書けるようになります。

ただしプログラムの構造化に取り組んだりオブジェクト指向をある程度理解しないとすぐに物理的な限界に達してしまうと思います。

[ターボ]

ISLeさん返信ありがとうございます。

私はプログラミングの仕方とか専門的に教わったことが無くてプログラマの仕事に就いたことも無くほとんど独学でやっていたので、プロの人や上級者の方はどんな風にプログラミングするのかなぁと興味があり投稿しました。

>わたしもsoftyaさんのおっしゃるように、プログラミング時間の大半はノートやメモ用紙に向かって唸
っています。

ソースを書く前に考えをまとめる時間がかなりかかるんですね。

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

これからもご教授お願いします。

[softya（ソフト屋)]

業務としての開発をプロセスで見ると従来からのウォーターフォール設計だとすると
要件定義・外部設計・内部設計・開発(プログラミング・単体テスト)・総合テスト・運用テストにわかれます。
http://itpro.nikkeibp.co.jp/article/lec ... 30/255501/
要は設計とテストが大半を占めていて開発の時間は１/３程度しかありません。

ゲームだと様相も変わる部分がありますが設計とテストはかなり重要です。

[ISLe]

わたしもプログラマの職に就くまで完全に独学でしたけどね。
職に就いたあとも特に教えてもらったことはないような。
同じ年に入社した同僚とは当初からずいぶん制作のスピードが違いましたが。

ソースを書く前に考えをまとめる時間がかなりかかるんですね。

実際には、打ち合わせとかしてる間に、基本的な構造は頭の中で組み立て終わってますけどね。
細かいところまできちんと煮詰めるのが面倒くさいだけで、慣れれば時間は掛からなくなります。

個人的には、きちんと煮詰める前にコーディングに入ってしまうのは逃げだと思ってます。

[ターボ]

softya(ソフト屋)さんISLeさん返信ありがとうございます。

2人とも大変勉強になりました。

softya(ソフト屋)さんへ
>要件定義・外部設計・内部設計・開発(プログラミング・単体テスト)・総合テスト・運用テストにわかれます。

なんか10年位前に基本情報技術者試験を勉強していた頃にテキストに書いてあったのを思い出します。

ISLeさんへ
>わたしもプログラマの職に就くまで完全に独学でしたけどね。

そうなんですか私も独学で勉強していた頃はどうしてもプログラマになりたいって思っていたのですが、数年くらい独学でC言語やC++やJavaやCASL2やVB.net2003の本を買いまくって、参考書に書いてあるプログラムやアルゴリズムのプログラミングや基本情報技術者試験の勉強していたけど、もう完全に諦めて今は趣味でやっています。

もしよろしければどのように勉強していたのか今後の勉強の参考にしたいので、ご教授お願いしたいです。

管理人様、解決のボタンを押しているのに長引かせて申し訳ございません。

[softya（ソフト屋)]

たぶん、人の勉強の仕方は参考にならないでしょうが少しは参考になるかもしれないので。
私の高校生時代（昔なので）などは、雑誌に載っているプログラムを自分の自作マイコン（パソコンの原型）に移植していました。
ＢＡＳＩＣや機械語などのコードを完全に再構成して移植するので大変勉強になったのを覚えています。
この時代に基本的なことの大半は学べたと思います。
面白そうなことを楽しみながら色々やっていたって事ですね。

就職のためソフトウェアの専門学校にも行きましたが設計についてちゃんと教えてもらった覚えがありませんね。
最初の業務系の会社では設計とテストについて多少教わりましたが技法と呼べるほど大したものではありませんでした。
結局のところ自分で試行錯誤して、どうすればバグが少なく効率的に品質が高いものが作れるか試行錯誤してきただけです。

そうそう、一番勉強になったのはライブラリを作って会社の同僚に使ってもらっていた時でしょう。
どうすれば使い方を間違わないか、誤解を生まないか、相手のミスを如何にガードするか、安易なミスのバグを如何に的確に警告できるかなど勉強になりましたし、インターフェイスや名前の付け方など工夫する余地もたくさんあることがわかりました。

ちなみに私は大雑把に仕様を決めて細かいところは作りながら決める派です。
あんまり細かく決めたくても細部が見えない場合もあるので大規模プロジェクトでもない限りは見切り発車してしまいます。
手戻りが多いので余り褒められた作りかたではないと思いますが、基本の仕様さえしっかりしていれば完成までは持っていけるものです。

【補足】
そういえば、何処で行き詰っておられるのでしょうか？
あんまり悩まずアプリを作ることが一番大事なんですけどね。
次のアプリは更に良い設計になるように繰り返すだけです。

[ISLe]

softyaさんとだいたい同じですね。
専門学校や教室などにも通ったことがない純然たる独学ですが。
わたしにとって教科書と言えるのは、C MAGAZINEとOh! Xです。
資格は持ってません。

もともとゲームが好きで、思い通りのゲームが作れると聞いて始めたプログラミングです。
パソコン一台あれば、絵や音を出せるということで各方面にも興味を持っていろいろやってるうちにある程度ハードにも詳しくなったという感じです。
興味のある対象ばかりやってたので勉強したという意識はないですね。

MS-DOSの時代にはRS-232C通信ドライバとかグラフィックライブラリとかウィンドウシステムとか作って、そのあたりでプログラムの構造化を体に叩き込みました。
いまでも、いかにプログラミングの際にコーディングしないで済ますかを意識して、ライブラリ作ったりフレームワーク作ったりしてます。


補足しておきたいのですが、細かい内部の実装を紙に書くことはありません。
先に書いた例で言うと紙に書くのは、『フェードイン/フェードアウト』という単語です。
もし『フェードイン/フェードアウト』という単語を知らなければいわゆる基礎研究をやって事前にボキャブラリを増やしておきます。
実際わたしのノートにはほとんどプログラムらしいことが書いてありません。
プロットとかシナリオとか絵コンテと言ったほうがイメージが近いかもしれません。

[ターボ]

softya(ソフト屋) さんISLeさん返信ありがとうございました。

二人の経験談とても参考になりました。

大変ためになる話しありがとうございます。

二人の話を聞いて私もまたプログラミングしてみたくなりました。今は簿記3級やTOEICの勉強や仕事に忙しいけど、また時間を見つけてプログラミングしたいです。