この夏の学校では、1 ヶ月間プロジェクトの開発に取り組みました。1 ヶ月と言っても、実際にコーディングに使える時間は約 3 週間ほどです。具体的な時間帯は午前 8 時半から午後 5 時半までです。最後の 1 週間は夜もコーディングに充てられます。
3 週間という時間は多くはありませんが、このような経験は珍しいもので、多くの困難に直面し、多くの収穫もありました。ここに記録しておきます。
新しい技術の学習#
今回は、以前触れたことのないいくつかの技術スタックを使用しました：フロントエンドの React、バックエンドの Flask。プロジェクトの後半では Redux と useSWR も導入しました。
新しい技術を学ぶことにはかなりの情熱があります。これらを選んだ理由も、以前触れたことのないものを試してみたいという思いからです。また、使用した技術スタックは全体的に比較的簡単に扱えるものであり、Redux はまだ少し理解が曖昧ですが、全体的な開発体験は、自分が以前触れたことのない技術によって足止めされることはありませんでした。
しかし、私は大きな問題を発見しました：最終的な締め切りに追われるため、急いで成果物を作ろうとして、使い方や例を見てからすぐに書き始めました。最終的には何かを書くことができましたが、いつも半分しか理解していない感じがあり、確固たる理解感がありませんでした。
また、個人の時間とエネルギーは限られている一方、技術は日々進化しています。庄子が言ったように、「私たちの生は限りがあり、知識は限りがありません」。多くを欲しがることはできませんが、それがこの原則です。
DRY と AHA#
今回のプロジェクトでは、バックエンドの開発をほぼ一人で担当しました。しかし、このような自分自身で開発した約 2000 行のコードでも、3 週目になるとまだ特定の部分を書き直したいという考えが時折浮かび上がります。
特にアクションの部分です。このプロジェクトでは、ユーザーのお気に入り、評価、コメントという 3 つの機能を 1 つのアクションとして抽象化しました。最初に書いた時は少し自己満足に浸っていましたし、自分自身が適切な結束を実現したと思っていました。
しかし、後でその欠点に気付きました：特定の部分を個別に変更したいと思った場合、その結合度のために変更する必要のないコードも変更する必要があります。プロジェクトの後半になると、フロントエンドとバックエンドの統合はほぼ完了しています。この時点で核心的な機能を変更することは、全体を揺るがすことになります。変更はできますが、時間的なコストを負担することができません。最終的な解決策は、別のメソッドをいくつか書くことでしたが、これによりコードが非常に醜くなりました。この時、私は本当に「山を築く」という気持ちを体験しました。
過去を振り返り、将来的にこのような状況をできるだけ避ける方法を考えると、2 つの原則が効果的かもしれません：
- DRY
"Don't repeat yourself" の略です。私は一部の共通コードをメソッドとしてまとめる意識はありましたが、まだ多くのコードがあり、使用可能なコードを直接コピーして少し修正することを選択しました。これは手間が省けるし、書くときもスムーズですが、後で変更しようと思った場合、以前の手抜きが相当な代償を払うことになります。もし私が以前に時間をかけてそれをまとめていたら、コードを変更するのも簡単になったでしょう。 - AHA
"avoid hasty abstractions" の略です。この原則は「早まった最適化はすべての悪の根源である」という言葉を思い起こさせます。再びアクションを例に挙げると、3 つの操作を 1 つに結合する際にもう少し考えると良かったかもしれません。しかし、言い換えれば、どのようにして急いでいないと言えるのか、どのようにして早すぎないと言えるのか。私は現時点では経験が不足していると思うので、次回同様の状況に直面した場合、おそらく自分の小さな知恵に満足し、自信を持って自分が掘った次の落とし穴に飛び込むでしょう。
プロジェクトの進行#
今回の進行はウォーターフォールモデルを採用しましたが、前学期に使用したスクラムと比較して違和感を感じました。個人的に最も大きな違いは、プロジェクトの初期段階で数日間連続で比較的抽象的な文書を書くことです。要件文書、設計文書など、私たち新人にもまだ経験不足のものを考慮することはできません。また、数日間の時間投資はテキストだけであり、このような体験は非常に良くありません。
全体的に言えば、このような経験は私の学生時代においては比較的ユニークなものであり、1 ヶ月の時間を無駄にすることはありませんでした。自分自身にはかなり満足しています。