【个人阅读作业】

一、软件工程团队项目感想

两个月的开发一晃而过，我们经历了两轮迭代，完成了我们的产品——“北航Clubs”。这是一个为社团与学生提供服务的网站，这个idea一年前就诞生在我的脑海中，最终经由软件工程课程的开发机会，我完成了自己这么久的执念。同学都戏称完成了夙愿。

 

一年前，我刚上大二，在宣传部接手凌峰社社团管理事务。从这个身份的角度，我看到了北航学生社团活动的四难：

1.百团大战之后，学生想加入社团难

2.学生如果不及时查看海报，想发现并参与自己感兴趣的活动，难

3.社团想要让学生了解自己、了解自己的活动，难

4.社团想要管理社员、进行招新，种种事物繁琐，难

 

随着对上述困难的切实感受，我越发感觉到，一个可以连接起学生与社团的平台，会帮助很多希望充实课外生活的学生，方便几乎所有需要组织活动、运营管理的社团。

 

自然而然的，我们选择“北航Clubs”作为软件工程团队项目。网站的架设与研发历时两个月，时间不短，但是期间很多精力都不得不投入编译、数据库、数学建模以及几科期末考试。这对项目的进展产生了很大的阻碍，也让我们在最后的两周连续刷夜才将项目最终完成。值得庆幸的是，我的六个队友：王开、徐丞、王春阳、杨墨犁、付帅、王若愚都非常非常给力，没有我们的齐心协力，我们不可能完成这样大的一个网站。

 

春阳做事认真负责，最后答辩前，网站功能还有小bug，团队焦虑的时候会为没有人做的“文档”做准备。春阳是个做事规律，就如他生活习惯规律一样，两轮开发中的scrum都做的很用心。日常开发，很多细节，比如对API实现正确性的质疑与修改等，都体现了责任心与细心。

 

王开在项目中很主动，短信与邮件服务这块他了解最深也基本由他负责。印象最深的是一轮迭代发布前一晚，王开和我、还有付帅一起把短信、邮件功能开发完成。第二天的一轮收功演示中取得很大的效果。

 

徐丞学习东西，做开发都很高效，第一轮开发开始，大家都不会rails，徐丞学习并架起来第一轮迭代的服务，和春阳、王开一起完成了后端的建设。两轮开发中，徐丞做出的贡献都相当大。

 

付帅，前端开发的主力，通过快速地学习，迅速理解了HTML、CSS与JS，并用JS实现了ajax与后端API接入，完成对Ueditor的学习与使用并成功运用入项目，解决开发时的一大难题。

 

杨墨犁，前端开发的另一主力。她是团队中唯一的女生，有着寻常女生不具备的努力与实力。对她第一印象是执行力，跟她说过的事情往往很快得到响应，交给她的任务，她的完成速度让我意外而惊喜。原本给她规划的任务是做Ui设计，后来却成了前端界面的主要开发者，使用SemanticUI，完成了第一轮界面的建设与第二轮部分界面的设计开发。

 

王若愚，前端开发的实干家，他在开发中主要负责JS代码的编写，实现页面的逻辑功能。他往往用最朴素的方法实现功能，实现速度很快。有时因为API不正确、JS代码不熟悉等原因而气恼，但交给他的任务他一定会保质保量地完成。

 

两个月的开发，我觉得最幸运的就是有这么一群靠谱的队友，前端我可以放心地交给付帅若愚，界面交给杨墨犁，后端交给徐丞王开王春阳，所有事情告诉他们就不用重复或催促，任务能完成地很好，也时时有给力队友主动的开拓一些新的好用的功能、特性。在我面对前后端开发的压力时，他们能站住来，让我心安，在我面对文档、软工杂项事务心烦而无力时，一点小的提议，伙伴们给以支持，就有了继续走下去的动力。在面对第二天答辩的DDL，刷夜实现新功能时，我费尽力气完成了短信服务资格（里面有一些波折，差点放弃短信服务），并完成了发短信API的ruby版demo。但已经是凌晨四点，心神俱疲，一切已晚。却没想到，王开付帅都没睡，他俩接过了接力棒，一个完成了API，一个在前端完成页面逻辑，就这样，给力的短信与邮件功能如期上线。一切都来的那么意外，让人满满欣慰与鼓舞。

 

