Crazy Tea Party-小学生に良いコードのルールを教える実験

私たち- エレファント数学キャンプ -は、8年生から11年生の学生のために、長年にわたって夏と冬の学校を開催しています。 学校での主な活動は、主要なタスクであるプロジェクトの仕事です。 複雑な物理システムのモデリングから、暗号を破るプログラムやAndroid向けのおもちゃを作成するプログラムまで、あらゆるものがあります。 学校でのほとんどのプロジェクトは、何らかの形でプログラミングに関連していますが、プログラミングがそれ自体でプロジェクトの目的となることはめったにありません。 ベテランのプログラマーになるまでの時間がなかった生徒たちは、永遠の時間不足の状況でさえ、「Schaubが働いた」というコードを書きます。 だから私たちは悪いコードが何であるかを直接知っており、毎年新しいコードを見ることもありますが、コードを読めないようにする方法でさえ驚くことがあります-そして毎年この問題をどうするかを決定します。



たとえば、昨年、導入課題のタスクのコードレビューを実施しました。 確かに、コードレビューは任意です。学童にエラーを指摘しますが、コードの書き直しを強制しません（効率は劣りますが、より人道的です）。 このアイデアは成功しているように見えますが、レビュー担当者から多くの時間がかかります。



別のアイデアはgitを使用して、「みんなのがらくたを見ることができるようにする」ことでした。 それから、プロジェクトの終わりに向かって、それがどのように始まったのか、どこで変わったのか、恐ろしいのか、違うやり方で行ったのかを再考することができました。 しかし、このアイデアは時の試練に合格していません。 私たちの経験では、学童はバージョン管理システムの使用方法を習得することも、定期的に行うことも困難です。 彼らはなぜ硬貨が必要なのか理解していないため、退屈しています。 さらに、gitを習得するのに数時間かかることは、1週間のプロジェクトにとっては無駄です。 そして、そのバージョン管理システムはもともと考えられていませんでした。



この冬に使用したソリューションは非常に気に入ったため、方法を共有する必要があると考えています。 クレイジーティーパーティーと呼びました。

だから、タスク：生徒に明確できれいなコードを書くように教える。 同時に、このプロセスは魅力的にする必要があります...



良いコードの書き方を学ぶために、通常、良いコードと悪いコードの例を見ていきます。 生徒は通常、自分のコードのみを見てください。 コースはこのプラクティスを変えるように設計されています。参加者は良いコードと悪いコードを見て、自分でコードを書きます。 通常、子供は批評家として行動しますが、特別なコースでは、他の誰かのコードを見て、自分でそれを批判し、改善しようとする機会がありました。 どうやって？



私たちは1つのタスクを取りましたが、その条件は大きく異なる可能性があり（Conwayゲーム「Life」がありました）、それをいくつかの小さなステージに分割しました。 分割は、各反復の終わりに既製の作業プログラムが取得されるように行われます。 ステージ自体は非常に小さいため、1つのレッスン（1.5時間）で完了することができ、場合によっては2回の反復でも1.5時間に収まることがあります。

参加者は将来の反復を事前に認識していないため、次の反復を簡単にするために、現在の反復のどこに「ストローを入れる」べきかわかりません。

初めに、学生は最初の段階のタスクを与えられます。 すべての参加者が完了した後、「席を変更する」時間でした。 参加者は決定を交換し、第2段階のタスクを受け取りました。 今、彼らは他の誰かのコードを見つけ出し、それを修正して、第二段階の問題を解決しなければなりませんでした。 同時に、コードをリファクタリングして他の人の間違いを修正することは許可されていましたが、コードの書き換えは完全に禁止されていました。 第二段階の後、生徒たちは再びソリューションを交換し、再びコードを追加し続け、再び彼らのために新たな基盤を作りました。 特別コースの参加者間のコミュニケーションは限られているため、コードを読んだ後は、どのような恐怖がここに書かれているのかを知ることができます。 反復間で、繰り返し発生するスタイリングエラーが解析されましたが、修正が推奨されました。



特別コースには5人の学生がいて、それに応じて5つのプロジェクトがありました。 3人の生徒が、異なる時点で各ファイルに取り組みました。 数回の反復の後、彼らが一度独自のコードに到達したとき、それはすでに彼らが最初に書いたものとは非常に異なっていました。 前のイテレーションで作業した外国のコードは、他のすべての参加者を通過した後に彼ら自身のコードよりも「自分のもの」であることが判明しました。

また、学生が円でコードを交換しないことも重要です。そうしないと、各反復で参加者は同じ人の手からコードを受け取ります。



しかし、非常に興味深い詳細を見てみましょう。 私が言ったように、グローバルなタスクはConwayゲーム「Life」を書くことでしたが、このタスクは事前に知られていませんでした。 ステージのタスクは次のとおりです。

