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

1、前情提要

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

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

---

2、结合我自身

个人开发经历

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

这是咱们的产品

欢迎使用并提意见，由于老板在外出差，如今暂停了业务上的推广，可是2.0版本已经在开发日程上了。

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

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

若是是多人开发

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

参考了众多的APP UI以后，咱们设计了新的设计图

---

3、个人思考和问题

读后感

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

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

个人问题

在看书过程解决的问题

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

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. 我在开发的过程当中发现，有不少的时间都花在了分析业务流程上（兼职流程），可是若是不理解业务，开发出来的产品压根无法使用，在实际的企业开发中，写代码的时间和不写代码的时间（需求分析、设计等）哪一个比较多？