01月07, 2018

软工3项目交付总结

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

何为工程

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

何为技术

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

何为团队

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

本文链接:https://blog.magichc7.com/post/ideas_for_SE.html

-- EOF --

相关评论