个人成长经验
[TOC]
什么才是所谓的编程能力？如何考核？如何提升？
所谓编程能力，指的是把“逻辑”（或者说“功能”“业务”）翻译成代码的能力。所谓编程能力强，指的是，不仅能编写正确的代码，而且编写代码的速度很快，写出来的代码 bug 很少、性能很好、质量很高。
更加具体点讲，一个编程能力强的人，能熟练使用编程语言、开发类库等工具，思路清晰，面对复杂的逻辑，能够编写出 bug free 的代码，能够合理地利用数据结构和算法编写高效的代码，能够灵活地使用设计思想、原则和模式，编写易读、易扩展、易维护、可复用的高质量代码。
如何考核
考核一个人的编程能力，主要包含三方面：编程语言、数据结构与算法、设计思想、设计原则和设计模式。
不管从事什么行业，要积累的东西都可以分为“变”与“不变”两类。==“不变”的是内功，“变”的是招式==。我们要善于发现、持续积累那种“不变”的能力，而不是要去盲目追逐一直都在“变”的招式。
编程领域，不变的东西：
- 技术上：数据结构，操作系统，网络，设计模式，数据库(SQL、NoSQL)、MQ
- 非技术：产品意识（关注问题本身，而非产品的需求文档）、沟通能力、快速定位发现问题的能力
如何提升
算法与数据结构：刷 LeetCode，不仅仅能加强个人对数据结构和算法的掌握，还能锻炼你的逻辑思维能力，写出 bug free 代码的能力、快速实现复杂逻辑的能力，也能锻炼你的性能意识
设计思想原则和模式：平时工作中“刻意练习思考”
- 拿到一个需求时：先思考如何设计，再开始写代码。
- 写代码时：多思考代码是否遵循了经典的设计思想、设计原则。如：是否足够可扩展、是否满足 SOLID 原则、可读性如何、可维护性如何、代码是否有进一步优化的空间？
- 做 Code Review 时：看到别人的优秀代码我们就去思考一下：有哪些值得借鉴的地方
问题：将 IPv4 地址字符串（仅包含数字、点、空格）转化成 32 位整数（32位的二进制数字）？
基础学科的知识，如何转化程实际的技术生产力？
-
没有直接用得上并不代表没有用：事实上，“二八法则”适用于任何一门技术。我们能够经常用在工作中的那部分，都只占 20% 左右，近80%都会用不到，但往往这 20% 需要的知识是需要其余的 80% 作为辅助依托的。好比：有一个人想要一个葫芦，于是他就种了一棵葫芦树，葫芦树叶子生了虫子，有人建议他赶紧杀杀虫。这个人却说：”我要的是葫芦，管葫芦叶子干嘛”。
-
现在用不到并不代表以后用不到：你高数、微积分学的再溜，口算可能依然赶不上市场买菜大妈们，但是换一个工作环境，那你的这些知识能让你在工作上甩几条街。因此：随便培训3-5个月的人，就能掌握框架、工具熟练的进行编程，但是牢固的基础会让你在后面的工作时间中，优势逐渐凸显出来
-
学了记不住并不代表白学了：学习本身是一种能力锻炼，是让你在遇到问题的时候可以快速检索曾经看过的知识，而不是为了考验你“记忆力”。从：自学能力、理解能力、逻辑思维能力，到：时间控件复杂度分析能力、分析发现解决问题的能力，这些都是学习能给我们带来的锻炼。
比起编程语言、框架、工具，基础学科知识确实很难直接转化成生产力，但它却是你构建整个“技能树”的根本，构建整个“知识大楼”的地基。基础掌握不牢，你对很多应用层技术的理解就会不够有深度，略知皮毛，只能做个技术熟练工。相反，基础扎实能让你学东西更快、更有深度、理解更透彻，也就间接地增强了你的开发能力。可以这么说，在一定程度上，基础知识本身，就是技术生产力。
程序员怎么才能让自己走的更高、更远？
- 技术方面的竞争壁垒主要来自：==在一个细分技术领域长期、深入的积累==。
- 业务壁垒：对某个业务有深入的积累。实际上，很多领导之所以能做领导，并非技术能力强，而是对业务熟悉。
- 技术、业务都没有什么复杂度，能做就是多积累自己
- 学历、项目、履历毕竟是入场门票，所以要适当学会：“面向简历打工”“面向跳槽打工”，提前做一些职业规划，把自己的履历弄好看点。
- 不要让职场软技能成为短板：职场不是学校，影响你向上发展的因素很多，肯定不是单靠技术，所以，学生思维要不得。
作为面试官或候选人，如何面试或回答设计模式问题？
- 能盲写常用的设计模式，要求并不过分，毕竟在开发中，徒手写个单例模式、工厂模式，也是常有的事情
- 但，学习设计模式的初衷是：提高代码质量。学习设计模式的重点：掌握应用场景、能解决哪些问题，而非纯考验记忆
- 用真实功能需求来面试：
- 明确需求：考察你的沟通能力、分析能力，是否能通过挖掘、假设、取舍，搞清楚具体的需求，梳理出可以执行落地的需求列表
- 设计与实现：由最简单的设计和实现方案做起，基于最简单方式后可以通过什么设计模式进行优化，对代码进一步解耦，提供代码的可读、扩展性
- 通过对代码片段进行 Code Review 来考察：考察编程能力、习惯、设计、改进优化。
如何接手一坨烂业务代码？如何在烂业务代码中成长？
-
要想接手一个业务系统，前提是要读懂代码，而读懂代码的关键，是要熟悉业务。代码只是业务的翻译实现，对照业务看代码是事半功倍。
-
没文档、没熟悉业务的同事，那么只能硬着头皮读代码，反推业务。将读懂的代码业务进行文档化。
-
偏底层的开发更加考验程序员在某一细分领域的技术深度，偏业务的开发更加考验程序员的能力，比如沟通能力、分析问题解决问题能力、权衡取舍能力、架构能力等，毕竟业务多种多样，问题千奇百怪，单一细分领域的经验很难应对所有问题。
-
业务系统的开发难度一般来自两个方面：高性能要求和业务复杂。
-
解决性能问题，主要依赖：技术广度、技术深度、工作经验。
你需要具备一定的架构能力，有一定的技术广度，需要对各种基础架构、框架、中间件都有所了解。光了解还不够，还要有一定的技术深度，最好能对原理甚至是源码有所研究。
-
业务复杂性，需要有很强的业务建模能力、复杂逻辑的抽象能力、代码翻译能力等。
-
