システム開発入門の第13週目では、1年生が自分のアプリを何度も動かし、見つけた不具合を直す作業に取り組みました。
前週に始めたオリジナルアプリの実装を進めながら、動かして確かめ、原因を探し、コードを整える流れを経験した授業です。
今回の学びは、次の三つに分けられます。
- テストによって、意図した結果と実際の動きの違いを見つける
- デバッグによって、不具合の原因を探して修正する
- リファクタリングによって、条件や変数名、処理のまとまりを読みやすく整える
プログラムは一度で完成しなくてよい
バグとは、自分が意図した結果と実際の動きが合わない箇所です。
バグが見つかると失敗したように感じますが、どの入力や処理で違いが生じるかを確かめれば、直すべき場所を絞り込めます。
「プロのエンジニアでも、最初から完璧なコードを書く人はいません。作ってみて、動かして、直すことを繰り返すのがプログラミングです」
田中先生
先生は、バグが出たことではなく、発見できたことを次の一歩として捉えるよう生徒たちに伝えました。
入力を変えてアプリの動きを確かめる
テストは、入力を変えながらアプリを実行し、結果が想定どおりになるかを確かめる作業です。
授業では、普段どおりの入力だけでなく、空欄や同じ名前の繰り返しなども試しました。
| 観点 | 試すこと | 確認すること |
|---|---|---|
| 期待する結果 | 通常の入力を行う | 想定した結果が表示されるか |
| 条件分岐 | 条件に当てはまる値を入力する | 対応する処理が選ばれるか |
| 空欄 | 何も入力せずに進める | 想定外の動きが起きないか |
| 重複 | 同じ名前を繰り返し入力する | 結果が不自然にならないか |
「あれ、100点って入れたのにBランクになる……？」
「条件の順番、ちょっと確認してみようか」
生徒Aと田中先生のやり取り
この場面では、入力した値だけでなく、判定する条件の並びも確認の手がかりになりました。
不具合の原因を一つずつ探す
デバッグは、テストで見つけた不具合を同じ手順でもう一度確かめ、原因となる箇所を探して修正する作業です。
授業では、次の順序で一つのバグに向き合いました。
- 同じ入力を使い、不具合が起きる場面を確かめる
print()で途中の値を表示し、想定と違い始める場所を探す- 条件や変数の位置を見直して修正する
- もう一度実行し、想定した結果になるか確かめる
授業中には、NameErrorやIndexErrorも現れました。
NameErrorは、使おうとした名前をプログラムが見つけられない場合に表示されます。
IndexErrorは、リストなどに存在しない位置を参照した場合に表示されます。
エラー名だけで判断を終えず、変数の場所や条件を見直し、途中の値を確かめることが原因の特定につながりました。
「あ、分かった。変数の場所が違った！」
「その気づきが一番の成長だよ」
生徒Dと田中先生のやり取り
修正後のコードを読みやすく整える
リファクタリングは、今回の授業では、不具合を直した後に条件や名前、処理のまとまりを読みやすく整える作業として扱いました。
生徒たちは、次のような見直しに取り組みました。
- 重複しているif文の条件を整理する
- 役割が伝わる変数名に変更する
- 繰り返し現れる処理を関数にまとめ直す
- 必要な箇所にコメントを加え、後から読んでも処理を追えるようにする
「コメントを書いたら、自分でも読みやすくなった」
「最初はうまく動かなくても、直していくうちに愛着がわいてきた」
生徒Bと生徒C
テストと改善を繰り返して完成へ近づける
テストは不具合を見つける作業、デバッグは原因を探して直す作業、リファクタリングはコードを読みやすく整える作業です。
三つの作業を順に進めることで、生徒たちは「動いたかどうか」だけでなく、「なぜその結果になるのか」までコードを読み直しました。
「エラーは成長のチャンス。思い通りに動かないときこそ、プログラマーとしての腕が試されます。直せたという体験は、何よりの力になります」
田中先生
次回はアプリの最終仕上げへ
次回は、動作確認、メッセージの調整、デザインの見直しを行い、人に使ってもらうための準備へ進みます。
続きは、第14週目のアプリ完成とテストプレイ準備で紹介します。
この記事に関連する株式会社greedenの取り組み
不具合を見つけ、原因を確かめ、改善を重ねる工程は、使いやすいシステムを育てる土台です。株式会社greedenは、Webシステム開発で要件定義からテスト、リリース後の保守改善まで一貫して支援しています。