提问回顾与个人总结
提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ |
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/3377 |
| 我在这个课程的目标是 | 学会软件工程，为以后工作打好基础。 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结软件工程课程，对整个学期学到的知识进行总结与反思。 |
学期初提问博客
对于原来提出的问题的解答
-
我以前认为goto函数是不易懂的，所以就不适合用goto函数，但是看到书中，为了函数有单一出口，可以使用goto函数，我个人的感觉是goto函数不利于阅读，所以要减少goto函数。我的疑问在于真的很有必要使用goto函数吗？
回答：经过了一个大三下学期，我的代码总行数增长了近9000行，其中包括在软件工程课程中使用的Javascript，WXSS，WXML，C++以及其他课程使用的Python，Matlab。在这些代码中，跳转语句非常多，其中有的地方需要连接到一个语句块之外，但是所连接到的地方又无需使用多次，这个时候，如果用到goto语句，就可以极大的减少代码行数，并且使函数简单化。
而且我发现，《构建之法》这本书中提到的“函数最好有单一出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto”，这一观点非常正确，一个函数最好只有一个出口，这样在逻辑上会非常清晰，并且，在Debug的时候，如果只有一个出口的话，单步调试中进出函数的过程都会非常明晰，编写程序的时候也不会错在某个出口的返回值出了问题。因此我认为，只要是符合代码规范，并且有助于代码的清晰展示，任何语句都可以使用，良好的goto语句比臃肿的if判断反而更利于阅读。
-
以前我认为两人和做就是两个人分配工作，然后各自实现自己的接口，给对方使用，但是在书中，变成了一人看着另一个人编程，而且屏幕共享要设置好，但是我跟人感觉屏幕共享没有必要，在一方编程号之后git上去另一个人可以看到就可以，没有必要完全实时看到。我的疑问在于真的有必要进行屏幕共享吗？
回答：在经历了软件工程的结对作业和组队大作业之后，代码行数及增长的同时我也体验到了多种不同的编程方式，有题目中提到的通过git编程，也有结对编程，在这些编程方式中我发现最具备效率的是结对编程。在有些两个人共同开发的工程中，如果通过结对编程来完成，会极大的减少编程者出现bug的可能性，因为大多数手误出现的bug会在结对编程的过程中被瞬间解决，因此极大缩短了debug浪费的时间，并且，由于有人在旁边看着编程，对于编程者来说，思路更加清晰明确，编程效率也会比单独完成更高，而且，在对接的过程中也没有任何的差错。如果两个人使用git进行编程，在对接的时候难免会出现一些差错，这个在软工的组队作业中也有体现。因此我认为屏幕共享还是有必要的，否则便失去了结对编程的意义。
-
我个人认为，写代码的时候不可以使用写了再改模式，就算是只是用一次的程序，也要按照规定来写，使用写了再改模式对自己的提升没有什么帮助，而且写出来的程序八成也不是什么好程序。所以我觉得写了再改真的有好处吗？
回答：在以前任务不是那么重的时候，我认为不应使用写了再改的做法，因为当时认为写了再改也不会改出好程序，但是在这个学期的大量的代码的PUSH下，我发现在《构建之法》书中提到的某些程序使用写了再改的模式是比较有帮助的，像文中提出的只用一次的程序完全可以写一个“能跑的”出来，因为这个时候无需考虑太多知识，以后也不会用到这段代码，所以先“敏捷”出一个功能保证其他功能的完整性，这个时候如果去专门学习这个知识反而会浪费时间，不如把时间放到会反复使用的程序上。因此我现在感觉写了再改的模式对有些代码还是比较适用的，但那些反复使用的代码还是要学习相关知识在完成，否则日后修改会浪费时间，效率非常低。
-
以前我认为一个软件往往是有特定针对人群的，所以只需要考虑自己的使用用户，但是，书中写了软件要为某些存在障碍的用户提供一定的便利，但是个人觉得这些需要比较偏硬件来实现，比如现在很多手机上的软件就没有对盲人有便利的地方，相反在硬件上就有对盲人的方便，所以我觉得软件应该比较偏向于他的服务人群。
回答：在这个学期中，我们的团队
Water_T一起合作了“小小易校园”这个微信小程序，由于微信小程序使用比较方便，有微信的都可以使用，所以在面对众多用户的时候，我们需要考虑如何使我们的小程序变得更加顺手，操作更加便捷，这个是吸引用户使用的一个重大因素，因此我现在看来，软件应该设计的更加贴合用户的习惯，这样才能吸引和留住用户，毕竟软件做出来是为用户服务的，有更多的用户才能说明这个软件做的有用，对于盲人群体，比如我们在软件中加入阅读选项，便可以获得一批盲人用户，添加对新手的友好支持也能降低用户只使用一次的概率，因此实际做软件和写程序还是有所去别的。 -
我感觉创新也可以是科研的一部分，创新的本质就是创造出新的东西，不论是这个理论有没有事先被创造出来，而且理论的诞生一定是服务于实践的，所以我认为创新和科研本质上的区别并不大，但是书中把科研和创新分开成两个部分，我认为科研是创新的一个部分，也是它的前提条件。所以科研和创新真的不能等同吗？
回答：科研与创新，二者虽然都有写出新的东西，但是二者的定义并不完全相同，书中也提到了科研是把金钱转换为知识的过程，科研的过程是十分耗费金钱的，并且，转换出的知识并不会直接变为金钱，而是纸面上的知识，仅有科研，并无法将成果转换为大众使用的产品，因此才需要创新，文中的创新是将科研的成果转换为落地的产品的一个过程，在我现在看来，二者缺一不可，二者起到的效果是相辅相成的，是有金钱转换为知识的过程，才会在有科研的知识转换为创新成果的过程，而创新成果所带来的金钱，也会进一步促进科研的产生，因此，二者缺一不可，二者相互促进，才会使得民用产品更加优秀。
新的问题
在这个学期的软件工程中的团队作业中，我担任Water_T的前端开发人员，也担任Gamma阶段的前端负责人，在进行前端开发的过程中，我发现一个比较困难的就是完全理解PM想要的效果，并且，在管理前端所有人的代码并将其进行整合的时候，我发现人与人之间的代码风格极不相同，因此在耦合的过程中发现问题的处理也稍微费劲一点，并且我发现对于工期的处理也是一个大问题，Gamma阶段中由于一个页面拖了两天才完成，因此导致其他所有页面都无法测试，这个是Gamma阶段出现的最大的问题。
因此，我的问题是，在负责一个小的项目的时候，比如前端的部分功能时，如何协调组内的工作 以及对于ddl的处理，才会使得最终产品不拖延时间上线并且可以给足每个人工作所需要的时间？
学到的知识点
需求阶段
-
真正了解用户的需求才能开发出令人满意程序
在Gamma阶段中，我们与其他大学合作，接到了一个需求，并以此作为我们Gamma阶段的任务，在这个过程中我发现，有的需求在word文档中描述的并不清晰，因此导致在交付的时候要修改部分内容，才可以交付使用，所以我学到真正了解用户需求才能一次开发出令人满意的程序。
设计阶段
-
设计人员要有比较大众化的审美，并且前端要拿到设计稿后才能动手写代码
在Alpha阶段中，我作为一名前端工作人员，既承担前端页面的设计工作，又承担前端页面的绘制工作，这个时候由于我觉得画的都还行，所以前端的美观程度就远不如后两个阶段，并且我们的前端页面在Beta阶段进行了大的修改，基本都重新画了一遍，在Gamma阶段中，我选择的配色也被大家认为难看，所以我发现，设计人员一定要有审美，有符合大众要求的审美，否则画出的前端就会被大家认为很难看，
实现阶段
-
实现的过程中一定要注意代码耦合度
在进行前端页面绘制的过程中，Alpha阶段我没有很注意代码的耦合程度，所以在Beta阶段修改的过程中就几乎重写Alpha阶段代码，因此我认为要注重代码的耦合程度，这样以后修改的时候就不会特别难受，所以在Gamma版本中，我特别注重了代码的规范度，便于以后提出新的要求进行修改。
测试阶段
-
测试的时候一定要选择不同的机型进行测试，不能只测单个机型
我在我们的团队中不仅负责前端页面的编写，还负责在手机上进行真机测试，开始我们只测试了安卓机，并且小米居多（因为周围没有人用苹果），直到第二天到苹果手机上进行测试的时候才发现，出问题了，由于安卓和苹果的机制不同，所以有的问题在安卓上表现不出来，但是到苹果上就会出错，因此我发现测试要测试多种机型，不能只测一种。
发布阶段
-
发布要及时应对各种情况，做好全面的准备
我们做的微信小程序遇到了多个难题，首先代码包过大，导致无法上传（小程序要求单个包小于2M，多个包整体小于8M），我们删掉了部分图片解决了这个问题，之后我们遇到了审核的问题，这也是困扰我们整个Beta阶段的问题，由于个人版无法使用信息发布功能（这个问题是突然就审核不过的），因此我们被迫换成企业版小程序，大约过了一周才审核通过，因此我发现，发布要应对多种情况，做好全面准备，才能不延期发布。
维护阶段
-
出现BUG要及时消除
在产品上线之后，难免还会出现Bug，这个时候要及时消除Bug，否则会让用户有非常不好的体验，我们的登录页面开始存在Bug，导致登录经常失败，但是当我们发现这个Bug的时候，及时对该Bug做出修正，消除了登录的问题，从而提升了用户体验，因此我认为线上版本出现Bug也要及时消除，这样才能留住用户。
个人心得
在进行了一个学期的软件工程的课程中，我对软件开发有了一个新的认识。这个学期中，我担任Water_T团队的前端工程师，我开始认为前端工作比较简单，但是真正上手之后才发现前端工作并不简单，甚至比较复杂，因为前端要做的不仅仅是实现功能，更要把页面画的美观，一个美观的页面对留住用户是非常重要的，而这恰恰是一个前端工程师分内的事情。
并且我发现组内的PM是非常有必要的，有了PM，我们才能直到大概的工期，从而有了ddl和压迫感，才会在该完成的时间内完成所需要的任务。并且在一个团队中，有的时候会有人比较忙，从而先暂时放一放软工课程的内容，这个时候就需要其他人来接手，因此在小团队中进行结对编程就是一件效率比较高的的事情，我和我的室友都是前端负责人，因此在整个前端页面的绘制过程中，我们经常出现结对编程的情况，从而使得我们每个人都比较了解前端页面，在进行页面逻辑修改的过程中，修改的速度也比较快，这也是我发现结对编程的优秀之处。
在这次的团队合作中，我选择了前端的工作，并且学习了wxml, wxss, Javascript等编程语言，顺利的完成了前端的额工作，如果下一次的话，我想选择后端工作，体验一下后端工程师的感觉，从而让我学会前后端双重工作，成为一个全栈工程师。
最后，我认为这个学期有了软工这门课程，并且与大家合作完成一个微信小程序非常有成就感，这个小程序或许能成为我第一个能赚钱的程序，因此我对我们的产品也非常满意。并且在开发过程中有助教的帮助与监督，也让我们的开发过程变得更加规范，所以我也要感谢助教的辛苦付出。软工这门课让我这个学期过的无比充实，我也祝愿软件工程这门课越办越好。