1. 私たちは、200セルの大きさの競技場である1次元のゲーム「Life」（ 基本的なセルラーオートマトン ）を書いています。 セルは、隣接するセルが1つしかない場合に生き残るか、または生まれます。 極端な点については、海外の「隣人」は常に「死んでいる」。 最初に、フィールドに生細胞を入れて、生細胞の数が係数2で幾何学的な進行を構成するようにします。各ターンはEnterキーを押すことで発生します。
2. ユーザーはフィールドサイズと等比数列係数を入力できます。 「W」コマンドを入力して、一度に1ステップではなく10ステップを実行する機能を追加します。
3. ユーザーにフィールドの初期構成を設定する機会を与えます。ユーザーが数値を入力すると、そのバイナリ表現によって、生きているセル（ビット1）と死んでいるセル（ビット0）が決まります。 また、最初に指定された構成が指定されたフィールドサイズに適合することを確認する必要があります。 プログラムを再起動する「R」コマンドを追加します。
4. 生存のルールを変更します。現在、隣人が1人いるセルは生き残り、左側に隣人がいる場合は何もない状態から生まれます。 「W」オプションを補足して、フィールドで実行するステップ数を入力できるようにします。
5. ライフルールは、0から255までの数字で設定されます：8つの初期構成（それぞれ2つの位置にある2つの隣接する構成を持つ中央のセル）ごとに、1ビットが設定されます：次のステップのセル
   
   
   ちなみに、この「Life」の修正では、推測できます

   学校新聞からの抜粋：

   「マッドティーパーティー」は、1次元ゲーム「Life」の運命を予測します。ルールとして年齢を紹介し、細胞の発達を観察します。 このような非常にもっともらしい結果が得られました：16歳以上では、すべてが絶望的に​​悪く、誰もが常に日没になります。 23では、最終的に安定性が得られます。 一緒にいるとまだ生きられることもあります。 ライフゲームの専門家である編集スタッフは、25歳でこの占いが繁殖を予測すると付け加えています。 講義から思い出すように、普遍的な知識は110になります。

   
   
   
6. フィールドとルールの保存と読み込みを追加します。
7. ゲームを2次元の世界に転送します。 現在、ルールは標準的な方法で設定されています。生き残るための隣人の数と、生き返るための隣人の数。 フィールドのステータスは行ごとに設定されます。

生徒は全員Pythonで書いていますが、参加者のプログラミングスキルはかなり異なっていました。 割り当ての形式は、グループ内の人々のレベルの差がマイナスではなく、重要なプラスになるようなものです。 共通のプログラミング言語を1つ使用すると便利ですが、必須ではありません。 実際の生活では、慣れていない言語でコードを読んで編集しなければならないことがあるため、複数の言語を使用するとコースがさらに楽しくなる可能性があります。

学童にバージョン管理システムの使用を強制しませんでしたが、便宜上、資料を1つのリポジトリに入れました。 プログラミングの学習に興味がある人にとっては、とても楽しい読書です。



すべての普通の人、つまり他人のコードを自分で調べたくない人のために、学童の誤りと私たち自身の誤りの両方について、私の観察と分析を行います。



参加者間のコード交換により、コードベースの品質が非常にスムーズになりました。 プログラムが多くの1文字の変数とモジュール性の欠如で始まったとしても、2、3回の反復の後、誰かが確実に変数に適切な名前を付け、ファイルを構造化し、コードを単純化します。 そして、他の誰かの（比較的）良いコードを台無しにするためには、まだ試してみる必要があります。 他の人のスタイルに簡単に統合できます。 さらに、生徒はお互いから（または先生から）好きなパターンを選びます。 時々良いもの。



しかし、私たちの期待に反して、時間の経過とともに、コードはますます異なったものになりました。 決定が下されると、彼らは生き続け、発展し続けましたが、彼らは家で異なったことをした人々の手に落ちました。 しかし、公平のために、これは常にそうではありませんでした。 一部の参加者は、誰かが別の方法で問題を解決したことを受け入れることは困難であり、通常の作業コードを独自の方法で書き直すために座っていました...そして、彼らは常にそれを改善しませんでした。 また、変数の名前はその内容と同じように変更可能でした。 どうやら、変更の規模にいくつかの正式な制限を導入する価値があります。



コースの作成者によると、「マッドティーパーティー」は、影響を受けたすべてのミドルスクールの生徒の中で最高であり、最も弱くて最も強力な生徒の中で最も少なかった。 最も弱い人には常に彼の標準に非常にまともなコードが付いており、最も強い人には誰も従わない。 この状況は、コースの教師自身が追加の2人の参加者としてコードの作成に参加する場合に改善できます。 そのような最初の参加者はリファクタリングを記述し、自分でコードを作成するかのようにコードを変更します。2番目は、最も弱い参加者よりも悪い人為的に悪いコードを実行します。



