软工实践（二）——构建之法读后感

一、前情提要

• 在完成软工实践第一次作业之后，老师在我的博客中评论布置了一个任务，用一周的时间通读构建之法，然后提十个问题。本来我还担心这本书会不会很枯燥，能不能按时间看完，没想到这本书看起来妙趣横生，让我欲罢不能，里面有很多的小故事和案例不仅生动有趣，还包含了软件工程这门学科的一些专业知识。看完之后收获良多。以下是其中的一个十分有趣的片段：
  
  
  
  

• en，争取做一只猪或一只鸡，而不是做一个鹦鹉，O(∩_∩)O。

---

二、结合我自身

我的开发经历

• 在大二暑假时，十分有幸的加入到了一个初创团队中进行开发，团队由我——程序员，老板——创业核心，美工——图片设计，运营——业务推广，一共四名成员构成。
• 我的主要职责是和老板沟通，商量好需求、并设计产品和编码。这真是一个粗糙的团队啊（看完构建之法后的感慨）。
• 但是我们有共同的远景，那就是提供一个好的可信的平台，商家发布兼职，同时用户可以接受兼职。传统的兼职是以群为基础的，商家在群里发兼职招人广告，但是这些广告良莠不齐，其中甚至包含一些欺诈的广告，商家也很难招到人。我们就是受这样的痛点启发，想要开发一个产品，贯穿兼职的招人、完成兼职、发布工资的过程。在需求分析阶段，我们仔细的分析了传统的兼职招人过程，设计了我们产品的一些主要功能（发布兼职、查看兼职、制作简历，接受兼职、工资结算，钱包），还有一些附加功能（积分商城、排行榜、任务系统等）。我们并没有对用户进行问卷调查，依靠着对一些从业者（兼职中介）的调查就开始了工作。
• 现在看完了构建之法，我发现我们的一个整体需求分析还是大概符合NABCD的，我们分析了用户的需求Need（商家的、和兼职用户的），我们找到了思路来解决用户的痛点Approach（搭建平台贯穿整个兼职流程），我们清晰的知道这么做的好处Benefit，能帮到用户哪些地方，同时为了做的更好和吸引用户，我们还开发了（积分商城、排行榜、任务系统）的功能，我们研究了我们的竞争产品Competitors（斗米兼职、大学生兼职、南姐兼职等），发现他们虽然也实现了兼职的发布和接受过程，但是其上的虚假信息还是很多，而且没有我们的福利系统，我们计划使用微信小程序平台来制作应用，因为这样更方便我们推广Delivery和用户分享。
• 我们的团队是典型的以老板驱动的流程，并且因为开发的过程因为只有我一个人，没有可以参考的或者学习的人，我就就着本能来进行了开发：
  • 没有写需求文档，和Spec
  • 进行了简单的数据库设计，画了思维导图，但是没有画UML图、ERD图、等其它任何图
  • 进行了项目的进度规划，但是没有仔细的规划每一天
  • 没有使用软件进行原型设计，但是简单的画了界面外观草图
  • 没有进行单元测试，但是每一个组件开发完成后会进行功能测试，基本页面制作完成后我进行了场景测试
  • 没有遵循瀑布模型、而有些类似敏捷开发，在产品上线后，我们设计了新的功能，在业务运行的同时进行产品的迭代开发
  • 使用了源码管理git，但由于程序员只有我一个，其中并没有遇到什么冲突问题
  • 注释和代码规范

这是我们的产品

欢迎使用并提意见，因为老板在外出差，现在暂停了业务上的推广，但是2.0版本已经在开发日程上了。

粗糙的开发过程必然会导致一些问题

• 开发的过程中，常常因为一个需求的不明确而需要进行大的改动
• UI设计欠缺，产品的美观度还达不到高水平
• 缺乏进度的规划，导致项目的开发比原预期慢了好多个月
• 测试的少，导致代码后面出了BUG，花了好几天修改，最后查明确实一个很小的问题没注意

如果是多人开发

我预想如果这个项目是多人开发，可能还会出现更多的问题，例如代码合并上、设计和测试上、后续维护上。单独开发避免了这些问题，却也给我带来了更大的工作量。（在这边替我老板发个招人广告，会微信小程序或者python django框架的，有兴趣一起接着做这个项目的，欢迎联系我O(∩_∩)O，让我一起通力合作，搭建出一个好的兼职平台，服务那些勤工俭学的小伙伴们，让他们不必为了兼职的质量而担忧）

参考了众多的APP UI之后，我们设计了新的设计图

---

三、我的思考和问题

读后感

