最近有幸收到掘金的邀请，成为掘金专栏的一份子，唯恐自己不能有太多有质量的贡献，但又想到这是一次锻炼和学习的机会，所以非常感谢掘金！
刚好今天不是很忙，于是思索着来写些什么！正好前段时间想写一个关于工作、学习的总结，于是今天就献丑了，在这里抛砖引玉！原文地址 因为觉得有些地方可能别人可能有更高见的地方，欢迎issue上来于我学习，不胜感激！
目录
- 1、你先上爱上这份工作
- 2、要有专的能力
- 3、先理论基础，再实践
- 4、找一个点持续关注它
- 5、你必须有个业余爱好
- 6、锻炼一种“写”的习惯
- 7、搜索引擎用google，看文档尽量看英文版
- 8、你要扩展自己
- 9、善于以更好的方式替代原来不好的方式
- 10、如何在团队中做的更好
- 11、写技术文档或开发用例文档
前言
- 其实心中刚冒出这个题的时候，我也觉得有些不妥，总觉得这样的话题起高了，以我现在的资历恐怕难以有相关的“素材”来完善这篇文章。总感觉写不好，但我最好还是说服了自己，因为不仅仅是表达观点给别人，也是我自己对我之前所做的工作的一个总结，总结总是能让人学到东西的，何乐而不为呢！诚然，我最初的看法认为一个合格的程序员只要具备以下几个点就好了：
1、足够的脑力软件基础；
2、跟随一个好的团队混几个项目经验就好了；
3、足够强的自学能力、自觉能力及耐力。
可是我发现，如果已经具有这些能力、阅历的情况下，那么确实可以说你已经成为一个可以“机械式”写代码的程序员了，但是你自己本身也就成了像你写的代码了那样的“代码”了，需要维护人员时刻维护才能正常运转，或者说必要时候，需要全部换血（补充自己）才能解决已经存在的问题！
在继续写后面的内容之前，我其实想问一个问题，如果一个人不具备上面的几点或者部分，他能不能成为一个合格的程序员呢？其实是可以的，这也就是我写这篇的文章主要想表达的————我并非是想来一场不符实际的批判，而是想谈谈已经成为程序员之后如何扩展、弥补自己。亦或还没有进入程序员的世界，怎么了解它，有什么“捷径”可以征服它，这就是我想表达的。
好吧，进入正题
- 首先说明一下上面三个点的不足：
1、确实，一个人大脑转的不是很快的话，相对来说做某些事情会慢一截，但是并不妨碍他把事情办好，更何况，如果在一个team中，一个人的这种大脑运转很快的发挥的相对作用影响不是很大，因为从一个team的点出发就大打折扣了，team更多的是需要团队协调性，并非某个人的“特立独行”。再做一个比较形象的比方：马云大家都知道吧，身为一个万亿级的企业老板，难道仅仅是因为他个人能力、脑力特别强吗？非也，因为如果假如公司就它一个人的话，我想他再厉害恐怕每天带来的效益也只能可圈可点！但如果加上公司其它特别优秀的人一起工作的话就不一样了！当然了，你不能断章取义，我并没有否定马云的作用哈！因为确实作为一个公司优秀的leader来说，他做到了——足够的领导力团结大家一个更好地工作、足够的眼界去揽别人看不到的市场、足够的裁决力去修复团队、项目中不该存在的“BUG”，等等！说这些，并不是在这里简单的“吹牛逼”而已，而是我想告诉你：一个team并不是在乎你是否真的脑力过人，因为你并不是机器需要以后每时每刻都在高效工作，而是更在乎你是否能与团队协调一下步伐更好的完善工作，你是否拥有足够的学习耐力去尝试新鲜的东西从而时不时地为自己带来一些新鲜的“血液”，这颇有点‘木桶原理’的味道！最后其实我也很好奇，大家在编程过程中，有多少工作是靠大脑而不是靠时间久而沉淀的经验去“约定俗成”解决的呢？所以你不必特别在意的“大脑”，只要努力，定能“笨鸟先飞”。
2、能混到几个项目经验确实是不错的，特别是那种大一点、覆盖面广的项目，这确实对你以后工作经验影响较深、较大。但如果仅此而已，而不懂得扩展自己，或者总结一套较好的学习方法的话，其实你的经验局限性也是很大的。因为特别是编程这种工作，各种编程语言更新、迭代较快，所有公司都在寻求一种能够极大提高生产效率的工作模式，所以你以前的开发经验可能很短时间就会被替换，导致你不得不转换你自己的思维和工作模式！
3、能拥有第三点能力的，我觉得其实本身已经很不错的，可是无法蔑视的一个现实就是：你不爱好一个职业，而只是看好它的前景，从而不断苛刻的要求自己来提高工作能力，那么这样你将会坚持的很累，很大可能就是你某一天坚持不了而放弃！
那么，我认为的一个“合格”程序员应该具备那些特点呢？
在这之前，我想说一下为什么这些点我认为是成为“合格”程序员所需要的点，或者说让你更接近它。那么在这里先允许我“装逼”来解释下吧，确实这就是经验，因为对比之前的学习、工作模式和现在的区别，我体会到两种方式那个才能更好的帮助提升能力！所以有了下面这些观点：
- 1、你先上爱上这份工作
很多事情一样，如果你不是因为喜欢而是因为“冲动”而进入一份工作，那么恐怕你很难坚持下去。因为你不爱好一份工作，你的身体本能是拒绝它的，很难想象你在工作过程中会有一种想完善、臻美它的兴奋点，从而在这份工作长期发展。
- 2、要有专的能力
这里想说一下，这里的“专”不是“转”牛角尖的的“转”，而是想说的是一种专于找到问题本质的精神，其实有时候我们有些我们做的事情表面看上去很复杂，其实往往是简单的叠加，不是有一种说法是大繁至简吗？我们如果拥有了专一个问题本质的精神，你就能由内到外看到问题深处，从而你以后再遇到这种类似的问题就能驾轻就熟了。比如你写过一段代码之后不能把它放在哪里就不管了，而是尽量弄懂它，问问自己能否从另外一个角度实现它？那种方式更优？那种体验更好？如果你达到这一个层次，我想有很多问题你不光会解决它，你肯定也会喜欢上这个过程！
- 3、先理论基础，再实践
当接触到一个东西的时候，你得先看它的理论，因为有道是以理论为基础进行实践开发。在看理论第一遍的时候，可以不用看得那么深、那么追根问底！因为毕竟这东西不是你发明的，你要想看第一次就能万事皆全，那是不可能的，这样做无非是加大你对它的仇恨度。并且有些东西你要在实践使用中才能体会它的深妙！当然了，这里不是要你只看重理论哈，还是要结合实际操作哦！编程实践很重要，千万别走“理论主义”的路线！
- 4、找一个点持续关注它
比如一个大牛的博客、一个技术更新较勤的平台等，或者你认为大部分开发者都在逛的一个社区。你所要做的并不是要一一去学习那些技术，技术是学不完的，而是从这个点看到你当前的所用的编程语言的一个大环境，某些新技术、新框架的更新等。这样你才可以及时调整自己，从而不会跟不上新技术的节奏以被淘汰。打个比方，你以前一直在用jquery，用的很爽，可是现实呢？恐怕jquery已经“过时了”，你可能更多的是需要了解node、angular、vue及react等！当然了，我这里的建议就是你先专一个框架就好，另外的可先做了解，等用到时再深究，因为它们道理是大同小异的！
- 5、你必须有个业余爱好
这个爱好不限，可以是玩网游（比如我）、比如旅游、看书等等，只要是你喜欢的！但是不能是违法的哈，要不然出了事别怪我哈！为什么要这样做呢？因为我感觉当我们长期太过于专注一件事情的时候，我们的想法、思想等有时候会变得有些‘狭隘’，因为你没有了解过其它东西，所以总以一种你现在的思维去批判它。也许，适当的时间转换一下思维、放开也是挺好的！当然了这里并不是专指程序员这个行业，其实每个行业都是这样！
- 6、锻炼一种“写”的习惯
当然了，这个是我个人观点，并不强求，或许你有更好的方法用你的就是！因为之前学技术的时候，做过几次以为就会了，可是发现过了一段时间，竟然忘得一干二净，又重新去看文档！但是奇妙就发生在这里，看自己比看别人写的总是会更爽、更简单，并且有种满满的幸福感在里面！其一，是你已经做过，你看起来更容易理解；其二，看自己写的，更利于你回忆起当时你遇到的一些极端问题是怎么解决的。所以我这里说的是你得养成一种学习总结的习惯，并非要照我这样做，你有更好的方法，你应该遵从你的本心！
- 7、搜索引擎用google，看文档尽量看英文版
其实结合起来最终就是迫使你尽量看英文版的文档、逛英文社区！这样做是有很多好处的，且听我我慢慢道来：1、其一，能锻炼的英文学习能力，这也是一种能力，何乐而不为？2、看英文版更容易看到本质，更容易从原作者的角度理解作者的意愿，我们看别人的翻译之后文档时，经常会发现，因为两种语言之间翻译衔接的问题，导致表达的含义往往不是一样，被翻译者“断章取义”了。你不妨试一试，同样的内容，你看完之后，再对比一下两个版本那个对你来说更好理解其含义？3、其实我之前也是用百度搜索问题的，可是发现搜索出来的答案往往是现成的，从某种意义上来说，这回阻止了你的自我思考，从而不会让你看到更深的问题，也许，当时你可能真的把bug勉勉强强修复了，但是后期又会出现很多出人意料的问题，导致你摸不着头脑；4、因为编程语言、语法本身就是英文的，而于我看来，英文的逻辑性很强，要不然用它来描述程序语句了！不信？你仔细体会、研究一下！看下面两种语法：
//英文
var x = 10;
if(x>5){
//...
}else{
//...
};
//中文
/*
定义 x = 10;
如果x>5的话：
//执行xx操作
否则：
//执行xx操作
*/8、你要扩展自己
前面已经说过，技术学不完的，所以你应该在专注你的工作的同时，应该扩展自己的技术，这个扩展的技术可以是以你当前的工作为中心外延的技术，比如你是学前端的，那么你可以尝试一下学一下后台、产品、研究用户体验等；亦或你可以选择一个跟你现在所做的毫无关系的工作，如果可以的话！为什么要这样做呢？其一：可以扩展你的技术面，因为很难预料，你能把你现在的工作干到一辈子，毕竟世事难料；其二：可以让你从多方面、角度看待问题，解决起来相对容易些；其三：多学习总是好的。
9、善于以更好的方式替代原来不好的方式
这是我最近意识到的，因为什么呢？最近刚做了几个小的网页页面项目，这几个页面项目虽然描述的内容和营销目的不是一样的，但是大致逻辑是一样的，也就是我可以js部分我可以不改动或者改动很少的部分就能在每个项目复用！这样就能减少很大重复编写的代码量了。可是我并没有这么做，因为我总觉得我前面的代码写的有问题，写的太过臃肿，所以我就想修改前面的代码，或者以不同的、更好的方式来实现前面写过的逻辑！当我做了这个改动之后，其实我发现获得了新的东西：1、以不同的思维看待问题、理解问题，拓宽思维方式，更助于理解原理；2、将会使你的开发体验提升到一个非常好的体验，因为什么呢，如果你只是简单重复地把你前面的代码复制到当前的项目中，那么长此以往，你肯定会厌烦这种机械式重复的体验；使你拥有一种架构的思维来思考你要解决的问题，因为从多个维度实现同样的问题次数多了，你就知道那种方式更优，更利于大家方便开发。所以这一切都是有益无害的！
当然，我知道实现这一步最开始这是很难的，因为人总会有惰性思维，或者说很难愿意去接受、尝试新鲜的事物。这一点上，我也做的很差，就好像我一直不愿意尝试自己去装系统一样，总害怕把系统搞坏了，装不回来怎么办！以至于我现在总是小心翼翼的玩电脑，弄坏了，没人帮我重装系统。可是当你大胆尝试几次之后，你会发现重装系统也就那么回事！
那么，我们总结一下就是：如果你愿意尝试用好的（相对来说好的）方式替换旧的（相对来说不好的）方式，你就会获得：拓宽思维、提升开发体验、拥有大局观等！
- 10、如何在团队中做的更好
其实我最开始以为，只要自己技术足够牛，就能在一个团队中带来更多产出、效率，团队不允许有菜鸟（菜鸟在这里不是贬义，后面解释）！其实不是这样的，因为如果是这样的话，那么势必公司将永远不会要毕业生和实习生了，因为他们最开始都是最菜的，世间也不会存在新人和老人、徒弟和师傅一说了！最终所有的技术都会因为找不到传人而断传。其实我觉得一个良好的团队应该是一个能接受新人和老人、徒弟和师傅良好结合的共同体，其原因有：1、你能保证把10个顶级美女放在一起它们之间不会闹矛盾，或者以为她们各自对美丽的理解、定义不同而各执己见吗？如果团队是这样的话，那么很难保证我们的项目朝最终的目标走去；2、如果把10个高手或10新手放在一起，那么之间就会少了一种向别人学习的动力，因为都觉得自己已经达到最高境界了，长此以往，大家也会厌倦这种孤独的生活的！相反，如果把这两种人放在一起，新手就会为有了新的方向（高手）而努力奋斗，高手也会为了更好的带新手而持续学习补充自己。其实，按我的理解，团队里面只需要一个所谓的高手就行了；3、当然了新手便宜，这从公司的角度出发，是有这个需求的，从社会责任和技术传承的角度出发，公司也应该给一个新手工作的环境的！
说了这么多，我并不是在为“不思进取、不努力工作”的菜鸟开拓的，我这里说的菜鸟指的是一类真的想学习、踏实工作的人，只是当前欠缺工作经验而已。好吧，接着前面的说，你在团队中怎么做更好呢！我觉得应该这样（个人理解，愿意接受不同的观点）：1、如果你是新手，那么你就应该努力工作、首先完成工作，潜心练好基本功、扎实基础。找到自己的学习方式，实在不懂的时候可以和大家一起交流一下意见，但是切记，别一遇到问题就找别人，首先你应该确认以你现在的能力是不是真的在其它渠道找不到答案了，因为如此的话，别人也会烦你的；2、如果你是高手或者说技术管理者：你就应该构思好项目架构，然后分别交给不同部分的同事干，把流程搞清晰，必要的时候组织大家起来一起交流、学习下技术中出现的问题！当然了，管理者也应该通过不断的学习，来拓宽自己的思维，当然不必学的太过底层，因为毕竟可能你不需要做实际项目，这样做只是帮你更好地让你带领大家完成工作和减少同事彼此之间的对需求的理解误差！个人理解，切忌这样的技术管理者：只做需求提供者和需要验收者，也不考虑团队的技术栈和需求的合理性等，这样的管理者，只会让团队做更多的无用功而已！当然了，如果技术管理者是你的老板的话，那么你可以委婉适当地给他分析一下当前需求的理解，让大家达成一致。如果实在不行，那么就先做个样板出来吧，因为可能等你样板出来之后没套数据之前，可能老板的需求已经放松一些了，这时可以再试着分析一下需求！
- 11、写技术文档或开发用例文档
为什么单独把这个作为一个独立的话题来讨论呢？因为我是觉得文档这个东西在开发中是很重要的，但是又是被很多团队忽视的，都觉得在小团队中这个东西完全是影响开发效率，所以这个步骤能省就省了！那为什么重要呢？我来说下我的理解：1、文档这个东西首先可以帮你整理开发思路，记录你在开发中遇到的一些问题，然后你是怎么解决的，所以从某种意义上来说也是一种帮你总结问题的方法，你千万不要以为这会影响开发效率，因为这个东西做好了，你将来回滚版本或者修复bug的时候才能找到为什么这样改的相关依据，其实这样反而是提高你的开发效率的；2、更利于团队之间的沟通，因为你开发的东西可能会给你的领导等非技术人员查看，这个东西这个时候就能帮助大家增进对项目需求的理解；3、明确各个同事之间的职责，尤其在小公司或者小团队中，避免让无辜同事背锅。记得曾经在一个团队里，项目经理提一个需求或者改动一个需求的时候总是嘴上说需求，哪里该怎么改嘴上说一下就好了！从来都不记录问题的，最后搞得整个开发小组思路围着他转，影响开发体验不说，而且严重打击了大家的开发积极性。更为重要的，最终项目发布的时候，老板说内容显示完全没有主次、新意，不能够提升用户体验，最后老板就找到具体具体开发项目的同事，一顿痛斥，说了一些狠话，相反，老板找到项目经理劝说他辛苦一下再改下需求而已。这里我就奇怪了，这个责任只是跟具体开发项目的同事有关吗？难道项目经理就一点责任都没有了？这里我并不是在意孰是孰非的问题，而是想表达如果没有了开发文档，一些不明白开发流程的人是很难明确问题出现在哪里！从而造成病急乱投医的现象，伤害相关人员不说，更影响大家一起工作。
所以呀，开发文档这个东西还是很重要的！
结语
- 回想一下，自己目前所能想到的也就这些了，也许在大家的理解中，可能有更多、更好的学习、工作方式方法，欢迎issue上来，与大家一起分享！
