温故知新

温故知新

一、 以往问题分析与解答

问题1：

• 问题回顾：

  例如一个游戏（如农药，吃鸡等），当人们热衷于它时，能够获得短期的快感，游戏公司开发了防沉迷，是为了减低长期的负面影响。但对于某个不知名的游戏，不言而喻其短期刺激显然更为重要。所以我的疑惑是：短期刺激和长期影响是一个软件不同时期应该考虑的事，还是一开始就应该一起考虑？

• 解答与分析：

  唯一不变的是变化 ----《谁动了我的奶酪》（斯宾塞．约翰逊），世间的无数事物都是如此，更何况软件呢？根据《软件工程 实践者的研究方法》（原书第8版）:软件的本质在于变更。我认为早期游戏开发公司没有也不可能意识到这样一个游戏会使得人们如此着迷，需要用一个机制来进行约束。因此，这应该是一个软件在不同时期应该考虑的事。

问题2：

• 问题回顾：

  现在一些小程序如嵌入至qq中的小程序，大多没有一定用户数量和规模，但程序内部依然包含大量的广告，这不是本末倒置了吗？用户需求都没有先得到满足，但是存在即合理。这些软件程序依靠什么在市场上能够继续生存？

• 解答与分析：

  本学期曾经参加微信小程序开发相关的比赛，经历了微信小游戏（Earth Run）的开发，部署，上线等流程，在这些过程中，我认识到微信或qq等平台本身就是流量的入口，因此这些小程序即使没有大量的用户数量，也可以通过这些平台推广自己的应用，相比其他产品小程序本身体量较小，

  故小程序本身不需要达到太大的规模，即可嵌入广告，符合构建之法中的描述：一个免费的互联网服务到达一定规模后，企业就会考虑如何让这个服务带来收入。

  所以我认为微信等平台和创意是这些程序赖以生存和源源不断产生的根本原因。

• 新的问题：

  如果将此类小程序作为自己创意的试错产品是否可行，又该如何避免被抄袭？

问题3：

• 问题回顾：

  实际开发工作中时间不可能为0，此处去左边取闭区间，是否不妥？还是我没有理解其真正含义？

• 解答与分析：

  根据原书中他做过类似的开发工作，有可能正好以前的代码可以直接使用，所以实际开发工作是有可能为0的，因此原文是合理的。

问题4：

• 问题回顾：

  回想起曾经的debug方法，输出查看日志，输出函数调用栈等。又通过网络查询到，例如bug间歇性随机出现时，可分析：

  1:随机性数值导致。

  2:特定的执行过程导致的特殊情况。

  3:野指针导致的不稳定性问题。

  想请问实际工作中出现这种不可见性时，如何解决？

• 解答与分析：

  结合在本学期软工实践项目开发过程中的经验，通常出现这种错误时，处理过程如下：

  1. 多进行几次相同操作，确认原来bug是否为间歇性随机出现
  2. 重新部署与运行项目，确认最新的代码已经更新至服务器中。
  3. 对相应的功能模块代码前后增加相应代码，用来限制输入，输出以及打印相关信息。
  4. 如果在这过程中发现了间隙性bug及其原因，解决bug。
  5. 如果增加了限制代码且不影响原因功能，忽视原有bug.
  6. 最后还是无法解决：重写代码。。。。

• 新的问题：

  增加了限制代码，就以为自己解决了bug ，这种做法显然不够合理，但是总不能在有限的时间重写代码吧，这种bug是否能够通过在编码时进行足够多的测试如单元测试，回归测试来避免？

问题5：

• 问题回顾：

  编写程序时遇见这样的情况，事先不容易判断是否需要优化，如果当前不进行优化，最后发现程序进行这样的优化是必须的，而又不得不修改大量代码。这种情况如何判断“过早优化”？

• 解答与分析：

  随着对《构建之法》与其作者了解的深入以及实践项目的进行，我认识到判断是否为"过早优化"，应该根据实际项目情况与其开发的时间，空间来进行进行讨论。同时根据程序某一代码的重要性，被复用程度来进行判断。

