软件和工程（个人总结）

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

什么是软件工程？

开课前听到软件工程这门课程的名字，只是将注意力集中在了软件二字上。心里想着，这次一定要认认真真的听老师讲怎么用C或者Python编写软件，扎扎实实的精通一门计算机语言，把本科丢掉的知识捡起来，并且能够正儿八经的敲代码，编程。然而，上课后才发现原来这并不是一门用来专门讲语言的课，反而将重心更多的放在“工程”上。所谓“工程”即在软件的开发过程中，将系统性的、规范化的以及可定量的方法应用到软件的开发、运行和维护中，这就是所谓的将工程应用到软件开发过程。
在上课老师的讲解中以及课下的实践中也确实是这样的，小组在进行软件的编写时，一定是一个团队协作的过程。既然是团队协作就要求团队有一个规范的系统，每个人各司其职，并且在代码编写以及任务安排等方面都要求按照约定的规定去完成。至于量化过程，可以从码云上的的代码工作量有所体现，以及在每周的小组汇报上体现每个小组每周的进度以及下周的安排。
在课外阅读的《人月神话》中也清晰的告诉我们了一个概念，并不是参与任务的人越多，花的时间周期越长，效率就越高，任务完成度越高。应该根据不同的任务，做出具体的安排。

---

软件编程等于写代码？

以前我有一个疑问或者说一个误区，开发软件，软件编程仅仅就是一帮程序员埋着头没日没夜的写代码吗？以前我是这样认为的，但现在看来软件编程远不止写代码这么简单。软件编写是一个复杂而迭代的过程，它不仅仅是编写代码，还包括代码审查、单元测试、代码优化、集成测试等一系列的工作。软件编程需要严格的按照规范步骤一步步走下去，并且不是写完后就万事大吉的工作，而是要通过一轮轮迭代，不断地修正错误，修复漏洞，改进优化，不断完善的过程。

---

不同阶段不同收获

在开始一个项目前，可以对这个项目按照NABCD原则进行分析。所谓NABCD是指需求（Need）、做法（Approach）、好处（Benefit）、竞争（Competitors）、推广（Delivery）。只有对一个项目有了充分的认识，才有可能顺利的完成这个项目。了解到市场的需求是开端，接着就要想怎么去实现这个项目，项目有哪些显著的优点以及在与同类产品进行竞争的时候有什么优势，有什么不足，最后还要有一个好的推广途径使产品为人熟知，这样一个项目才有获得成功的潜力。

需求阶段

在项目需求阶段，我们小组针对在校大学这一用户群体进行需求分析。每当开学季，学生就会有购买大量新教材的需求，而上学期用过不会再用的书籍就闲置了。在万能墙上发布需求所需的周期太长且还需要排队，现有的二手书网站针对性不够强，分类过于杂乱，并且交易费用过高增加了学生负担。我们针对在校大学生这一特点，提供一个给在校大学生校内线下交易的平台。
在项目需求这一阶段我学到了，在开展一项工作前要进行一定程度上的调研，并且要抓住研究对象的显著特征，针对研究对象特有的特征进行分析。还要做到集思广益，一个人的想法总是有局限性的，小组每个成员都进行头脑风暴，需求的提出更加高效且更加全面。

设计阶段

在设计阶段，我们根据前期提出的需求进行初步设计，主要包括前端和后台。前端包括用户的注册登录、个人信息、书籍信息、界面等等。后台包括系统管理、管理员对用户管理、书籍信息管理等等。围绕用户需求，提出了一系列的满足方法。
在项目设计这一阶段我学到了，在做一个软件时并不仅仅是对表面上看得见的进行代码编写、参数设置，同样还要对后台看不见的步骤进行思考和代码编写。设计一定要紧贴需求来考虑，并且一定要尽可能的考虑的面面俱到。设计时也要参考现有的产品，借鉴现有产品的优势，提出自己独特的功能，设计的产品要有显著的优点。

实现阶段

我们小组首先对人员分工以及项目总体安排进行了详细的规划，每个人都有自己的任务，每个时间段都有进度安排。在代码的编写过程中，主要是由我们小组的软件工程师任浩源负责总体编写，另外两名成员负责查找资料，修改代码中的细节部分。
在实现阶段，我学习到了在合作时要有明确的分工，要进行及时的沟通。有什么问题大家及时讨论及时解决。

测试阶段

项目的测试还没有完成，课堂上在老师的带领下，我们对Pycharm进行了配置，可以实现自动测试已经编写的代码正确与否。最终项目的功能测试还要等到所有编写完成，进行统一测试。目前登录，书籍信息查询等功能均已实现。
在测试阶段我学到了，编写的代码要及时进行测试，每编写完一个单元都要进行测试。这样才能及时发现问题改正问题。

发布阶段

目前为止，产品还没有发布，但我们已经做了推广视频，对我们的产品功能大致做了介绍，并上传到b站上。

---

心得体会

通过这次的项目，我感觉在信息高速发展的现在，单打独斗是不可取的，只有团队协作才能够更加高效的完成目标。在这次项目中，我们团队集思广益，每个人都分工明确，通过查找资料以及及时的共享信息，我们还是较为顺利的进行着项目的进展。
现在对于我们这种开源的项目就应该上传到云端让每个人都看见，不光是自己团队的成员，互联网上的各种大佬都能够看到我们的代码，并且能够修改并上传，同时也能够在码云上记录每个人的工作情况。
这次团队协作，共同完成二手书交易网站，很好的实践了上课讲的理论知识，并且编写的网站也能够在现实生活中进行应用。

---

总结

在开课之初制定了自己的学习计划，现在回过头来看，编写软件的规范性、掌握标准的软件开发流程等已经基本实现了，但Python的强化学习和实际应用还是做的不够好，后面还是要找机会再进一步学习Python并加以应用。
在团队中，我更多担任的是搜集资料，协助任浩源工程师完成细节上的修改，提出任务的解决框架，提出需求，产品推广等等。在团队中，虽然不能够担任程序主要开发者的工作，但还是尽力去协助软件工程师更顺利的完成工作。

---

《梦断代码》读后感

《梦断代码》讲了这样一个故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。那么到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？有理论认为，传统的软件公司用工资，职位，绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作（大教堂/Cathedral模式）。其实，用开源，社区，共享的模式会更好（集市/Bazaar模式）。和驱动紧密相关的，是责任。在Chandler 项目长达7年的拖延中，有没有发生过各位项目管理者引咎辞职的事？ 好像没有。 [有不少人离开，但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚，那我为什么一定要拼了命要避免下一次拖延呢？在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在“集市”，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任。一个软件团队可以制定出动人的远景/Vision， 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任，那Vision只是一句话而已。
时间对每一个人都是公平的，对每一个软件项目也是这样。书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。对每一个团队成员来说，他/她不仅要完成手头工作，还有报告自己的进展，回答别人的问题，了解其他人的进展。每个人的时间都是有限的，要保证我们在应付所有的交流/沟通之后，能有时间完成“手头工作”。
把握远景，处理近景。正是因为早期那些不完美，但是及时的设计，让后来者有挑剔这些不完美的奢侈机会。