回头望一望过往，从13年毕业至今，用手指数一数刚好能数过来，创过业，上过班，也搞过个人项目。
能力栈也从java、php、前端、产品经理、UI和平面设计之间反复横跳，反复折腾，🤣创过业的苦逼人应该都懂，后来主攻了前端，已经做了5年高级前端了。
最近自己行色匆匆地整理了一些编程方面的思考，聊聊自己对高级程序员的想法，当作是给自己这些年的一些总结吧。通过6个方面聊聊除了技术水平外，高级程序员应该具备什么样的职业能力。
一、代码风格很大程度决定了你的态度
代码需要有自己一贯的风格，包括命名约定、逻辑代码习惯、不写无用坏代码、语句块风格（如lambda表达式中只有一句话时省略return）、模块或函数注释、逻辑复杂部分注释，且注释需包含联系方式和时间，这样可以让后来者在需要求助的时候找到当事人，这也是对事负责的态度。
同时编码风格的追求体现了一种编码的热爱、一种不随意妥协的态度，当然也有可能是强迫症或洁癖发作，看不得不美观的东西。
二、人人都应具备解决问题的能力
通过百度、google、或者寻求同事帮助等方式解决编码中遇到的问题也是一个程序员的基础能力，而更高阶自独立思考能力在这边可以为你带来很好的提升效果。这边的问题可能会分很多类：
1、功能性问题，如上传文件时怎么才能成功、如何生成一张图片并返回图片流等等，这类问题通常是查资料、问同事朋友解决；
2、技术性问题，如怎样通过一个字符串生成二维码图片（当然你也可以直接用别人的库，省的自己造轮子），这可能也是钻研精神的一种体现，毕竟会造手机的人比会用手机的人厉害得多的多。这样一直钻研的人，久而久之就可以解决各种各样的问题，了解各种底层原理，离大牛之路原来越近了，但此时的你，可能头发也就少了好几根；
3、结构性问题，以下三个问题是更高阶人员才会遇到的问题，如我应该如何组织代码结构，模块与模块之间又是怎样的一种关系，当然你也可以完全不考虑这个问题，然后随便找个地方保存你的代码，或者干脆就写到一个函数里就好了，对功能和性能完全没有影响，但这样做你的心真的不慌吗？没有人给你code review出来吗？
4、协作性问题，一个项目大部分时候毕竟是很多人一起开发维护的，如何能保持大家的共同认知很重要，谁都不希望在同一个项目里重复造轮子，谁也不希望看到有人把代码搞乱，或把自己的代码搞乱。这时你应该需要用各种协作规则、编码规范，并用文档的形式记录下来，简单举几个例子，第一个编码规范让团队内的编码风格保持一致，这个最好理解却也最容易被忽视的东西。第二分工明确职责明确，编码前做好充分沟通进行分工且明确结构方案和技术方案，执行时不要干涉他人写的代码，而通过提交问题的形式让当事人处理迭代，同时将沟通时分配给自己写的公共模块记录到准备好的模块文档中并通知其他成员，做到信息一致。执行起来光有这些自然不够，还需要不断地code review来调整未按规定执行的代码。
5、项目性问题，正常是项目经理或产品经理需要考虑的事，项目迭代如何按时交付，这就要求项目内需要建立一个可行的开发计划，很多人可能会觉得制定开发计划就是一个坑，每天把自己坑到晚上10点才下班，久而久之就成了公司压榨员工的现象了。做计划是一件很难的事，我认为要解决这个问题，特别需要注意以下三点，第一个需避免计划谬误，每个人都会把计划美化，觉得可以做很多事，但做起来确是另一幅景象，遭受了挫败感，所以具体的事情要减少到原计划的50％到70％，让自己切实可完成，让计划为你带来成就感，第二个是预留30％左右缓冲时间让计划避免突发事情的破坏，第三个是保证执100％完成，这是达成任务获得成就感，从而增强信心的环境，如果任务制定太高了，就每天再往下降一点，知道可以确保100％按时完成。
其他问题也就不再举例列出了。
最后总结一点就是，问题解决固然重要，但不要为了解决问题而解决问题，知其然不知其所以然，又或者干脆网上搜索到的代码复制粘贴过来试，能跑通就不管了，全然不知问题的根本原因所在。
更好的做法是要去理解问题本身，找到原因并在自身内化。
三、模块抽象能力很大程度区分了程序员的层次
这个也可以理解为我们常说的封装，但又不仅仅是抽出代码封装，而包含了更多的设计思维在里面。
我认为这是区分中高级程序员很重要的一点，模块抽象能力代表了代码的组织性、灵活性、可理解度以及可维护性。
每一种流行框架或库的出现都代表了作者在模块抽象部分的新思维，ViewModel、Promise、Spring的ioc、aop这些，都代表了作者在抽象上的理解，才孕育出我们现在的各种技术、社区等。那我们在实际项目中的模块抽象，同样可以让代码结构拥有上面所说的四个特征，让项目更加美观。
模块抽象能力可以在项目设计阶段，以及下面说到的微重构阶段进行，让代码始终可以保持高维护性的状态。
四、用写开源库的心态设计你的每个模块
可能我是个开源爱好者的缘故吧，虽然我也没上传几个代码库，也没什么时间来维护。
但是在设计项目模块的时候都会不自觉地想象如果我要把它开源出去，它应该会有什么功能，哪些功能是我们现在会用到的，在编写前就把它设计得更加灵活，这样设计的目的是为了让模块或组件更能够减少日后项目变化带来的重构成本，也许有些功能在后面使用时已经就具备了，再到后面愈加成熟后再开源出来，供大家使用也是一个快乐的分享，而这些东西也就成了你的门面，当然前提是有足够的时间来维护，而不能让那些使用的人困惑于bug和未满足的需求。
五、微重构能力可让你的项目持续保持高可维护性状态
好的产品经理对产品会有更好的把控力，会制定出稳定可行的路线图，这对于开发来说是一件很好的事，因为这样开发人员编码时就可以根据产品路线图预留好相关功能的接口，从而让代码在日后迭代更方便。
但大部分产品可能不是这样的，产品路线图并不总是制定好的，产品经理经常需要根据市场反馈才能制定出近期策略，或者上面所说的路线图突然改变了，这时候预留的代码可能也要作废了，久而久之项目在这样的环境下改来改去，坏代码越来越多，可维护性越来越差，统一重构成本又太大，到后面谁都不愿意接这块烫手山芋了。
谁都没有对一个项目从开始就完美设计以后不再修改的能力，微重构就要求你在平时迭代时对之前因为需求限制，或没有考虑到的散装代码、未抽象的代码进行抽取重构，让代码一直保持在高可维护性的状态。
虽然会在迭代时额外花费一小部分时间，但这是为了在日后节约更多的时间和精力，同时也让新来者更容易接受项目维护。
一个微重构的例子：原本一个前端项目只需要和一个ip的服务器交互，此时的ajax请求可能一个简单的函数封装就可以满足需求，随着项目迭代，这个项目需要和多台服务器交互，很多人觉得函数中加个ip参数就可以了，需求实现了改动也小，心里美滋滋。但这样却违背了模块抽象的原则，灵活性也大大减小，此时根据微重构的角度则应该封装成一个ajax类，在创建对象时都有其独特的特征参数一一对应每台服务器，这便有了受欢迎的Axios。
并不是所有需要复用的代码需要微重构。
它大致可分为以下三点：
1、可复用抽取，绝大多数开发人员都知道这块内容，对原本只有一个地方使用到的散装代码在某一天给的需求中也需要这块代码，此时就是抽取这块代码的时候了，这边所说的"这块代码"不仅仅是包括一个代码块，它还包括一个更细微的字符串或数字的常量、一个配置项等；
2、相关聚合，在平时项目中，我可以很肯定你一定会把视图文件放一个文件夹，把工具文件放一个文件夹，把相关controller、service、dao放到一个文件夹，但在代码中可能又是另一幅景象，你可能会在想要的调用接口的地方直接调用接口，也可能会在A文件和B文件写满了sql语句，这些都和上面的文件分类截然相反。为了便于维护和统一管理，我们就需要将相关代码聚合在一起，如序列化和反序列化、构造和解析、接口操作、数据库操作等等，这些都可以看作是一些相关操作，可将它们挂载到一个相关类上，可单独写一个文件导出方法，也可以写成一个类。
3、模块抽象，这就和上面第三、四点所说的一样了，利用抽象能力重构原本应该抽象却没有抽象的代码。
六、让你的好习惯辐射到更多人
也许你自己也有一套行之有效的编码或项目管理心法，无论如何都请不要独享，把它传播给更多需要的人吧，因为这至少在两个方面可以让你受益：
1、与你的同事分享可以增进团队融合度，谁都希望与自己价值观相近的人共事，但要遇到这样的同事很难，这样的事大多数只存在于理想中，所以如果你的团队相处很好，请好好珍惜吧。
大部分情况是核心价值观和能力匹配度可接受，并通过不断地磨合来相互适应，提高融合度，这时团队成员的分享、辩论等都可以持续提高团队融合度，当然，从相反面也可以过滤核心价值观不够匹配的成员。
2、与朋友或陌生人等非共事关系的人分享进行价值输出，可以把这种分享看作是一种服务或一个产品，通过产品或服务对外输出价值，既让这份价值产出了更多的收货，又可以提升自身品牌信誉度。
从辐射渠道上，你可以写成文章、做成分享PPT，让它在同事之间流动，让它在BBS上传播。
如果你时间精力充沛，你也可以做成视频，然后去qq群、微信群、知乎、segmentfault、简书等等各大社交网站去传播。
相关信息
我是alova御用推广人🤘🏻🤘🏼🤘，alova是一个轻量级的请求策略库，它针对不同请求场景分别提供了具有针对性的请求策略，来提升应用可用性、流畅性，降低服务端压力，让应用如智者一般具备卓越的策略思维。