德
在整个信息爆炸的时代，我们每天都了解到了大量的信息，也学习到了很多的知识，然而却一直没法感觉到自己的智慧。带着这个困惑，我想探究一下到底什么是
智慧，我们在软件编程过程中，又需要怎么样的智慧？最后，我们怎么样才能获得这些智慧呢？梦孤先在这里抛转金玉，希望能得到大家宝贵的经验分享。智慧的碰撞相信会让大家更有智慧。
智慧的定义
智慧 是生命所具有的基于生理和心理器官的一种高级创造思维能力，包含对自然与人文的感知、记忆、理解、分析、判断、升华等所有能力。智慧与智力不同，智慧表达智力器官的综合终极功能，与“形而上之道”有异曲同工之处；智力则谓“形而下之器”，是生命的一部分技能。
在我们的日常生活中，智慧体现为更好的解决问题的能力。
智慧怎么获得
知识并不等同于智慧，智慧不是通过书本学习、听讲而带来的成果，而需经过自己的努力和实践才能获得，必须依靠自己的努力去得到智慧。 是的，在课堂里，我们花费了很多时间去研究他人的问题，等到我们进入自己的活动境地时，我们却会发现我们正从事的是另外一种学问。在那里，的确有不少有待做出解释和需要解决的问题。 我应让年老多病已到晚期的病人继续忍受痛苦呢，还是拔掉使一个垂危的老人延续生命的插管呢？在我们的生活中，经常会碰到诸如此类使人进退两难的例子。我们常常祈祷，如果有足够的智慧能正确行事就好了。我们只有自觉而努力地去解答我们生活中出现的问题，才能获得真正的教育。从人性的角度和与他人的关系做出决策，例如与我们的配偶、我们的孩子、我们的上司、我们的助手、我们的朋友和邻居等等的关系去做出决定，这就需要我们承担采取行动以后如何相处的后果；还要思考我们的行动可能对别人所起到的影响。这才是我们必须取得的真正学问。我们所面对的这些真实的东西不会给我们文凭。 重视和注意交织在我们生活中的快乐和痛苦、挑战、失败以及许多偶然事件，我们所得到的将大大超过学问和知识。我们要重视我们自己所受的磨炼和赢得的胜利，更要重视别人经受的磨炼和获得的胜利。对这些事给予关心和反省、推理和思考，将能使我们的学问和知识不局限于书本和课堂，它使我们受到的不仅仅只是教育而已。如果只有学识而缺乏推理和思考能力、关怀同情的美德，那么，这种学识只能用作腐朽的卖弄而已。 关注我们自己和我们同伴的生活，这就是我们取得智慧的来源。 苏格拉底告诉我们：“没有经过检验的生活是不值得留恋的。” 我还想大胆地对苏格拉底的格言作一补充，不仅我们的生活需要检验，我们还必须注意他人的生活，力求了解他们的快乐和痛苦、愿望和忧虑、成功与磨难，这种关怀及由此延伸出来的爱护，能使我们活跃思维，增添气魄。 这就是使我们变得聪明起来的途径。
来源：《演讲与口才》，作者：[美]西奥多·鲍威尔
编程的智慧体现在哪些方面
按照智慧的定义，编程的智慧必然是体现在解决编程中的特定问题的。编制中的问题我们每天都会碰到很多，比如：
- 这段逻辑是应该独立封装成一个工具类，还是封装到一个基础的父类中？
- 要新加的这个接口，和之前的接口有一定的相似之处，是在原来接口上做修改，还是独立一个接口？
- 这些数据的存储容器是该用数组还是链表？
之类的问题有很多很多。面临这些问题时，我们常常会纠结于怎么做出最好的决策，这非常考验我们的智慧。结合这些年的工作经验，我觉得这些问题总结起来，主要可以分成以下几个方面：
- 代码逻辑清晰、可读性好；
- 质量可靠；
- 性能；
- 开发效率；
- 扩展性；
编程的智慧
下面我们就从这五个方面，来一一分析一下。
1、代码逻辑清晰、可读性好
阅读源码是我们学习编程路上必不可少的一个部分，但是源码阅读的过程常常让我们痛苦不堪。各种个人的命名习惯、代码的写法，都让我们很难理解作者的意图。这些框架源码的代码相对来说还是非常优秀的了，他们的代码逻辑性、可读性还算是比较好的了。我们公司自己的系统代码往往要更加的凌乱，特别是注释和测试用例的缺失，让我们在修改遗留代码时，总是如履薄冰、提心吊胆。
所以我们常常会因此而产生强烈的意愿去写出逻辑清晰、可读性良好的代码。但是我们在实际写代码的时候，却往往很难做到条理清晰、命名准确、注释完善、测试用例覆盖全面。我们常常感叹，我们学习了很多的设计模式，学习了很多的数据结构和算法，熟悉了很多框架的原理，然后自己写出的代码依然是一堆垃圾。
我觉得要做到代码逻辑清晰、可读性良好，是需要足够的智慧的，而这种智慧的根本，是“礼”。就是儒家思想中“礼智仁义信”里面的这个“礼”，这个礼体现的其实是尊重。我们都知道，人与人之间交往首先是尊重，而一个软件，从根本上来说，是工程师与用户交往的载体，也是一种交往的方式。然而，我们软件行业到处充斥着急功近利，公司只想要业务快速落地，产品经理只想要产品快速实现，技术主管只想要大家加班加点快速码代码。。。。各种各样的急功近利中最没有考虑的就是人，公司没有起码的对工程师的尊重，工程师也同样没有起码的对产品的尊重、对用户的尊重。
从工程师本身来讲，行业的现状、公司的现状都是没有能力去改变的，但是我们可以在自身能力的范围内，尽量不受到环境的干扰，回归到尊重的本质上来。深刻体会与用户这个交往的过程、深刻体会与后续开发者的这个交往过程，我们一定会源源不断的产生灵感，这些灵感不断积累就会造就我们的智慧。
2、质量可靠
产品质量相信是每一个销售、售前、实施、运维人员心中的痛，多少次在客户的现场演示被打脸，多少次被迫给客户说“我们是技术有限公司”。当然一个产品的质量往往和这个公司的大环境是分不开的，抛开外部因素不说，在工程师个人能力范围内而言，可靠的质量也是每个人必然的追求。毕竟谁都不希望自己开发的产品在线上发生生产故障，然后半夜爬起来修改bug，再火急火燎的发布补丁，回头还要被经验总结。
既然从公司角度、从个人角度，其实都是希望能产出一个高质量的产品的，怎么就最终产出了一个千疮百孔的破玩意呢？公司明明制定完整的质量保证流程，大家也都执行了，怎么就没有起到应有的效果呢？
质量的保证是由需求的清晰、代码质量、测试完备、运维保障等各个方面来组成的，对于工程师而言，往往会觉得质量也不是我一个人的事情，后面反正还有测试进行把关，实在不行多改点bug就是，现在还是抓紧赶进度先。这种想法应该代表了当前行业的“人之常情”。
开发高质量的代码，是需要足够的“义”的。“义”在现在我们更多的解读为责任，我们一生都会背负很多的责任，为人子的责任、为人夫/妻的责任、为人父/母的责任、为员工的责任。。。。柴静在《看见》这本书中说过一句话“一个人的强大，不在于征服多少，而在于承担多少”。我们的自由把“义”当成自己的本能，才有可能拥有支撑起质量可靠的智慧。
3、性能
在传统软件开发中，一般对性能不会太关注，最多也就是在数据库层面优化一下sql完事。但是随着互联网的兴起，大量大高并发场景出现，我们的开发新的产品时，动则要求上万、十万的并发。当然在大的层面上还是要靠对资源解决的，在工程师的开发层面，要保证的是在一定的资源条件下，足够支撑当前阶段业务规模，并在增加资源的情况下，能取得线性的性能提升。然而性能应该是对工程师技术能力最大的挑战了，毕竟性能优化是没有尽头的，性能的提升过程也是一点点的抠出来的。而且颇受讽刺的是，对性能提升最明显的，往往是对业务的改造。当然，足够的性能也是每个程序员天然的追求，这是大家的骄傲之所在。
但是对性能的追求是需要足够的智慧的，这个智慧中首先需要我们前面说的“礼”、“义”，在这个部分还需要更多的“智”。这个“智”并不仅仅是聪明才智，更重要的肯能是对专业的热爱、持续的研究，以此积累的专业判断力和解决能力。
4、开发效率
一个企业的竞争力拼到最后，都会体现在“效率”二字上，对于软件公司，开发效率又是其中的重中之重。怎么提高开发效率是每个软件公司的追求，各种开发管理流程、绩效管理方式层出不穷。瀑布模型、RUP模型、螺旋模型、敏捷开发、XP极限编程，绩效方面也大名鼎鼎的KPI和OKR等等。但是也没有那个公司能说得清楚自己的开发效率值到底是多少，今年相比去年到底提高了多少个百分点。
所以在对开发的管理上，作为公司高层总是有着很深的危机感的。这种危机感来自于没法对开发过程进行量化，没法对提升开发效率做出有效的决策。业界唯一的办法就是加班、加班。。。
程序员自身从自我价值的角度，当然会本能的会去学习各种提升开发效率的方法：利用成熟开源框架、在公司内部封装复用组件、在开发之前进行详细设计、不断的学习新的技术，可以说程序员学习的新技术99%都和提升开发效率相关。但是开发效率从管理角度还有一个需求，就是可控性，可控性是传统工程进度管理里面的概念，主要是为了能按期将项目交付甲方，而采取的有效管理手段。但是在软件工程领域引进后，直接的后果就是大家加班。所以其实工程师对开发计划是天然对抗的，他们觉得开发计划是对他们创造工作的不尊重，直接扼杀了他们创新的动力。毕竟保证可控性的最好方式就是重复，重复的工作才能轻易量化，量化之后才能保证可控。
那我们怎么突破这个怪圈呢，我觉得同样可以在儒家思想中找到答案：“信”。信是诚信、信任，它同样是人与人交往的基础。这两年了解到很多公司都在逐渐采用OKR，但是却把它用来作为管理员工的工具，我觉得是非常可悲的。我理解的ORK是一套沟通机制，它的根本就是信任，没有这样的基础可以说最后就是领导者觉得ORK还得配送KPI，然后又变成了逼迫大家加班的工具。
作为程序员，要想提高自己的开发效率，首先是和团队建立信任，信任是一种强大的理论，会让你逐渐开放、包容，能和别人无私共享，当然最终必然会共赢。这个共赢里面，就包含了智慧。
5、扩展性
只从编程出现以来，扩展性就一直是顶级编程大师的追求，也直接导致了一代又一代的编程语言出现。其中在上世纪90年代出现的面向对象编程模型，将这一特性发挥到了极致，也造就了Java语言30年的繁荣。
就专门的扩展性而言，成就的最高峰应该要数四人帮在1995出版的《Design Patterns: Elements of Reusable Object-Oriented Software》 ，这本书里面总结了行业沉淀的23种设计模式，为广大程序员在面对各种情况下设计扩展性良好的代码结构，提供了可供参考的编程范式。
在“技”的层面，当然远不止这些设计模式，在分布式架构下也有很多保证程序扩展性的手段。但是如果仅仅是停留在“技”的层面，我们也只能做些依葫芦画瓢的工作而已。要想在扩展性上拥有足够的智慧，我们得提高自己的对问题的抽象能力，而抽象能力又需要我们对事物、对人与人之间的关系有足够深的认知。如果了解过心理学或者佛教教义，应该会知道，我们对外界的认知，其实根本是我们对自己的认知。我们的这些认知能力又依赖于我们认知到自己爱、喜悦、和平的“真我”天性。
所以自我的认知决定了对世界的认知，对世界的认知决定了对事物的抽象能力，最终就会体现在代码的包容性、扩展性上。
总结
一个人如果不是真正的有道德，就不可能真正的有智慧。智慧是参照更多人的角度去思考问题，只有那些善于为别人着想的人才配拥有智慧。可见，智慧是为大众服务的，是以道德观念为前提的。一个人要拥有真善美的思想和大忍之心（即报着吃亏是福的想法）的人才有可能拥有智慧。学习可以拥有知识，我们常说有了知识好象也就有了智慧，其实知识不等于智慧。知识是内容，而智慧是方法，是活用知识的技术。
网友评论