编程思想，着重表达的是思想二字。
这是一句废话，但真真确确。我想表达的是做事和思考的方式，和编程本身关系不大，只不过不好表述，尤其是让人很容易明白的表述。
授人与鱼不如授人与渔，这个大家都知道，应用到程序员行列，就是学会思考解决问题，而不是学习如何解决某个问题。
为了能表述的更简单直白，下面都是单个问题的事例，这样比较不枯燥。
程序员号称是理性动物，貌似因为和干的活儿有关，不知道是谁提出的，渐渐的程序员自己都相信了。但问题是，程序员还没有脱出普通人类的范畴，普通人类共有的非理性行为特征，作为程序员的你，怎么可能这么容易摆脱？
程序员的非理性行为更多偏向于趋向性，我猜测由于程序员更孤独，认同感会更强，所以趋向性比较明显，而一旦有了趋向性选择，表现的往往更富有激情甚至极端。
最明显的例子，就是受到鼓吹，接受某编程语言或某技术后，坚定站在保护立场，摒弃一切外来抨击（哪怕内心已经认同）。
我真是见过某个demo只有几个函数，注释里特地表明代码使用了OO思想怎地怎地……
面向对象只是在某个领域或针对某类问题，能更好的解决问题，仅此而已。
面向对象语言为了表述对象，做了更友好的语法设计，表达力更强。java嘲笑c++说我是完全面向对象的，c++反过来欺负c说你是面向过程的。
好吧，你都说是思想了，又跟语言有什么关系。你非要说c写不来面向对象，我只能说你c学的太烂。
这个问题可笑吗？一点儿都不，因为我身边很多人都认为可以，并使用Prepo转换后说：你看，可以的。包括好几年工作经验的都说咱验证验证吧。
这个问题的根本是位图的定义，搞清楚这个问题是不用去做实验验证的，不是浪费时间么。作为一个客户端开发人员整天和UI打交道，这种基本常识需要具备。
答案是：当性能不符合需求的时候。
你别笑，我见过太多的例子，看着代码问他为什么要这么写，他说这样效率高。问题是需要他考虑效率了吗？之所以问为什么这么写，是因为代码很晦涩难懂，容易出bug。如果写的漂亮优雅性能又好，自然最好。
效率永远不是最重要的，但太多人时时搞性能优化，搞后台的还有情可原，做客户端天天考虑性能就有点儿过了。
性能永远不是最重要的。
这要区分具体项目以及项目大小和项目周期。 如果是小项目不用考虑太多，基本随时都可以，经过充分测试验证就行。如果是大项目需要考虑的因素比较多。
也许你见过有些项目里的代码很糟糕，可能还是有名气的项目，大可不必嗤之以鼻。重构代码的代价是比较昂贵的，牵扯到历史需求问题，牵扯到业务之间的耦合关系，牵扯到项目周期，甚至牵扯到商务问题。假如对项目了解不深，迫不得已还是不要改，愣头青的热血一头扎进去结果经常是头破血流，个人还好，就怕拖累整个团队、部门或公司。
在重构的必要条件到来时（如bug，性能等），最好在版本初期做修改，最起码在质量部门介入之前修改自测完成。
项目的复杂度分两个纬度：一是技术复杂度；二是人的复杂度。
个人的认知是：项目的复杂度从来都不是技术问题，而是人的问题。这里的人泛指与项目相关的所有参与人员，包括直接客户、间接客户、用户、领导层、决策层、产品、测试、研发等。
再考虑上技术复杂度以及项目周期等因素，要想做好一个项目，真的很不容易。很多好的项目可能在摇篮就被扼杀掉了。
这种说法本身没有什么错，但什么才算精，是值得商榷的。程序界不存在独孤九剑这种逆天招式，技术和学科一样具有相关性，所以很可能你在达到中级或高级时，就会碰到壁垒，原因是其他学科的基础支撑不够。
举个最简单的例子，原先搞java的很多，真正对虚拟机机制、并发、异步IO等知识了解的并不多，更多的是拿来主义，一旦碰到线上问题就捉肘见襟。反过来搞C和C++的对这些理解更深入些，不过对模式、容器、架构等上层应用理解没有搞java好。
真正要达到精的地步，必然会在某个层级涉及其他领域，反过来再促进作用。
现在的程序员是幸福的，无论什么问题网上一搜，90%的问题都能得到解决，对网上的资料归纳总结加上自己的思考，再能解决9%的问题。
这种习惯造成很多人不看官方文档。
于是，导致很多讨论沟通都是无效的。有很多真实场景发生，比如在解决问题时，需要确认hashmap是否线程安全，有说安全有说不安全，网上搜一堆信息说法还不一致，半天没个结果。问题是这种事情必须以官方为准，除了官方谁说都不算，让小弟看官方文档，回答是英语不行。好吧，我的做法是：打开官方hashmap文档，在满篇的英文中搜索thread，找到thread safe或thread unsafe。
这是方法问题，不牵扯其他。类似的问题有太多，随便在网上找了篇文章下定论，给你争论的面红耳赤，我只问一句：官方文档怎么说？
当然，官方文档也不是都对的，最权威的还是源码，文档和源码不一致时（源码不开放的可以参考头文件描述），以源码为主。
作为程序员，要有理由怀疑一切，追寻到问题的根源，并经过自己的验证。
还有一点是时效性。不同时间看待问题解决问题的方式不一样，所以无论文档也好，代码也好，注意下时间和版本日期。
作为一个程序员，始终认为谦虚是必备品质，只有谦虚才会更快的进步。
因为只有谦虚，才会站在别人的立场考虑问题，扬长避短；只有谦虚，才知道自己的不足，努力学习知识，怎么可能不进步呢。
自信，是对自己技术的自信，对自己解决问题能力的自信，碰到难题就莫名的兴奋，一心想搞定它。
只有具备了这两样，我认为才是好的程序员（虽然我现在已经不那么谦虚了）。
抽象是软件设计的核心，在软件工程周期中，抽象在不同层次不同环节均存在。 例如，设计本身就是一种抽象，架构设计、框架设计、编码设计都是抽象的行为，站在不同的视角抽象的结果不同，所以设计的本身就是站在不同视角对事物进行抽象，抓住核心需求找到最合理的抽象结果。
无论面向对象思想还是函数式编程思想，或者设计模式、架构模式也罢，都要对抽象深入理解。
使用 C++工作5、6年了居然不知道32位平台指针占多少字节，5年 java 经验不知道切面实现原理。
不懂基础算法，不懂网络协议，不懂 IO，不懂多线程……
那么技术怎么成长呢？一旦面对复杂些的问题，或陌生的领域，估计连解决思路都没有。 上层应用可以工作需要时再学，但基础功不够，临时学就晚了。工作时间越长越知道基础功的重要性，也在不断的加深基础积累。
之所以单独提出这个概念，是因为发现客户端开发人员普遍比后台人员随意。
这种随意包括在网上拷贝一段代码直接使用，不经过测试和验证，只看结果是自己需要的就算合格。还有产品问研发这个需求可不可以落地，很直接了当的给出结果，没有经过深思熟虑，或者在网上搜索一下，也没有经过验证直接出结果。还有关于敏感信息也几乎不考虑安全问题，异常考虑也缺少范围。
造成的原因可能是多方面的，大多数情况也不会造成灾难，反过来说，即便慎重也不见得不会出错。
但我想说的是态度问题，谁都会犯错，这是不可避免的，但如果错在很低级的问题上，错在随意性上，你会不会觉得不值？比如前段时间 xcode 感染事件，一批的一线互联网公司出品的 app 被感染，真是很难让人想通，一线公司缺这点儿带宽？
作为一名员工，要有基本的职业素养，大部分技术人员也都是这么要求自己的，但总有一小部分不屑这么做。
我不知道职业素养会不会对自身有负面影响，但既然作为一名员工，拿着公司发的薪资，那么理应遵从基本职业道德。
遵从的目的倒不是为了成为好员工，而是方便公司管理。管理是公司很大的问题，没见哪个公司敢说自己公司的管理没问题。
所以遵从基本职业道德，会促进公司管理，管理提升公司进步才会有好的效益，从而反哺自身。这是很简单的辩证关系，但生活中确实有些人不明白。
无论是什么工作，都会有服务的客户，一般我们总是想办法更好的服务客户，对应到软件行业，就是更好的理解客户需求。
需求不是个简单的事情，不是客户说什么就是什么，而需要挖掘客户潜在的需求，解决这个问题需要对客户业务的熟悉，以及需要良好的沟通。
而我们常常采用另一种方式：把自己幻想成客户，模拟某种场景然后做出决策，并把决策认为是客户希望的决策。这是因为把自己带入客户角色中，最终成功欺骗自己，认为这个决策是客户（或客户中的部分和个体）需要的。
事实上，结果往往相反。
技术人员大都比较执着或者说是固执，这也导致同行之间的技术交流比较困难。心直口快的会跟你争个面红耳赤，腼腆的表面很认同，背后一脸的不屑。师傅与徒弟之间的授业还好，同层级之间即便你分享若干经验，他学习到很多东西也不会认为是你的功劳，而认为是自己的努力。
程序员是极爱好面子的一种群体，牵扯到面子问题，极有可能他是死不认账的。
做完铺垫，来谈谈技术交流的形式：
1、具体技术交流。
2、技术思想交流。
大家都爱按照第一种形式交流，符合程序员的特质：直接、具体，容易落地。也许你不同意了，说大家更喜欢技术思想形式的交流。好吧，我同意这种观点，但真正做到的已经非一般程序员。
前面说了，程序员都是固执的，两个固执的程序员交流思想大都是一个结局：一个人想把自己的思想强加到另一个人头上，另一个人感觉受到了侵犯，拼命反击，最后不欢而散。改天再谈，还是谈具体技术吧，大家都happy，因为具体技术很容易得出结论，符合程序员的特质。
但是大家都是玩逻辑的，都明白第二种交流形式更具有价值。那么如何能够更好的碰撞思想？个人认为技术思想的碰撞，不是为了追求真理，寻求共鸣，而是为了实现自身技术思想体系的补全。非是要说服对方，而是表达自己的思想供对方参考，同时学习对方的思考方式，补全自己的不足。如果大家都有这个基础认知，那么思想碰撞就不存在问题。
这也是为什么前面章节会提到要谦虚，只有谦虚以及学会感恩才能容纳百川。
学会看别人思考问题的方式，比如何解决具体问题要有价值的多。 但最终奥义是形成自己的思维方式。