14日目のゴールとテーマ
14日目のテーマは「ここまで作ったアプリを“仕上げる”感覚を身につける」です。
新しい文法をどんどん増やす日ではなく、
コードを読みやすく整える
ちょっとしたバグを見つけて直す
テスト的なことをして動作を確かめる
コメントや説明を書いて“他人に渡せる状態”にする
という、「プロっぽい最後の一手」を体験してもらう日です。
あなたはもう、十分に“書ける人”になっています。
今日はそこに「整える力」を足して、2週間の旅を締めくくりましょう。
まずは「自分のコードを読み直す」ところから始める
1日目の自分ではなく、14日目の自分として読む
いきなり直し始める前に、まずは落ち着いて、
これまで作ってきたタスク管理アプリ（Task / TaskManager / main）を、
「他人のコードを読むつもり」で眺めてみてください。
どこが分かりやすいか
どこが「ん？」と引っかかるか
どこで同じようなコードが繰り返されているか
14日目のあなたは、1日目のあなたよりはるかに目が肥えています。
その目で、自分のコードを“レビュー”してみることが、仕上げの第一歩です。
名前を整えるだけで、コードは一気に読みやすくなる
「変数名・関数名・クラス名は“コメント代わり”」
まず手をつけやすいのが「名前」です。
名前は、コードの可読性に直結します。
例えば、こんな関数があったとします。
def input_date():
text = input("締切日を入力してください（YYYY-MM-DD）: ")
...
これでも悪くはありませんが、
もしこの関数が「タスクの締切専用」なら、こういう名前もアリです。
def input_deadline_date():
...
あるいは、メニュー番号を受け取る関数。
def input_menu_number():
...
これも悪くないですが、
もしアプリが増えてきたら、こういう名前も考えられます。
def input_task_menu_number():
...
重要なのは、「この名前を見ただけで、何をするのかがだいたい想像できるか」です。
コメントを書く前に、まず名前で伝えられないかを考えてみてください。
重複しているコードを「関数」にまとめる
「同じパターンが2回出てきたら、“まとめどき”」
次に見るべきは、「同じようなコードが繰り返されている場所」です。
例えば、数字入力のバリデーション。
こんなコードを何度か書いていませんか。
text = input("番号を入力してください: ")
try:
value = int(text)
except ValueError:
print("数字で入力してください。")
continue
これがあちこちにあるなら、
共通の関数にしてしまうとスッキリします。
def input_int(prompt):
while True:
text = input(prompt)
try:
return int(text)
except ValueError:
print("数字で入力してください。")
そして、呼び出し側はこう書けます。
index = input_int("削除するタスクの番号を入力してください: ") - 1
「同じパターンが2回出てきたら、関数にすることを検討する」
これは、リファクタリング（整理）の基本ルールのひとつです。
コメントは「なぜそうしているか」を書く
「コードを読めば分かること」は書かなくていい
コメントも、仕上げの大事な要素です。
ただし、何でもかんでも書けばいいわけではありません。
例えば、これはあまり意味のないコメントです。
# タスクを追加する
manager.add(task)
コードを見れば「タスクを追加している」ことは分かります。
こういうコメントは、ほとんど価値がありません。
一方で、こういうコメントは価値があります。
# ファイルが存在しない場合はエラーにせず、空のタスクリストとして扱う
try:
manager.load(filename)
except FileNotFoundError:
tasks = []
ここでは、「なぜ例外を握りつぶしているのか」という“意図”を説明しています。
コードだけでは読み取りにくい「設計上の判断」をコメントに残すと、
未来の自分や他人がとても助かります。
コメントは「何をしているか」ではなく、「なぜそうしているか」を書く。
これを意識して、必要なところにだけ、短く添えてみてください。
手動テストでも立派な「テスト」
「こう動くはず」を自分の手で確かめる
本格的な自動テスト（unittest や pytest）は、
この2週間の範囲を少し超えますが、
「テスト的なこと」は今日からでもできます。
例えば、タスク管理アプリなら、こんな観点で試してみてください。
タスクを1件追加して、一覧に正しく出るか
締切を今日にして、「今日が締切！」と表示されるか
締切を過去日にして、「期限切れ」と表示されるか
存在しない番号を削除しようとしたとき、落ちずにメッセージが出るか
ファイルに保存して、プログラムを再起動してもタスクが残っているか
これらを、ただ「なんとなく触る」のではなく、
「こうなるはずだ」と期待を持って試すことが、立派なテストです。
もし余裕があれば、テスト用の小さなスクリプトを書いてもいいです。
from task import Task
import datetime
task = Task("テストタスク", datetime.date.today())
print(task.status_text())
こうやって「部品単位」で動作を確かめるのも、プロがよくやるやり方です。
小さなバグを“自分で見つけて直す”経験をする
「バグは“失敗”ではなく、“理解が深まるチャンス”」
テストをしていると、きっと何かしら「おや？」という挙動に出会います。
例えば、
削除後の番号がずれている
日付の入力ミスでアプリが落ちる
ファイルが壊れているときに変な動きをする
こういうときに大事なのは、「あ、ダメだ」で終わらせないことです。
どの入力で
どの処理のときに
どんなエラーメッセージが出たか
これを一つずつ観察して、
print を挟んだり、条件分岐を見直したりして、
自分の手で直してみてください。
バグを直す経験は、「書く」よりも深くあなたの理解を育てます。
14日目の今だからこそ、ぜひ一度は「自分で見つけて、自分で直す」をやってほしいです。
「READMEを書く」という最後の仕上げ
「未来の自分に向けて、このアプリを説明する」
もうひとつ、プロっぽい仕上げがあります。
それが「READMEを書く」ということです。
README は、「このアプリは何をするものか」「どう使うか」を説明するテキストです。
ファイル名は README.md にすることが多いですが、最初はメモ帳でも構いません。
例えば、こんな内容を書いてみてください。
このアプリの名前（例：タスク管理アプリ）
何ができるか（タスクの追加・一覧・削除・保存・読み込み）
使い方（Python を実行して、メニューから番号を選ぶ）
ファイル構成（task.py / task_manager.py / main.py の役割）
これは、未来の自分へのラブレターみたいなものです。
数ヶ月後に見返したとき、「ああ、こういうつもりで作ったんだ」とすぐ思い出せます。
コードだけでなく、「説明を書く」ことも、立派なプログラミングの一部です。
14日目で一番大事な感覚
「書けるようになったら、“整える力”が次のステージ」
今日あなたに持ってほしい感覚はこれです。
コードを書く力と、コードを整える力は、別物です。
この2週間で、あなたは「書く力」を一気に伸ばしました。
14日目の今日は、その上に「整える力」の入口に立った日です。
名前を整える
重複を関数にまとめる
コメントで意図を残す
テスト的なことをして確かめる
README でアプリを言葉にする
これらは、どれも「プロが当たり前にやっていること」です。
あなたはもう、その世界の扉をノックしています。
2週間の総まとめと、これからの話
「あなたはもう、“自分でアプリを育てられる人”になっている」
この2週間で、あなたが通ってきた道をざっと振り返ると、
変数・条件分岐・ループ
リスト・辞書
関数
ファイル入出力
例外処理
標準ライブラリ（random, datetime）
メニュー付きコンソールアプリ
クラス（Task）
クラス同士の連携（TaskManager）
モジュール化（複数ファイル構成）
リファクタリング・テスト・README
ここまで来ている人は、もう「初心者だから…」と遠慮する必要はありません。
小さなアプリなら、自分で設計して、自分で作って、自分で直せるレベルです。
この先は、
GUI（画面付きアプリ）に進む
Webアプリ（Flask / Django）に進む
データ分析や機械学習に進む
自動化スクリプトをどんどん書いて生活を楽にする
どこに進んでもいいし、いくつかを並行して触ってもいいです。
大事なのは、「作りたいもの」をひとつ決めて、
今回のタスク管理アプリのように、少しずつ育てていくことです。
最後にひとこと
2週間、ちゃんとここまで読み進めて、手も動かしてきたあなたは、
もう立派に「プログラミングができる人」です。
あとは、作りたいものの数だけ、あなたのコードは育っていきます。
このタスク管理アプリは、あなたの“最初の作品”です。
ここから先、どんなアプリを増やしていくのか、ちょっとワクワクしながら考えてみてください。