プログラムの書き方

[Libra]

夏休みにサークルで後輩先輩交えて、
C言語のプログラムの合宿を行おうと考えています。
自分は教える方の立場です。
と言っても、独習Cの参考書程度レベルですが・・・。


今年からプログラムを始めたばかりの後輩も含むので、
printf、scanf、型、演算、制御文、ループ、配列、乱数・・・etc
参考書でいうところのポインタ、関数の前の章あたりの内容までを
扱う予定です。

問題を用意して、プログラムを解かせようと考えているのですが、
解かせる際の手順を以下のようにしようと考えています。


１：必要な仕様を紙に書く(割り算を行うときは０で割った時の処理を付ける等)
２：実行した時の流れを紙に書く
３：使いそうな文法を紙に書く。(繰り返すときは「forループ」、条件がある時は「if文」等)
４：必要な変数を紙に紙に書く。(変数の型、変数名、変数の役割)
５：プログラムで実装するときの手順を箇条書きで書く(フローチャートではなく、日本語で書く)

１～５まで出来て、先輩に確認OK貰ったらプログラムを書いていく

プログラムを書いて完成したら、先輩側に伝え、
動作確認し、プログラムの書き方に間違いがなければ次の問題に進む


という流れにするのを考えているのですが、
問題を解きながら教える際に、このやり方は有効でしょうか？
悪い点、改善点などありましたら、教えていただけないでしょうか？


プログラムを書くときにいきなり書き始めて、あとから変数が必要になったり、
効率が悪くなったりする事を防ぐために、このような感じで進めていこうと考えました。

[たかぎ]

> このやり方は有効でしょうか？

相手にもよるでしょうが、ここまで細かいことをいうと嫌になってきそうです。
何かテーマを与えて、どんなに汚くてもよいので完動するものを作らせ、その後でどうすればもっとよくなるかをいっしょに考えていく方がよくないですか？

[Dixq (管理人)]

私もそう思います。
まず「面白さ」を感じさせてやる気を上げる事が大事だと思います。
いつまでたっても結果が見えないままだとやる気が下がる要因になると思いますので、
ドンドン作ってみて動かしてみる事、大事だと思います。

設計はある程度経験を積んでから行えばよく、間違いはその時指摘してあげればいいと思います。

私ならこうしますかね---。


まず、区分や順番がいいかどうかは別として、上記テーマを章ごとに分けます。
1章：printf
2章：scanf
3章：型
4章：演算
5章：制御文
6章：ループ
7章：配列
8章：乱数
みたいに。そして

1. 章の内容を説明、簡単な例題を出して、教える側が例題を解く。
2. 複数類似問題を出してプログラムを実際に動かして解かせる。
　(解らない人は先輩に随時その場で質問し、1:1で解らない所を教えてもらう)
3. 全部早く出来た人は、まだ出来ていない人に教えてあげる
　(人に教えると言うのはすごく良い事です)

以後ループ

人数が少なくて可能であれば出題する問題は同じレベルで、内容が全て若干異なるのが理想ですね。
例えば

Aさんに出題する問題は
「"*"を使ってprintfで20*20マスに"E"の文字を表示しなさい」

Bさんに出題する問題は
「"*"を使ってprintfで20*20マスに"F"の文字を表示しなさい」

みたいな感じでしょうか。

※
真面目な解説に入る前に、先輩たちが作った作品を見せるとか、
C言語を学ぶと何が出来るようになるのかという事を明確に伝えると良いと思いますよ。
「windows7だって作れます」という紹介も良いでしょうが、あまりにも自分たちと次元が違いすぎる話をしてもつかめないかもしれないので、
1週間位勉強すれば可能になるような事で興味を引きそうな事も教えてあげるといいと思いますよ。

[Libra]

最終的な目的は、「プログラミングの上達」と「ゲーム制作」です。
ゲームを作るときには大規模なプログラミングになるので、
小さなプログラミングを作る時から、どんな変数が必要か、型はどうなのかを
列挙出来るような慣れが出来るといいかなと思いました。


>相手にもよるでしょうが、ここまで細かいことをいうと嫌になってきそうです。
>何かテーマを与えて、どんなに汚くてもよいので完動するものを作らせ、
>その後でどうすればもっとよくなるかをいっしょに考えていく方がよくないですか？

