本文目录
如何高效地增强编程（特别是debug）能力
1.重现Bug
Debug过程中最关键的一步就是要首先能够重现Bug.一个Bug的出现和当时的环境,测试的数据以及操作的步骤都有很大的关系,因此对于隐藏较深的bug往往是很难重现的Bug.但并不能说不能重现就代表系统没有问题或是一个偶然现象,一个Bug及时不能重现只能说明系统有潜伏很深的隐患存在,最终问题还是在程序或代码上.
这里Bug的重现并不是指要在所有的机器上都能够重现,只要能够在一台机器上在24小时内能够重复出现,就足以让我们去跟踪和解决该问题了.很多硬件环境引起的Bug其根源仍然在我们应用程序的兼容性上面.
一旦我们在一条路径上面能够重现Bug后,接下来还要考虑是否能够在其它路径上面重现Bug,或者录入其它一组数据走同样的路径就不出现Bug,这是在重现Bug中我们需要做的重要分析,搞清楚这些边界条件将有助于我们定位Bug
2.描述Bug
描述Bug并不是一件简单的事情,首先应该说明的是Bug发现的软硬件环境.然后是准备的测试数据,然后是具体的操作步骤.这是三个最重要的需要描述的信息.这三个描述清楚了才是描述具体的Bug表现,Bug的严重程度和优先级等信息.
描述Bug和重现Bug是两个不可分的过程,好的Bug描述要达到能够很好的重现Bug的作用.
3.总是假设Bug是由于自身原因造成
根据多年的经验,绝大部分的Bug都是由于我们自身的原因引起的,而只有极少数的Bug是由于编译器或开发环境引起的.当系统出现Bug的时候将问题归咎到环境或其它因素上面,是一种不负责任的态度,也不是解决问题的态度.
当有Bug出现时候首先假设是自己的问题,如果确实是自己的问题则你可以找到相关代码并修复Bug.如果是编译器或环境的问题,则要首先保证自己的代码没有问题
4.分而治之(定位问题,Light Debug)
当你能够重新Bug而且能够很好的描述Bug后，接下来你就会形成一个可能引起该Bug的假设信息。我们Debug的过程其实就是一个二分法查找或二叉树搜索的过程。你不断的去形成相关假设，然后通过迭代不断去验证你的假设，不断的去缩小问题域的范围，最后将问题定位到一小段功能函数或代码上。
我们开始有可能并不能得到一个关于Bug的准确描述，在我们Debug过程中，不断的假设和尝试过程中去获得对Bug相关信息的更准确理解和描述。一旦将问题定位到一小段代码上后才可能开始详细的Debug过程，如对变量和推荐信息进行观察等。
5.创造性思维(换一种方式思考)
当花了很少时间分析Bug而无法解决的时候，或许应该从将Bug放下轻松几天。有时候由于我们太专注一件事情了而经常犯只见森林不见数目的错误，一些显而易见的线索往往被我们忽略了。
我们对于一些较复杂的Bug无法解决往往是我们一味的安装我们当初的错误假设去解决问题，一味的钻入到死胡同而无法回头。本来是由于操作系统或打包部署的问题可能你却花了几天时间去走查代码而一无所获。很难清楚这究竟是因为我们的思维定式还是性格上面的固执起见。但可以确定的是它对我们解决复杂问题所带来的副作用。
当局者迷，旁观者清。所以当你需要请求他人协助的时候最好能够请开发小组外的人员帮助你分析问题。因为他们往往一开始就可能选择另外一种视角或分支来思考和分析问题。
6.善其事者先利其器
对于IDE本身，CompuWare或Rational等都出了很多相关于Debug的工具集，实现代码的覆盖率测试，单元测试，性能测试，语法等静态检查等功能。以协助我们分析和解决Bug.
但我们需要分清楚工具和思维的界限，工具可以协助你分析，但思维的源头还在于自己。如果你连走哪条路去罗马都无法选择出来，给你一架飞机也是徒劳的。如果你已经选择了一条路去罗马，还靠着自己双腿折腾着去，估计就很难让人理解了。
7.高级Debug(分析和解决问题,Heavy Debug)
我们说的Debug一般分为了高级Debug和轻量级Debug(Step 4)。之所以把这两者分开重要原因是轻量级Debug关注的是假设分析，路径的选择和简单的本地化变量的观察。而高级Debug更多的关注的是程序的内部逻辑结构和操作方式。高级Debug重要的一点就是要充分发挥Debugger一些高级特征，去协助我们做深层次的分析。
如果我们从解决问题的角度来思考的话，轻量级Debug主要目的是定位清楚问题，缩小问题的范围。而高级Debug的重点则在进一步的分析和解决问题。做高级Debug的一个重点及时需要不断的去回顾我们为了修复Bug而在Debugger中对程序所做的任何修改，任何一个修改都可能引起一个新的分支的产生而影响到我们的回溯。
8.验证Bug的修复
在Bug修改完成后，进行全面的测试和验证是完全必要的。由于修复一个Bug而引入了一个或多个更多的Bug往往是程序员的恶梦。而避免这种情况只有通过全面的测试。你需要仔细分析你修改模块的所有外部依赖关系和依赖逻辑，以此着手去准备相关的测试数据（包含好数据和脏数据)，进行仔细的测试和验证。
结构化分析中谈高内聚和低藕合，面向对象中我们谈OCP开放封闭原则，如果我们一开始就不遵循这些最基本的设计原则，那后续维护和修复Bug的人员往往成了最终的受害者。
9.学习总结和经验共享
学习总结的重要内容就是形成细粒度的模式语言。在哪种场景或环境下，遇到哪种类型的Bug，应该遵循哪种分析方法和Debug步骤，首先应该考虑到的假设和路径又是怎样的。这些模式在总结出来的一开始并不一定完全正确，但却会在我们不断的学习和总结中去完善。
分享和获取始终是不可分的，在你分享他人的经验时候也要乐于贡献自己的经验教训。对于大家都可能犯的问题还需要总结出来形成项目的规范和经验教训库。
VS2022据说支持C#直接开发APP，C#要崛起了吗
非原生的App开发，一个都没能形成主流，反正都要经过学习才能掌握的技术，为什么不直接学习原生开发，坑还少一些。
另外，app时代已经过去了，还做app属于49年入国军，不要再自嗨了
