运用vb开发简易计算器 可以实现加减乘除以及包含括号的运算
coding项目地址：https://coding.net/u/Trip1eL/p/Calculator/git?public=true
快速看完《构建之法》后我不懂的问题：
问题1 78页 代码复审 我曾在一则微博中看到，某科技公司年会抽奖系统是一位新人程序员写的，当时在座的大牛都认为不公平，于是现场要求review代码。于是出现了几百人盯着投影看代码。那么，在众多大牛眼里，每个人的想法都不一样，有的人认为公司成员名单排序不合逻辑，有人认为这位程序员调用的随机数API不好。书中基本以理想情况来描述代码复审，当面对这种情况时应该如何处理。
问题2 194页 有关PM 接触过一些程序员和某程序员社区，发现大多程序员与PM有很深的羁绊。PM如何处理这种类似上下级，上级命令下级，下级不愿搭理上级的这种情况。
问题3与本书内容可能会无关，但是这是我一直想请教老师的问题。当一个软件通过大量时间的迭代更新，反复修复bug，但总会出现修复一个bug，又产生两个新的bug，这种情况下有没有必要重新整理思路，重新分析需求，团队重组，对整个软件进行重构？
问题4 293页 易用性测试 以程序员角度对一个新开发的软件进行易用性测试，我认为有失公正。打个比方，国内较为知名视频网站“哔哩哔哩动画”，他们开发的手机客户端一直存在两个版本，普通版和beta版。两个版本都可以在应用商城下载，beta版比普通版更新会快一步，新功能先手上线在beta版本上，用户可以选择放弃稳定性去尝鲜并对软件的用户体验进行反馈，最后开发人员会修改再次上线到beta上直到此功能反馈能让大多数人接受再上线到正式版。让用户决定开发目标，并让用户成为易用性测试人员，是否是一个更为优秀的方式？
问题5 快速看完本书后，我个人认为，软件开发过程中最为重要的是团队。但是团队一定是不可或缺的部分吗？全栈工程师完全可以个人开发一个项目，那么，团队的优势是什么呢？
问题2 194页 有关PM 接触过一些程序员和某程序员社区，发现大多程序员与PM有很深的羁绊。PM如何处理这种类似上下级，上级命令下级，下级不愿搭理上级的这种情况。
问题3与本书内容可能会无关，但是这是我一直想请教老师的问题。当一个软件通过大量时间的迭代更新，反复修复bug，但总会出现修复一个bug，又产生两个新的bug，这种情况下有没有必要重新整理思路，重新分析需求，团队重组，对整个软件进行重构？
问题4 293页 易用性测试 以程序员角度对一个新开发的软件进行易用性测试，我认为有失公正。打个比方，国内较为知名视频网站“哔哩哔哩动画”，他们开发的手机客户端一直存在两个版本，普通版和beta版。两个版本都可以在应用商城下载，beta版比普通版更新会快一步，新功能先手上线在beta版本上，用户可以选择放弃稳定性去尝鲜并对软件的用户体验进行反馈，最后开发人员会修改再次上线到beta上直到此功能反馈能让大多数人接受再上线到正式版。让用户决定开发目标，并让用户成为易用性测试人员，是否是一个更为优秀的方式？
问题5 快速看完本书后，我个人认为，软件开发过程中最为重要的是团队。但是团队一定是不可或缺的部分吗？全栈工程师完全可以个人开发一个项目，那么，团队的优势是什么呢？
软件有很多种：包装在盒子里的软件、基于网页的软件、企业或学校或某组织内部的软件、游戏、手机应用、操作系统、工具软件，选取三种软件，请分析它们各自的特点。
（1）游戏：优秀的宣传及游戏介绍CG动画是吸引我成为其用户的最大原因（怕是个网瘾少年哦~）；游戏的目标几乎全都是盈利；游戏所有都是在各大正版平台购买下载获得；推送更新，但对于育碧来说应该是买BUG送游戏；同一类比如h1z1和绝地求生同为大逃杀类游戏，后者更看重中国市场，宣传力度很大，这就是为什么绝地求生能获胜的原因。
（2）操作系统：桌面系统暂且不提，因为windows的市场占有率太高。手机主要是IOS和Android之间的选择， 我更倾向于Android，因为安卓的应用开发难度比IOS更简单，适配起来更容易。由于我的手机是Google Pixel俗称谷歌亲儿子，所以系统会第一时间通过OTA推送进行更新，bug修复时间较快。
（3）工具软件：工具类软件我大多会尽可能支持正版选择购买，但是有些软件太过于昂贵，比如FL Studio 会选择拷贝等方式。
软件相对于硬件来说，维护较为容易，版本更新及时，一次购买终身更新，然而硬件无法这样，比如曾经的奔腾cpu现在已经过时，只能通过购买最新的酷睿进行升级。