出題する問題のプログラミングの規模が小さい場合でも
手順を挙げて・・・となると細かすぎますかね。難しい・・・。
サンプルプログラミングを見て、いざ問題にとなると
出来る人とできない人との差がかなり出ているようなので、
手順を挙げるのをやった方が良いと思いました。



>まず、区分や順番がいいかどうかは別として、上記テーマを章ごとに分けます。

サークルの活動で、後輩にC言語を教える講習会を開いており、
章ごとに分けて教えるという形をとっています。
今のところ、最初に書いた扱う内容(配列ポインタ)までを終えました。
夏休みは、その講習会で扱った部分までの復習と言う事で
プログラムの問題を解く演習をやろうと思ってます。
ただ、学校でやるようなプログラムでは面白くないので、
出題する問題は、全部ゲームプログラミングにつながるようなものです。

・１～２０までの乱数を重複しないように５個表示
・０を入力するまでなんども繰り返し入力を求めるプログラム
・High＆Low
・ジャンケンを行うプログラム等

[たいちう]

体育会的というか昭和的な感じがしますね。
1人1台パソコンが無かった頃の。
精神的につらそうですが、合宿の目的は何ですか？
プログラミングを覚えるためならば、合宿なんか必要ないし、
プログラミングを覚えることも最終目標じゃないですよね？

[Libra]

> 体育会的というか昭和的な感じがしますね。
> 1人1台パソコンが無かった頃の。
> 精神的につらそうですが、合宿の目的は何ですか？
> プログラミングを覚えるためならば、合宿なんか必要ないし、
> プログラミングを覚えることも最終目標じゃないですよね？