私たちの学生の何人かはOOPスタイルで書くのが得意だと言わなければなりません。 そのため、OOPが頼む場合でも使用しなかったことは非常に注目に値します。 彼らにとって、コードを単純化することになると、オブジェクトは明白な選択とは思えません。 独自のクラスの作成方法を学ぶだけでは十分ではありません;クラスの使用によりプログラムが改善される場合、訓練を受ける必要があります。 コースの将来の化身は、これを考慮すべきです。



すでに述べたように、変数と関数の名前はリビジョン戦争を引き起こします。 これは、好みの好みだけでなく、多くの名前が非常に不幸であり、良い名前が正常に修正されたという事実とも関連しているようです。 プログラミング教育の私の経験では、初心者（かなり大人の初心者でも）が変数に意味のある名前を付けることはできません。



この誤解の理由の1つは、変数を一種の「ボックス」として考え、そこに値を入力し、値を読み取り、値を変更できることです。 「変数」という名前自体は、それらの意味を変更するために作成され、異なる時点で異なるコンテンツをそれ自体に保存するオブジェクトの意味を明確に記述するために作成されたことを示唆しています。 時にはそれは単に不可能です。 同じ変数を再利用することは、低レベル言語の高性能アプリケーションではおそらく便利ですが（コンパイラの最適化が不十分な場合にのみ）、現代の世界では言語機能の最も意味のある使用ではありません。 通常、これらは無害な小さな変換です。数文字を文字列に追加し、数値を丸め、文字列を数値に変換します。 たとえば、2つのダミーセルがエッジに沿ってフィールドに追加され、同じ変数に記録されました。 そして今、変数にあるもの、つまり数値またはその文字列表現を言わないのですか？ フィールドまたは拡張フィールド？ 些細なことのように思えますが、コードの品質はそれらで構成されています。 そして、そのような些細なことは、リファクタリング中に大量の血液を台無しにする可能性があります。

私は関数型プログラミング言語に対する熱烈な謝罪者ではありませんが、不変変数の概念は、優れたコードスタイルの習慣を作成するのに非常に役立ちます。



別の理由は、多くの人が単に怠けすぎて、変数の意味を集中して定式化できないことです。 多くの場合、タイトルは変数の内容ではなく、その形式を反映しています。 たとえば、3番目の段階で、フィールドの初期構成を10進数で指定できるようになりました。これは、バイナリ形式に変換されたときに構成を提供します。 5つのプログラムのうち4つでは、この変数は「number」または「decimalNumber」と呼ばれ、「initialFieldPosition」または「aliveCellsEncoded」ではありません。 その後、これらの名前は何人かのプログラマーの好みを満足させるために数回変更されましたが、完全で論理的な名前を取得しませんでした。 本当の名前を取得した他の多くの変数とは異なり、このスローを停止しました。 または、ここに「count_symb」がありますが、それは何ですか？ 実際、フィールドの長さ-そして、すべてフィールドが文字列で表されるため、文字数は文字列の長さを表します。



3番目の理由は、言語の知識の不足です。 知らない言語で考えを定式化することは困難です。 いくつかの用途で使用される出力の1つは、タスクとともに、タスクのトピックに関する用語集を作成することです。



関数名には同様の編集戦争があります。 いくつかの理由は似ていますが、特定の理由があります。 実際には、新しいコードは通常、より論理的な場所ではなく、追加しやすい場所に追加されます。 関数の引数または戻り値のパラメーターを追加する必要がある場合（Pythonで記述していることを思い出してください）、良心のtwinりもなく追加されます。 成功した場合、関数の名前はそれに応じて変更されますが、常にではありません。 しばらくすると、関数によって実行されるアクションの意味は、その名前と非常に条件付きの関係になります。 この問題の対処方法はまだ明確ではありません。 1つの選択肢は、学童が関数によって返される値のタイプを変更できないようにし、アクションを実行して結果を返す関数に明確に分割することです。 しかし、そのような禁止が機能​​すると信じるのは単純です。



すべての欠点にもかかわらず、このコースは生徒たちがほぼ健全なコードを書く方法を学ぶのを助け、また彼らがプログラムを読んでいる教師が経験するすべての痛みを経験することを可能にしました。 ;）



クレイジーティーパーティーコースは、 Pavel Smirnovによって考案および実施されました。 私は著者に尋ね、プログラムの結果のソースコードを読み、私の意見を書き留めました。



PSこのコースでは、事前にいくつかの手順を慎重に考えた製品を書く方法ではなく、他の人のコードを操作する方法、徐々に改善し、プログラムがひどいものにならないようにする方法を学びます。