• 软件 = 程序 + 软件工程， 在之前的课程中我们学习了怎么写程序，而并没有教我们怎么做工程，曾经我忽视了软件工程（这不就是合作写程序吗？），其实并不是这么简单，其中的区别就像大家一起搬砖和大家一起盖大厦的区别这么大...

• 虽然把构建之法看了一遍，但是时间仓促，虽然有做了一些笔记，但是还是觉得有些囫囵吞枣，其中提到的一些思想和方法还需要在以后的实践中进一步熟悉和掌握。这是一本需要一有时间就拿来翻翻看看、仔细揣摩的书。
  

我的问题

在看书过程解决的问题

一些在看书早期中记录的问题，都在后面的阅读中得到了解答。
例如： **开发的过程中，学习到了新的技术能够促进开发，该怎么办呢? **这个问题在第十五章给了解答：

15.1.4　招数：设计变更（Design Change Request）

经过Alpha/Beta阶段，移山团队收到了不少用户的反馈，有些是意料之中的，有些是意料之外的。大家都看到，原来的设计也有不少要改进的地方。有了用户反馈，大家也能够取得比较一致的意见。另外，大家也有了很多新想法。一时间，众说纷纭，很多人都嚷嚷着——DCR，DCR！

重写或重构

小飞：我们的某某模块真是太烂了，我觉得必须重写，而且现在又有了新的技术叫“我佩服”（WPF）[或插入任一最近时髦的技术]，它能做很酷的效果，为什么不呢？

二柱：我们先要看看，原来烂到什么程度，现在是否能完成功能？你所说的问题有多严重？是功能不能实现？或者界面有问题？或者不能扩展（例如：不能支持更多用户）？

大栓：另外，是重构，还是重写？重构——在尽量保持原有界面的基础上优化部分代码。重写——重新实现原有功能，同时，要分清是全部重写原有功能，还是偷偷加上许多新的功能（Feature Sneak）？

小飞：咱们找领导去，超总，看看我新写的功能。

阿超：你不是在修复这个模块的Bug么？怎么开始写新的功能了？

小飞：对，不过你是不是觉得我加的这个新功能很酷，嗯……现在是有点慢，但是如果数据库再做一些对应的修改，比如增加缓冲之类的，那就更好了。

阿超：用户提到了这个功能么？这和我们项目的远景有什么关系？数据库修改后，原来的用户数据要如何迁移到新的Schema下面？
小飞：嗯，但是用户如果看到了，就会喜欢的。

阿超：很多程序员有这样的冲动，在做修改的同时，想到自己还能做更多的事，有一个“东西”一直想做，但是提出几次都没人重视，那现在有机会，就“加进去”算了。或者还有很多灵机一动的想法。打个比方——本来是要修厨房顶上一个有时漏水的水管，结果修理工来了，修好了水管，同时灵机一动，加了一个带淋浴的豪华卫生间。

小飞：但这毕竟是新的想法，我以为你会喜欢的。

阿超：记住项目的当前阶段是一个阻尼振荡的过程，要收敛和稳定。等到下一个版本开始的时候再进行发散的思考吧。如果你觉得目前的设计有问题，我们要用DCR来管理。

怎么做DCR？阿超给大家列出了DCR的要点：

如何提出DCR？

1）在提交一个DCR时，选用任务作为工作件类型，并在标题中标明DCR。

2）在DCR的描述文字中，说明：

a. 问题在哪里，问题的影响；

b. 如果不修改，会有什么后果？

c. 几种修改方案，各种方案的优缺点和成本。

除了这个问题在看书中解决之外还有很多，就不一一列举了

还没有解答的困惑

1. 对一个要去找工作的学生来说，专业成绩和实践能力哪个更被企业看重？
2. 开源的代码有必要附带测试代码和开发文档吗？
3. 资金和人力有限的创业公司需要严格的执行软件开发流程吗，还有分工上，有时候并没有产品经理，也咩有测试人员，这时候有什么适用的软件开发流程吗？
4. 在需求分析中，可以不通过用户，直接从现有市场的竞争软件中取长补短吗？
5. 怎么看待互联网或者说软件只是把传统搬到电脑上或者网络上这种说法？业务有时候并没有变动，这算是行业创新吗？
6. 测试人员的技术需要比开发人员厉害吗？
7. 在现实的小公司中，产品经理一般都是兼任开发职责的，利会大于弊吗？
8. 管理 != 技术，面对不会技术的管理要怎么协调工作？
9. 我在开发的过程中发现，有很多的时间都花在了分析业务流程上（兼职流程），但是如果不理解业务，开发出来的产品压根没法使用，在实际的企业开发中，写代码的时间和不写代码的时间（需求分析、设计等）哪个比较多？