2018-08-23怎么判断一个代码的好坏，我总是不知道自己写的代码是不好还是好作者回复: 那就看看一些标准库或开源代码，找找好的感觉
9
2018-08-20感觉运维代码是最复杂，但是前期是最看不到收益的的。。。
但是却很重要，特别是项目规模上去之后。。。作者回复: 很多时候，运维类代码都成了技术债
9
2018-08-22突然想起了，福特曾经说过的一句话，如果我们去问顾客想要什么，他们会告诉我们想要一辆更好的马车，而不是汽车。作者回复: 😄，哈哈，经典的福特之问
7
2018-08-20恩，讲的很好！一门语言学会后，编程的困难在于对业务逻辑的理解，尤其对于业务背景和整体流程的理解，决定了业务抽象的层次的高低，和看问题的深浅程度！
大厂应该都有基础架构平台，各种维护性代码应该比较容易加，让业务工程师专注于业务。作者回复: 恩；业务大了后，都会工具化和平台化，才会有规模效应
3
2018-08-20项目时间太紧的一个后遗症就是deadline 只能保证功能代码调通。运维代码缺失，大量fixme：有空时再补日志，有空时再补错误码，有空时再补国际化，有空时……作者回复: 有空时，就忘了……😂
3
2018-08-21于现阶段的我而言 我觉得更难的是针对业务逻辑的抽象和实现 把业务逻辑的实现和业务相对应 和PM脑子里的概念相对应 让后来的人能看代码就能知道业务的所有规则 清晰明确的掌握业务 这个是最难的作者回复: 所有的代码都需要一定程度的抽象思维
2
2019-04-18第二次拜读这篇文章，但对于控制，和运维还不是很明白😭，作者可以在形象化点说明吗？😊作者回复: 那可能是你还没怎么写过类似的代码，所以觉得抽象，不着急，多做些事情，多写点代码，会恍然的😄
1
2019-03-10总结：
对于最终需要交付运行的程序代码，
从代码的用途(or使用场景)上将作者代码分为三种：功能代码、控制代码、运维代码。
功能代码，满足于用户需求，为实现特定的业务功能而开发。
控制代码，对代码执行流的控制，如并行、异步、限流、熔断、超时控制等。RPC、中间件、代理服务器等，应该是对代码执行流的控制。控制代码的需求，是从众多(已有的或预见的)功能开发中提炼而来，基于一些共性的特征抽取。源于功能而高于功能。
运维代码，用于解决运行过程中出现的问题，或者为解决问题提供必要的信息。
结合工作，我们做的防重组件，是控制代码。基于pinpoint实现链路跟踪，是对业界已有的运维代码成果的使用展开作者回复: 嗯，理解很对
1
2019-03-10控制不仅仅是业务逻辑代码的控制，还包括性能、容错等方面的控制。而且业务代码里也包含了逻辑步骤的控制，界定控制的边界是关键。赞同老师最后一句的观点，但落地需要一些好的方法论，后面继续学习。 1
2019-01-26没有完全理解控制代码究竟是哪一类代码。胡老师可以举更多的例子解释吗？作者回复: 比如并发，互斥，流控，隔离等控制代码执行的代码
1
2018-09-11老师对代码分类的很清晰👍
接触到的大部分程序员都希望更多的编写高技术含量的控制代码，会觉得写业务代码比较枯燥没啥技术含量，而且每个公司业务并不通用，请问老师我们平时学习中应该怎么平衡在学习两者上投入的时间精力呢？作者回复: 不用太刻意去平衡，哪里的需求更强烈就投入到哪。业务和技术是价值链上的两个环节，两个环比一个环更有价值
1
2018-09-06刚出来工作的我只想尽快熟悉各个业务功能，然后串起来，理清整个框架作者回复: 恩，刚开始都是这样的
1
2018-09-05"因为从用户心里想要的，到他最后得到的之间有一条长长的链条
极客时间版权所有: https://time.geekbang.org/column/article/13626
",看到这一点，您遇到过用户具备甲方攻城狮的情形么；是不是若产品经理不打算偷懒的话，甲方攻城狮那边其实没有技术职责？从技术上来讲，形同虚设是不是噢。。 1
2018-08-29一直纠结这个。终于看到了答案。作者回复: ^_^
1
2018-08-21最近的编程中这三个方面都体验到，如何分离不太懂 1
2018-08-20如何让开发正确理解产品的需求有哪些好的方式呢 1
2019-12-04拐回来又看一遍，还是受益良多。
平常很多时候都是写完功能代码就急着被催上线，现在更会注意一些三码齐全。希望coding越来越好
2019-04-16代码归类：
功能
控制
运维
2019-02-13业务，控制，运维三个层面的划分好清楚
2018-11-14优雅就是边界与距离，最后一句话说的真好作者回复: 🤝