1.2 阶段收获

1. 需求阶段

原型设计(Axure)是本阶段最大的收获，无论从一开始在网络上搜索如何深入了解到用户最本质的需求来进行原型设计，到发现搜索框这个宝藏（需求从哪里来——藏在搜索框里的秘密)），还是到最后和核心用户--助教和老师，进行交流，我们都将我们接收到的信息，转化为原型，并以此和用户持续交流，迭代修改原型，直到需求变成了原型上活生生的页面。

2. 设计阶段

关系数据库的设计（E-R与实际设计）是需求和实际项目对接的关键一步，同时也是我第一次设计如此复杂的数据库，从现实中用户，分数，作业等等实体及关系，到每一个属性的类型大小，都需要代入到应用环境和联系相关知识（存储空间分配，范式，rabc......）来决定，在这过程中我对书本中的描述体会颇深，大意为：设计可以根据具体情况有所改变，不一定要完全遵从范式。

3. 实现阶段

本阶段由于需要搭建spring 框架以及决定解决相关功能的一些技术（权限管理：shiro, excel处理：easyPoi等等），所以我早早的开始了相关方面的学习，这也是整个项目中，收获最大的地方吧。

4. 测试阶段

由于主要工作在开发部分，所以我测试阶段大多进行的是单元测试，以及利用PostMan 进行接口测试，PostMan 是一个非常优秀的工具。

5. 发布阶段

在这过程中学习了,linxu 常用命令，防火墙，安全组等相关知识。虽然有很多运维工具如宝塔面板，但是还是需要动手去操作才知道别人这样设计的合理性。

1.3 一些经历

​ 在整个软件工程实践中，感觉自己经历了很多，发现了自己的很多缺点与不足，同时也收获了很多。因为种种原因没能自由组队成功，被分配到了随机小组，在身边人看来，我是不幸的，但是经历了那么多，蓦然回首，我是如此的幸运。因为我负责后端并参与了任务的分配，所以需要我和团队里的每一个人的交流都比较密切，同时对整个项目有比较多的思考和参与。上面这些都促使我不断的克服困难，一开始会发现有的队友比较慢热，群里大家也不说话（每当这个时候，我常常会怀疑我是不是做错了什么，大家是不是都在忙自己的事情，后面才知道，原来是大家也在思考怎么解决问题，hhhh），后面慢慢就好起来了，很多队友间也开始积极的交流问题，我们的测试，常常和我讨论这个问题算不算bug,怎么修复，助教的问题怎么回答。同时，刚开始一些队友实践比较少，虽然完成任务比较慢，但是很努力的学习与解决问题，我们常常在一个房间里一起改bug, 常常因为问题的归属处进行争论。同时，我们负责博客的队友也很努力的按照作业的要求完成博客，收集各项材料，回复助教，老师的评论，我们经常一起讨论，任务量，任务的分配等相关问题。还有我们的前端负责人，明明是走后端技术栈的，为了团队去学习了前端。还有我们的安卓组长，说实话我觉得他的移动端界面很丑，他对于自己代码的要求如泛型，常量的使用，变量的类型等等都做得比较好，这点值得我去学习。自己有很多没有做好的地方，说话，做事比较急躁，没有考虑周全，搭建的后端框架也有许多问题，幸好我的后端队友还是和我积极的一起解决问题。我们这个项目虽然没有做到足够完善，但是我们都灌注了很多的心血，也完成了主要功能。总而言之，整个软工实践中，我学习到最多的就是如何进行团队管理，和项目的推进以及如何把一个大的东西拆分为一个个零件，虽然很多东西没能做到，但是依然收获颇丰。

二、 个人技术总结：

Springboot 整合jwt+Shrio

概述：由于编写的一个利用springboot 开发的web项目涉及用户权限管理(实现对用户访问系统的控制，按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。)和身份验证(判断一个用户是否为合法用户的处理过程）。在学习的过程中整合了shiro+jwt，本文旨在小结shiro整合jwt 的使用和遇到一些坑。