软件开发绝对不是一个人，一种思想，一堆代码就能完成的事情。有的人开发出的东西叫产品，有的人开发出的东西只能叫一堆代码文件，文件里还充斥着大量的糟糕实现。我觉得只有能领悟到工程层面，我们才能算是成为了软件工程师，否则我们只不过是信息时代里的又一群码农而已。

何为工程

说起来，我的老爸是土木领域的工程师，很小的时候，我就看到他伏案去看一张张图纸，去翻一页一页的造价表，然后去现场看各个工程的施工情况。我也跟着他了解了一些有关的内容，虽然计算机对于我的吸引力更大促使我今日走上了这条道路，但是一规一矩的工程师思想还是对我产生了较大的影响。
与之前的那些作业相比，这次的作业量任何人想凭借自己的一己之力Carry全场都是不可能的。解决问题的重点也从算法偏向了工程学。三种项目，无论是众包也好，大学生竞赛平台也好，还是客服平台也好，如果还想用原先写大作业的写一步看一步的想法去做完的话，到后期，甚至到中期，项目就会面临重构的危险。可以说，一个架构师顶上做完全局设计也好，四个人合作商量得出也好，项目开始前就必须能看到项目的结束是对项目架构设计的基本要求。一个项目，尤其是非长期（以年为单位计算）维护的项目，在短期内其核心架构一定不会有很大的变化。本次项目，由于条件和能力限制，我们所有人的设计都是单点服务的架构设计，难度远小于分布式的服务架构设计。没有清晰的架构，最后写出来的根本就不能叫工程。
而架构设计只是工程中重要的一步，从工程的层面去考察一个项目的时候，工程的质量好坏还取决于很多评价因素。对于软件工程来说，项目需求是否明确（前期需求工程质量如何），是不是解决了需求，还是只是一些臆造。对于项目中业务逻辑的实现是否合理，有没有会造成全局性能短板的糟糕实现。对于业务模型的抽象是否合理，都会影响项目的成败。而另外，项目的代码质量，项目的配置管理是否清晰，项目的进度控制是否合理，完成的功能是仅满足需求还是能有更好的实现，all those matters。
一个优秀的工程绝不仅仅只是一个优秀的作业，优秀的工程的产出一定是一个优秀的能用的产品，或者有潜力能变成优秀的软件的Demo级产品。

何为技术

这次我们的交付产品的技术方案做的比较充分，可能在很多人看来，我们用了很多超前的东西，但是实际上，我们只是比别人多看了更多的选择，并选择了最适合自己的方案。对于最终交付来说，只要选用的方案合理，不违反相应的协议规定，最终能满足功能，就算是合理的技术选型方案。选择好了方案后，后面要做的事情，就是在选定的技术方案下将选择的技术项能力发挥到极致。做技术方案不是炫技，只是选择合适的刀。有些团队太执着于造轮子的话，最后就会面临难以按时交付的窘境。

何为团队

团队合作是一个互相撑起来的过程。我很自信的讲，可能交付的时候，有些组做出的产品从表现上没有比我们逊色多少，但是从团队合作上，我们绝对是当之无愧的第一。事实上，我们团队的四个人，除了灰灰和尚明是室友之前有过合作之外，其他人都是第一次相互合作，但是整个合作却异常的顺利。团队的成员之间能互相地撑起来，互相支持，团队才能让每个人都发挥出更多的潜力。领导团队的人必须知道均衡压力，必须做出为团队必须的牺牲和让步，必须深刻理解自己的团队成员的优点和短板。优秀的团队在做完产品之后，对其成员也会有影响，我发现比起项目刚开始时，项目交付时的灰灰和尚明有了更多的技术自信和表现力，能将自己的想法更好的外化。