最后再说一下我自己。第一轮开发，我是团队中唯一有相关技术经验的人，为项目做了整体规划与技术架构设计。在做架构选择时，确实涉及到非常多的问题。我不是经验丰富的老司机，顶多算一个上过路的小司机，却要在众多框架，技术实现路线中寻找适合本项目的结构，这给我很大挑战，我第一次进行了各种技术流派之间的比较，最后选择前后端API交互，后端MVC，前端MV*的技术框架，后端选择rails，前端则决定使用HTML+CSS+JS这样底层语言实现。第一轮对前端没有做太多技术规划，这一方面是相比较而言我在做设计时更担心后端服务，一方面是我对前端开发技术与主流框架不很熟悉。时间检验后，我对前端的不重视让我们走了一些弯路。

 

到第二轮开发时，在AJAX、后端API开发都不成问题后，UI与前端界面已经成为制约团队开发的技术瓶颈。前端界面的好看与易用程度成为我们最大的关心。我意识到前端的重要性，学习了React和vue.js两个前端框架，看了AngularJS等，真正了解了前端开发思路。我准备采用vue.js，却发现前端彻底重构代价太高，大家时间精力不足的情况下，前端重构的想法无法实现。意外往往出现在你轻视的地方。如果我在一轮开始就使用vue.js，我们的前端开发会更快地走上正轨，而不用受制于重构的困境。

 

最后，我挑下前端界面重担，二轮开发中负责实现用户相关界面。在这个实现过程中，代码布局、代码结构上都追求与主流代码实现相似，最起码代码看着不要那么“low”，界面也向“微博”的UI看齐，实现了微博UI的各种效果。随着前端工作逐步深入，又加入了jQuery和juicer作为前端逻辑控制工具

 

二、对《构建之法》阅读问题的回答

1.需求是什么，需求的规范需要明确吗？

需求是对自己目标产品的抽象，它既描述了产品的种种特性，也分条目描述了产品的功能，有为开发提供指导的作用。需求必须明确，否则会导致利刃迷失方向。

 

最开始，“北航Clubs”立项，这个项目的产品目标是服务社团，为此我们从用户使用角度，规划了许多实用需求，如：信息发布、活动发布、活动报名、社团报名与社员管理、群发短信、群发Email、社团网盘、收缴团费、社团申请借用教室以及社团文化产品电商等。

随后，深入开发后，我们又提出了活动与资讯评论、用户实名验证登陆、查看个人信息与修改个人信息、找回密码、站内信等需求。

一轮开发之后，二轮开发之前，我们又设想了APP端的需求量以及需求实现难度，做一个安卓和iOS的应用也在可以承受范围内。以及web端界面UI的重新设计，好看易用响应快。

 

我们当时提出的这些都是需求，制定一个需求有两方面的考虑，一是产品定位与用户对该需求的迫切程度，二是需求实现的难易程度以及团队现实情况。可以说，需求既是对产品的规划，也是对技术实现的计划。

 

比如说，开发安卓、iOS的需求，很切中用户痛点，也符合产品覆盖web、安卓、iOS平台的设想，但需求难度太高，最后也无法实现。

另一种，申请借用教室，这个需求也有一定用户需求，但与我们“社团与学生沟通平台以及服务社团”产品规划偏离稍远一些，于是也没有给予实现。

 

实际上，提出需求，正式脑洞打开的时候，肯定会有大量合理的不合理的需求被提出来，但对于需求，需要有需求分级，确定下那些需求应该被尽快实现，哪些需求无关紧要。最终项目的实施是按照需求优先级予以完成的。

 

需求规范，我认为需求更像一个idea，一个需求的规范就是抓住用户痛点，尽可能地细化，并且描述清楚，无歧义。需求需要有用户主体、用户行为、期望功能等几个要点的明确说明。

 

2. 一个人开发效率非常高，多人开发，个人效率随团队人数上升而直线下降，我们一般需要将大项目拆为小项目，使协作耦合产生的效率负影响减少。但是，谁来做项目拆解工作呢？

 

