这次暑期学校的一个月时间都是用来开发一个项目。说是一个月，但实际用来编码的时间大约在三个星期。更具体的时间是早上八点半到下午五点半。最后这一个礼拜晚上也会拿来编码。
三个礼拜的时间说多不多，但这种经历倒是少有，踩了不少坑，也有不少收获，这里记录一下。
学习新技术
这次用的几个技术栈都是之前没有接触过的：前端React，后端Flask。项目后期还引入了Redux和useSWR。
我对学习新技术倒是蛮有热情，之所以选用这些也是出于想尝试些之前所没有接触过的事物。并且这次用到的技术栈，上手也都是比较容易的，除了Redux现在还是云里雾里，所以整体的开发体验下来并不会因为都是自己没接触过的技术而寸步难行。
但我还是发现了一个蛮大的问题：因为要赶最后的ddl，所以比较偏向于急于求成，看了看用法和示例就开始写了，虽然最后也确实能写出点东西，但总有种半生不熟的感觉，没有一种确确实实掌握的踏实感。
我还意识到，一个人的时间和精力是有限的，而技术却是日新月异的。所谓庄子所说的：吾生也有涯，而知也无涯。所谓贪多嚼不烂，就是这个道理。
DRY与AHA
这次项目中，后端几乎是我在负责的。但就是这样一个自己在开发的两千行左右的代码，到第三周的时候就还是偶尔会冒出想推倒重写某个部分的想法。
尤其是action这个部分。在这个项目中，我将用户收藏、评分、评论这三个功能抽象成一个action。自己刚开始写的时候还有点沾沾自喜，认为自己是做到了合理的内聚。
但后来却发现其中的弊端：当我想单独修改其中某一部分，因为其耦合性，导致我需要修改一些本不需要修改的代码。而到了项目后期，前端已经和后端对接已经完成百分之八九十。这时候修改一个核心功能，可谓是牵一发而动全身。改是能改，但是却不敢改，因为承担不起所需的时间成本。最后的解决方式是另外又写了几个方法，这就导致代码变得很丑。这时候就真切体验到了垒屎山是一种什么样的心情了。
回顾过去，思考如何在以后能尽量避免这种情况，我想有两个原则可能会起作用：
- DRY “Don’t repeat yourself"的缩写。我虽然有意识去将一些常用的代码封装为一个方法。但还是有不少代码，我选择了直接复制粘贴原有可用代码，并在其基础上进行些许修改。这样子固然省事，写的时候也很畅快，但后期想要修改时，却就要之前的偷懒付出相当的代价。而如若我之前多花些时间，将其封装，这样我的代码也就更方便修改。
- AHA “avoid hasty abstractions"的缩写。这个原则让我不禁想到一句话"premature optimization is root of all evil”。还是以action为例，如果我在将三个操作耦合成一个时多想一想，那会好许多。但话又说回来，怎么样才算是不仓促，怎么样才算不是过早。我觉得现阶段的我还是缺乏经验，所以下次遇到类似的情况时，我想我大概率还是会为自己的某个小聪明而沾沾自喜，并毫不犹豫地踏进给自己挖的又一个坑。
项目流程
这次的流程是采用瀑布模式，相比于上学期所使用的Scrum总觉得不得劲。我个人感觉最大的差异是在项目前期，连续多天都是花在写一些比较虚的文档。而这些文档：需求文档，设计文档之类，我们这几个甚至连初出茅庐都还不算的新人，没办法考虑得那么周到。而且多日时间上的付出只是一些文字，这样的体验感实在不好。
总的来说，这样的经历在我的学生阶段中算是比较一个独特的经历，一个月的时间也没有怎么白白浪费掉，对自己还是较为满意的。