代码与工程化
码代码与工程化
编程是一个世界，算法是这个世界的高山大河。但世界不只高山大河，有不起眼的平地，不壮观的村子，交错的道路，立体无限的空间。
算法不只是哪种排序方式大 O 最好，还是当下哪个方法更合适。算法不只是课本上的那些经典，更是正在发生的没写进课本的，解决生产问题的那些。
编程等于数据结构加算法是学校老师爱说的，他们要简化教学模型。
但你自己要学会拥抱世界的混乱，这才是程序员真正面对的。 编程：搭积木 基础编程能力：能把积木按照图纸搭得又快又好 高级编程能力：熟悉每个积木快的性能(即熟悉基本的数据结构和基本的算法 —– 熟悉，表示“知道怎么回事但不需要能亲自用代码写出来，能用伪代码描述清楚即可”)、能设计出最符合要求又易于操作的搭积木的图纸
算法：来我们研究下每个积木块的内部细节，谁能把这些细节做得更优谁就是算法高手 ACM 竞赛：来来来！我们来研究下这些几万年都不会用到的、几百年内也难以商业化的积木的内部细节！！！(请轻喷)
不。编程是一个系统的工程，其中包含非常多种方面的能力。而对于编程所要解决的不同类型的任务而言，所需要的能力的侧重点也完全不一样。如果要列举一下的话，我认为至少有如下。
编程的思想。也就是计算机解决问题的基本思路和模式，比如对于各种选择，循环，递归控制过程的掌握。通常来说在人们学习第一门编程语言的时候实际上就是在学习这方面的技能。可以说面向过程，面向对象，函数式编程等也是这个类别里面。对于编程语言的语法，规范，最佳实践等的掌握。对于已经有 1 的基础的，学习一点点基础的语法即可很快的对另一门新的语言上手，这也是很多人说学习一门新的语言很简单的原因。但是需要知道，每一门编程语言都有自己的细微的特点，要达到充分的掌握并非常熟练的使用，还是需要花费很多的功夫来学习的。能够对于要解决的特定的问题选择更好的时间和空间开销的解决方案的能力。通常来说也就是数据结构与算法的能力。虽然算法可能是一个非常宏大的概念(任何用计算机编程解决问题的方法你都可以叫做算法)，但是这里我们可能主要侧重于对于一个问题的时间和空间复杂度的分析和优化。对于标准库，系统 API，以及第三方类库的了解和熟练的使用。需要能够知道这些库的具体逻辑，能够有能力快速的在文档中查找到自己需要使用的合适的 API，或者选择使用合适的库。能够合理的组织代码，达到易读，易扩展，易于变更等。能够对软件项目的开发过程当中的各种方面进行合理的组织和管理。通常就是设计模式和软件工程。能够对计算机系统本身有足够的了解，对编程过程中直接或者间接使用的工具有足够的了解。通常说来着意味着对于计算机组成，操作系统，编译原理，网络原理等计算机系统基础的深入学习。虽然计算机体系的设计都尽力的把下层封装成一个黑箱，使得上层可以不用考虑黑箱中的细节。但是这种封装其实不可能完全隔绝这种差异。很多时候你都需要对更底层的东西有更好的了解来帮助你设计上层的系统。这对于性能的提升和问题的排查实际上都有着很积极的作用。对于要解决的问题相关的特定领域的知识。对于不同种类平台的应用开发，计算机科学里面的各个子领域如人工智能，图形学等。这涉及到你如何能够应用编程的能力来解决实际的问题。能够熟练的使用一台计算机，包括但不限于熟练的安装各种软件，解决系统问题，配置奇奇怪怪的开发环境。有足够好的英文阅读能力，有足够强的自学能力，有足够强的在互联网上有效的检索信息的能力。有进行抽象的复杂逻辑思维的能力。 对于任何真实世界中的问题而言，都必然是一种系统的工程。这都涉及到综合运用你拥有的能力和资源，对其进行合理的优化配置，对于要完成的目标进行必要的取舍。对于每一种不同的具体任务而言，对于以上每一种能力的要求都是不一样的。简单化的描述编程能力主要应该是什么，都是不恰当的说法。
科研机构/学校：我们会研究所有积木快包括那些几百年内也难以商业化的积木的内部细节 大多数公司：我们是搭积木的 少数公司：我们主要也是搭积木的不过我们的积木比较专业所以我们也会做一些针对性很强的一般公司不会用到的积木快的内部细节研究
The essence of software development is composing functions and data structures. Why do so few understand function & object composition?
难在复杂性的持续增加。如果编写一段写完就扔的代码(如运维修复)，那其实是可以很快做好的，想不通的地方绕一绕总也能搞得定。但当你编写的是一段大规模使用，需要持续改进，并且不断有新功能需要添加的代码。那么难度就急剧增加了(这也是我认为的编程的主要难处)。一方面，最开始编写代码的时候就要考虑到以后的扩展性，而这个考虑又永远不可能是完备的，也不应该是完备的(不要过早优化)。只有一些基本的原则，比如保持单模块的独立性，避免模块间的耦合，这些原则的运用需要丰富的经验，并且不一定总是用好了。另一方面，在代码的持续演进过程中，需要对抗代码的腐化。当原来拍着胸脯保证的确定因素突然变成不确定因素；当代码引入了不合理的功能(如需要理解上层逻辑)；当有新的人来维护代码。代码腐化的结果是大大增加了工作量和减少了代码的稳定性。(代码腐化只有一个好处，天天加班，显得事情很多，搞不好能把领导唬住)