C#异步编程如何调试

[wxf54318]

使用asyn /await ， Task.进行异步编程如何对程序DEBUG，只能通过输出一些LOG吗

[以专业开发人员为伍]

基本上“无法调试”。极其简单的初学代码也许可以调是个几行，但是一旦遇到复杂的、大量异步操作交织的情况，绝对无法调试。因为那根本不是人脑所能记忆的信息爆炸场景。 好的开发不是调试，虽然我们常说“调试”，其实这是一个基本功。好的开发是“测试驱动”的，而测试驱动开发的结果就是往往出了问题之后并不需要怎么调试，就能立刻发现问题。因为测试驱动开发只做必要的事情，只做眼前的一点点事情，强调的是重构、自律、设计和充分理解。

[以专业开发人员为伍]

比如说我们要写一个“加法”过程，我们首先写

int plus(int a, int b)
{
    if(a==1 && b==1)
        return 2;
    else 
        throw new NotImplementedException();
 }

我们只要知道1+1=2就行了。然后当发现1+2无法将结果输出为3的时候，我们重构为

int plus(int a, int b)
{
    if(a==1 && b==1)
        return 2;
    else (a==1 && b==2)
        return 3;
    else
        throw new NotImplementedException();
 }

当问题复杂到一定程度时，我们才会写出复杂的代码，否则没有必要的时候不回去想当然地搞理论。 这种一步一个脚印的编程方法对技术要求更高，远比那些动不动就问别人“一共有几种情况、有没有什么开源软件下载”的做法的技术要求更高。因为充分地技术落地、不走弯路、快速迭代、轻松适应回归测试需求的测试驱动方法，当你遇到bug时，你往往可以迅速地看到前几次迭代重构的测试驱动机制所改变了的内部结构细节，或者你也可以有勇气断然放弃最后的实现而重新实现，你根本不用调试，而往往是在一个很小的迭代步骤中推倒重来（这往往是20分钟内的小迭代，绝不是把推倒重来一个大系统）。

[以专业开发人员为伍]

所谓的“调试、输出log”在这个时候其实都是比较低级的做法，是不得已的时候（比如我们必须发布出去、无法亲自动手重现问题场景）的保护措施。受限于工程背景和经验，你可能想不到更好更重要的debug的方法。其实最重要的是人而不是代码，一个大型软件（例如facebook）的代码可以让每一个人都能随时修改，只要他（她）保证提交到版本管理系统之前运行了几百遍自动化测试就行了，就能保证更快、更好、异常稳定、技术开放、但是别人偷不去。这种勇气的根本是来自于工程训练，而非简单地一些编程伎俩，所以满脑子如果仅仅有一些小伎俩是想不清楚的。

[threenewbee]

vs2017下可以下断点调试，甚至在catch里下断点。

[正怒月神]

断点+日志。

[以专业开发人员为伍]

对于复杂的、高并发的场景，你所打印出来的 log 跟你中断调试的结果一样，都是“乱的”。而把任何一个任务工作流的几百几千个甚至上万个异步回调都单独按照工作流编码、然后单独按照工作流来打印调试堆栈，并且还能清晰地显示出从一个节点发散出去的许多异步子线程节点的应有的逻辑排列，我觉得这可能主要是唬人用的（比如说一些卖相关软件的人最喜欢说的理论），而实际价值并不高。 实际上，每当我们启动我们的自动测试程序，我们都会把所有的测试用例先用顺序方法执行一遍，然后在打乱次序但是以顺序方法执行几遍，然后再来以（几十，几百个）并发方式来执行这些测试用例。最后才知道一个程序中一部分基本代码的质量好坏（这只能说明曾经考虑过哪些问题，并不能说明没有问题）。 说白了，一句话，高级的高性能的系统——特别是服务系统——的质量保证靠的是工程组织方法，靠人的自律自我组织能力，而不是什么简单的语句。

[以专业开发人员为伍]

我上面说过了，测试驱动开发过程中是一小步一小步地、“测试驱动地”去开发的。注意这里是用测试系统来驱动开发。 而有些人可能是启动了最终的应用程序，然后在程序界面上“点点点鼠标、敲敲敲键盘”胡乱地手动“测试”。这个时候你去跟踪调试复杂高并发异步程序，那根本干不下去。实际上程序开发的第一步就错了。编程的目的不是为了给用户用，而只是为了通过测试。测试的目的才是为了给用户用，所以测试用例经过专门地分析设计。但是编程过程不应该“乱乱地”去调试，而应该用工程化的测试驱动方法，这样当你开发过程中遇到绝大多数bug的时候，你凭感觉就能在几秒钟内发现问题、随手解决问题，而不是去花很多时间调试。