这一点我深有体会。拆解工作的人，一定是对项目整体有经验的人，最好是架构师。架构师熟悉各方面开发过程细节，拆解大任务为小任务，最重要的是工作间依赖要少，即使存在依赖要方便沟通，同时为可能存在的依赖进行预估、记录，提前准备解决方案，以防止两个子任务相互干扰。

 

在项目开发过程中，我实际成为“北航Clubs”的架构师，通过设计前端——API——后端的架构模式，将网站开发任务拆解成前端后端两部分，并准备API文档作为前后端相互依赖的解决方法。

 

3. PM应该是技术大牛，还是其他哪种人？

首先，PM应该有产品思维，要懂得需求，懂得用户痛点，懂得UI审美，这样产品经理才能将开发团队引领向正确的方向。

其次，PM应该有一定的技术基础，但不应该是技术大牛。技术大牛，能力大，责任也大，开发任务不知不觉就会重，定会顾开发顾不上产品管理。但是PM也不应该是技术小白，不然他提出的需求、产品设想很容易脱离团队实际情况，脱离于技术实现能力，项目因此会受到打击甚至停滞。

 

我是团队的PM，在一轮迭代中我不写代码，而是负责架构与督促管理，一轮任务进展顺利。二轮迭代，我成为前端开发主力，团队开发效率提高了，产品质量也有改善，而我却无力再负责团队管理，很多后端的事情我都不清楚，只能让前端其他同学直接去找后端同学沟通，团队整体时间安排受到影响。

 

4. 敏捷开发会导致代码重构次数很多，或者文档不全导致代码可读性差吗？

会的。

在我们的开发中，代码重构时有发生。

一轮开发中，需求是“建设社团活动分享平台”，所以平台上文章全部是活动。

二轮开发，将文章区分为“活动”与“资讯”，资讯没有报名资格，为实现二轮的需求，我们不得不将前后端文章部分的相关代码重构，区分活动与资讯后再重新部署。

另外一个是，一轮开发时，需求只是“短信邮件通知功能”，二轮时变更为“短信邮件与站内信一起作为通知功能并可以查看历史通知”，这使得短信、邮件被取消，新建一个统一的“通知”实体，下分三类子实体（短信、通知、站内信），也导致了大量的代码重构。

而对于UI需求的变更，一轮为开发速度设计的UI在二轮被迫重构，一轮开发的前端学生界面完全弃用。

 

文档可读性差倒是没有，我们的文档主要是API文档，而且是时时更新。可能有时没及时更新，却不会出现可读性差的问题。代码方面，会有一定影响，因为部分代码是从之前的逻辑中拷贝过来的，但总体影响不大。

 

5. 团队中，代码风格规范与设计CSS风格规范应该怎样制定？会发生变化吗？

这是个很好的前端问题。

代码风格规范，主要包括：

1.缩进四字符

2.命名遵循驼峰命名法

3.代码封装成块、成类，前端代码将JS代码封装在.js文件，页面JS代码同一卸载HTML的body最后的一个script中。所有页面元素绑定事件函数在一起集中实现，JS全局变量同一写在该script最开头

4.Ajax书写，API报错等代码由API文档规范约束

5.因为项目比较小，CSS样式全局共享，统一放在header2.css文件中，以避免CSS冲突。（如果项目做大，将使用SASS完成CSS功能）

代码风格制定后，会很稳定地存在很长一段时间，除非项目大规模重构，否则代码规范不会被彻底取代。

 

CSS风格：

当初阅读《构建之法》时，心中对前端开发与UI设计之间的配合有不明晰的地方。比如UI设计出曲线等元素，前端人员可能无法很好的实现，前端容易实现的样式，UI设计由有可能无法注意。这两种职能交叉点就在CSS样式，理想状态是UI出设计图并规定出各个位置CSS样式属性。但这样太难为设计师了，可行性不好。故而我对CSS风格规范的解决方案有疑惑。

经过一定的实践，我了解到前端开发中，设计师只负责出图，具体样式实现全部由前端工程师负责。但是设计师应该出一套CSS风格规范，如网站的配色方案、UI交互方案以及动画实现方案。

