標準的なアプローチの問題
Javaを実行することがわかったとたんに、宿題と制御タスクの準備と確認の問題が私たちの前に出てきました。 その時までに、私たちは学生としてさまざまな大学を訪問し、DZをテストするためのさまざまなアプローチを試してみました。たとえば、「USBフラッシュドライブを持ち込む」、「紙に印刷する」などです。 その時の最も便利なアプローチは、AUで実践されたものであるように思われました。生徒は電子メールで決定を送信し、教師とのやり取りに入ります。 ただし、このアプローチでは、すべてが好きではありませんでした。
- 教師には多くのルーチンがあります。解決策をコンピューターに転送し、実行し、テストし、レビューし、書面にすべてのコメントを書く必要があります。
- 追加の生徒の待機および教師のロード、として 生徒は、教師に決定を送信し、彼からの回答を待つだけで、決定の正しさを完全に検証できます。
宿題をAUに送信する別の方法は、共有リポジトリを使用することです。 その中で、生徒ごとに、宿題を行う場所に個別のディレクトリが作成されました。 このアプローチは、部分的にルーチンを排除しますが、教師はまだ解決策を手動でチェックし、メールでコメントを書くため、学生はまだ解決策に問題があることを理解するために回答を待つ必要があります。
少し考えた後、「VCS +パブリックCIサーバー+コードレビュー用ツール」を組み合わせることで上記の問題をすべて回避でき、サードパーティサービスを使用することでこれらすべてを設定する必要がなくなると判断しました。
仕事の組織
リポジトリを次のように整理することが決定されました。各タスクについて、実行する必要のある説明を含むREADMEを含む個別のブランチと、ソリューションバックボーンとそのテストを含むMavenプロジェクトを作成します。 学期の初めに学生はリポジトリの分岐を作成し、目的のブランチに切り替え、変更を行い、コミットしてプルリクエストを送信します。 PRは自動的に収集およびテストされます。 テストが失敗した場合、生徒は作業を終了する必要があります。 すべてが順調であれば、教師はコードをチェックしてコメントを残すか、PRを閉じてマークを付けます。
学生ごとに単一のリポジトリとディレクトリを使用するアプローチとは異なり、このような組織は、変更をマージするときに起こりうる問題を排除し、リポジトリをクリーンに保ち、破壊行為からも保護しますが、幸いなことに、AUにはこれに先例はありませんでした。
サービス選択
VCSサービスGithubを使用すると、すべてがシンプルで明確になりました。 歴史的に、私たちとほとんどの学生の両方がそこにアカウントを持っていました。 これが重要な長所になりました。 さらに、コードをレビューしてコメントを残すことが決定されました。
CIサービスでは、事態はもう少し複雑でした。 当初、私たちはTravis CIを使用することにしました。 ただし、時間が経つにつれて要件が変わりました。タスクを使用してリポジトリから直接利用できるオープンテストに加えて、生徒がさまざまな微妙な点や境界ケースについて独立して考えることができるように、さらにクローズドテストを作成したいと考えました。 閉じたリポジトリを作成し、ビルドを変更してこのリポジトリをメインモジュールのサブモジュールとして追加し、暗号化された変数をユーザー名とパスワードで追加して、Travisが閉じたリポジトリを複製できるようにしました。 生徒の1人がプルリクエストを行おうとするまで、すべてがうまくいきました。 暗号化された変数はPRのビルドから入手できないため、これを確認しませんでした。 残りのCIサービスをすばやく検索すると、Semaphore CIが見つかりました。 Travisとは異なり、プライベートリポジトリにアクセスするためにビルドで使用できる秘密のSSHキーのダウンロードをサポートしています。これはまさに必要なものです。
落とし穴と短所
最初に遭遇した問題は、奇妙なことに、Git自体でした。 連中は、Githubへの決定の提出に必ずしも成功しませんでした。 これは、フォークを更新してリモートとして新しいブランチに切り替えた後、フォークではなくメインリポジトリがそこに設定されたためです。 この微妙さは別に言及する価値があります。
2番目の問題は、コミットとPRの命名規則の欠如でした。 その結果、最初の宿題を終えた後、「fix」、「1st hw」、「my homework」などの名前のPRができました。 全員がプロファイルを持っているわけではないため、ユーザー名で学生を識別することはほとんど不可能であるという事実により、これはさらに複雑になりました。 後続のタスクについては、もちろん厳格なルールを導入しましたが、初めて汗をかかなければなりませんでした。
このアプローチの主な欠点は、すべてのタスクを意味のあるテストで作成できるわけではないことです。 たとえば、一般的な割り当ての1つには、関数型Javaの記述が含まれていました。 このタスクのコードの量は最小限であり、その主な魅力は、関数の適切な署名を考え出すことでした。 定性的にテストするには、複雑な階層を考え出し、さまざまなトリッキーなケースをテストする必要があります。 作業を手動で確認するよりも時間がかかります。 また、テストの作成が困難で費用のかかるタスクには、マルチスレッドのタスクが含まれます。
かなり多くの人々は、他の人のソリューションの可用性をマイナスと考えています-隣人がすべて準備ができていて、配達されていれば、DZを自分で書きたい人です。 個人的に、私はこれがマイナスだとは思いません。不正をしたい人は誰でもそれを行う方法を見つけるからです。
結論と将来の計画
このアプローチの経験は前向きであると考えることができます。 最初はいくつかの問題や不規則性がありましたが、学期の半ばにはすべてが落ち着き、正常に機能していました。 解決策を確認するのは私たちにとって便利でした。そして、彼らがそれを取るのが便利であることを願っています。 いずれにせよ、学期の結果によると、10人の私のグループでDZを渡すこの方法に不満を表明したのは1人だけでした。
このアプローチの論理的な開発は、自動スタイルチェックや静的コード分析など、他の有用なサービスを追加することです。 また、PRのレビュー担当者を自動的に割り当てるようにGithubに教えることも非常に便利です。 そして一般的に、完璧に制限はありません。