学校の敷地内に合宿所があるので、
広さ的な理由でそこを利用してます。
昼は３時間くらい(？）プログラミングをやって、
例年であれば、夜は交流を深めるために遊んだりして合宿所利用してます。
プログラミングやらずに、遊びに来るだけの人もいますが（笑）。
ちなみに、学校の敷地内なので、大半の人が別に泊らなくても
家に帰って寝れるという位置ですね。
強制参加ではなく、自由参加なので、まったく体育会系ではないのですが・・・。




せっかく答えてくださったので、質問したいのですが、

・５つの数字を入力し、入力した数字を出力するプログラムを作成せよ

という問題で、完全に手が止まっている後輩がいました。
サンプルソース等はやってるのですが、いざ自分で使うとなると応用が効かない様です。
手順を追って理解させたいのですが、最初に書いた方法では細かすぎでしょうか？

[Dixq (管理人)]

内容が同じでも雰囲気作りや進行の仕方次第でどうにでもなると思いますが、
聞いている限りだと、「やらされている感のある」時間になりそうだと感じました。
「自分から意欲的に取り組んで楽しみを見つける」という段階に差し掛かるまでに少し時間がかかるのではないかと。

Libraさんが「勉強」をお好きかどうかは解りませんが、私は「勉強」は好きではないです。
最初から細かく教える方法もあるかもしれませんが、プログラムは演習で覚え、トライ&エラーの中で学んでいく要素が多いので、とにかく演習をするってスタイルが私は好きです。




（以下厭味とかで言っているのではないです）
上のレスをみる限り、Libraさんの合宿への姿勢はある程度決まっているように思えました。
Libraさんはドンドンやらせるよりキッチリ教えるタイプが好きなのではないでしょうか？
教える人がやりたい方法でやる方が作る資料や教え方にも気合が入るでしょうし、
もう自分がやりたい方針がある程度決まっているのならそれでいいと思います。
参加メンバーが何を望んでいるかは、Libraさん自身が一番お分かりだと思いますしね。
上のようなやり方はあくまで私ならこうするかな、という事なので参考程度に聞いて頂ければと思います。

[Libra]

> 内容が同じでも雰囲気作りや進行の仕方次第でどうにでもなると思いますが、
> 聞いている限りだと、「やらされている感のある」時間になりそうだと感じました。
> 「自分から意欲的に取り組んで楽しみを見つける」という段階に差し掛かるまでに少し時間がかかるのではないかと。
>
> Libraさんが「勉強」をお好きかどうかは解りませんが、私は「勉強」は好きではないです。
> 最初から細かく教える方法もあるかもしれませんが、プログラムは演習で覚え、トライ&エラーの中で学んでいく要素が多いので、とにかく演習をするってスタイルが私は好きです。


実は、自分もドンドン演習やらせる派です。&& 「勉強」は好きではないです。
今までは「演習どんどんやらせる派」だったのですが、その方法でやった場合
いざ目的のプログラムを作る場合に結構困ると思うのです。（規模が大きいプログラム）
例えば、２次元配列まで学んだらコンソールでオセロ作れますよね？
いざ組むとなると、先行、後攻、勝敗判定、表示の手順をしっかり立てなければいけないです。
個々の制御文や文法の使い方がわかっても、手順の挙げ方等はここで初めて必要になってくるからです。

どうすればわかり易く説明出来るかというのを考えて、
（結構考えぬいて）上がった方法が、小さいプログラムの内から
手順を追って書けるようにするという方法です。
プログラムの組み立ては紙で行い、実際のプログラムでの
トライ＆エラーで書くことは慣れていけばいいかなと。

「紙に手順を書けること」＆「プログラムを書けること」のダブルの演習のつもりです。


> （以下厭味とかで言っているのではないです）
> 上のレスをみる限り、Libraさんの合宿への姿勢はある程度決まっているように思えました。
> Libraさんはドンドンやらせるよりキッチリ教えるタイプが好きなのではないでしょうか？
> 教える人がやりたい方法でやる方が作る資料や教え方にも気合が入るでしょうし、
> もう自分がやりたい方針がある程度決まっているのならそれでいいと思います。
> 参加メンバーが何を望んでいるかは、Libraさん自身が一番お分かりだと思いますしね。
> 上のようなやり方はあくまで私ならこうするかな、という事なので参考程度に聞いて頂ければと思います。

姿勢が決まってないので、こういう方法はどうなのかと、スレッド立てた次第です。

[組木紙織]

先にゲームを作るのに必要な要素をこちらで準備しておいて、その要素を作ってもらうといった
形式でまなんでもらうのはどうでしょうか？

もちろん事前に文法事項は一通り説明&理解をしてからの話になりますが。

ポーカーは当たり判定が面倒なので、ババ抜きや7並べぐらいならそんなに面倒ではないと思います。
私ならゲームの部品を作らせる前に、文法の説明を兼ねてソート&検索関係のアルゴリズムを
簡単なのからいくつか実装させて、それからゲームの部品を作っていくようにもっていきますね。

[Libra]

> 先にゲームを作るのに必要な要素をこちらで準備しておいて、その要素を作ってもらうといった
> 形式でまなんでもらうのはどうでしょうか？
>
> もちろん事前に文法事項は一通り説明&理解をしてからの話になりますが。
>
> ポーカーは当たり判定が面倒なので、ババ抜きや7並べぐらいならそんなに面倒ではないと思います。
> 私ならゲームの部品を作らせる前に、文法の説明を兼ねてソート&検索関係のアルゴリズムを
> 簡単なのからいくつか実装させて、それからゲームの部品を作っていくようにもっていきますね。
>
>

ババ抜きや7並べ、構成する小さな部品で見た場合
タメになるサンプルが出来ますね。同じ数があるかどうか調べる、
隣の数があるかどうか調べるetc・・・。




自分は問題を解く上で詰まっている人を教えるときには、


・問題文から、なんの文法をつかいそうか
・手順の確認
・今までのサンプルソースで使えそうな部分はないか
・必要な変数は何か
・じゃあ、プログラム書いてみよう！


と確認した上で、指導してました。
文法の基本事項は理解しておかないと、後々の理解度に影響がでるので、
上で挙げた事項をを紙に書かせて理解度深めるやり方ではどうか？と思い質問してみましたが
紙に書くのは、やる側からすれば、やらされている感が出たり、
めんどくさいだけのようですね。

[組木紙織]

>・問題文から、なんの文法をつかいそうか
>・手順の確認
>・今までのサンプルソースで使えそうな部分はないか
>・必要な変数は何か
>・じゃあ、プログラム書いてみよう！

学校の勉強みたいにC言語を覚えることが目的ならそれでいいかもしれませんが、
ゲームを作るためを目的とするなら面白くないですね。

そもそも
変数なんて必要になってから定義すればいいし、
文法なんてコンパイラに怒られながら覚えていくものだとおもっています。