CSS风格规范会发生变化。设计师可以更新方案，而前端工程师应做好CSS样式管理工作，可以快速有效地应用新的CSS设计方案。

 

6. 测试驱动开发的开发方式中，测试用例无法考虑代码中的bug、逻辑不严密的地方，应该怎样修补？

 

一个程序的状态机应该是可监控的有限的，这种情况应该是将多种逻辑代码杂糅在一个程序体，需要将该程序分解为若干子程序。

 

 

7. PM应该要求团队中的每个人都达到“极限编程”的状态吗？

 

我们团队软工开发过程中时常会有“极限编程”状态，大部分原因是DDL太紧，也有一部分原因是无法阻挡控制的时间分配问题，此时必须充分调动起队员的战斗力，完成任务。“极限编程”状态下，项目进展会非常快。

 

PM应该为软件工程中可能遇到的各种突发情况做好备案，“极限编程”是备案之一。PM应当尽可能避免“极限编程”，不到十分紧急，最好不要使用。但是如果真的遇到问题，PM应当要求队员“极限编程”完成任务，保证软件工程顺利完成。

 

三、产生的新问题

团队文档应该交由专人负责吗？

这个问题的产生源自于我们团队博客团队展示效果都比较缺乏。

我们日常开发过程中，不够注重记录，也没有专人强调提醒那些需要被记录，所以到最后博客撰写的时候，常常还需要重新收集素材。除了素材，语言技巧、排版技巧、展示技巧都是我们缺乏的，我们在这方面的短板影响了各位同学。大家无法找一个人专人负责，只好集体负责，这又会导致一定程度的文档不规范与风格不统一。

实际上，文档交给专人负责也会有困难，难点在于很多开发过程中的记录，如果文档负责人不清楚开发过程，也就很难了解哪些东西需要被记录。说到底这也是经验的问题。

我觉得文档应该由一人牵头负责，自己分内负责文字排版与展示，分外需要提醒、督促其他队员记录必要的信息并收集这些信息。这个工作我想不是很轻松的，我在以后的软件工程项目中会加强考虑。

 

四、软件工程与博客论文再体会

 

1.瀑布模型与敏捷开发

我们采用的方式是敏捷开发

我感觉敏捷开发很自由，在项目启动的前期大家都有相当高的自由度与活跃度，但随着项目不断发展扩大，敏捷开发带来的文档不足、相互间依赖与不稳定会降低这些自由度与活跃度。最终我们二轮还是书写了大量的文档，包括较一轮复杂全面地多的API文档。

所以我觉得瀑布模型和敏捷开发并不是一个二选一的问题，而是即使你选择一个，在实践中，你也会情不自禁地偏向另一个，最终达到一定的平衡与饱和。

 

2.大泥球

二轮迭代开发中，深刻地体会到大泥球。

一轮迭代，对前端代码要求比较宽泛，以实现功能为目的。

一块代码完成后，后续的跟进维护没有跟上。

存在大量冗余代码

JS DOM操作随处都有，使用的方法不够简洁

这些问题制约了二轮开发阿德效率。最终，出于重构学生界面前端的想法，我们对学生界面前端进行重构，完全抛弃“大泥团”，实现了新一版前端界面，完成了代码的精简、模块化、规范化等。

大泥球对后续的维护和开发带来的影响是致命性的，绝对不能让“大泥球”进入正式代码，要即使铲除——重构，或者改写精简。

 

3.银弹

 

软件工程确实是不存在银弹的

我们找到比较好的架构与工具，在一轮开发中队员也积累了较充分的基础。可软件工程还是在DDL前一天完成开发，这就是软件工程的“银弹”。可以说，尽管有经验，有好工具，软件开发工作中的复杂性、一致性、可变性和不可见性依然是不可变的

 

五、在实践中学习到的知识点

 

需求：需求分析、需求分级

设计：API设计、UI设计、技术框架选择

实现：前端技术（HTML、CSS、JS），后端rails技术，短信群发、邮件群发功能

测试：Fiddler前端测试工具

发布：学习软件的部署，从test环境到product环境，需要进行环境的配置。

维护：学到htop等服务器监控、错误处理命令

 

转载于:https://www.cnblogs.com/haoj/p/5123110.html