代码一把梭，兄弟来背锅。
大部分从事开发工作的技术人员，都有一颗把代码写好的初心。除了把编程当作一份工作，同时还具备了一定的工匠精神。但很多时候又很难把初心坚持下去，尤其面对接了烂手的项目、产品功能要得急迫、个人能力不足等问题时，这些原因导致开发的工程代码臃肿不堪，线上事故频出。
懂得高并发，可还写不好代码。
这就像家里装修完之后购买家具，花了几十万元买的实木沙发，怎么摆放也不好看！代码写得不好，不一定是基础经验不足，也不一定是产品需求要得急迫。很多时候是自己对编码经验掌握得不足，以及对架构的把控能力不到位。其实，大多数产品的第一个需求往往并不复杂，甚至可以说所见即所得般容易。但在接手开发时，如果不考虑后续是否需要扩展，将来会在哪些模块继续添加功能，这样的“病毒代码”就会随着种下的第一颗劣质种子开始蔓延。

只有标准的研发规范流程，才能写出更好的程序！
一个项目的上线往往要经历业务需求、产品设计、研发实现、测试验证、上线部署后最终对外开量。对研发人员来说，非常重要的一环是研发实现，又包括架构选型、功能设计、设计评审、代码实现、代码评审、单测覆盖率、编写文档及提交测试。所以，如果一个大项目由多人开发，研发人员之间一定要遵守研发规范并互相协作。
代码开发不是炫技，就像盖房子一样，如果不按照图纸修建，随意地造出一间厨房或卫生间是很荒唐的，但研发人员有时却总敲出这样不规范的代码。

程序员中有两类人：一类是喜欢编程的人；一类是仅把编程当作工作的人。喜欢编程的人会主动学习，不断丰富自己的知识，也非常喜欢对技术进行深度的探索，力求将所学的知识运用到工作中。
怎样成为喜欢编程的人？
其实无论做哪一行，凡是能达到喜欢这个行业的程度，往往是从这个行业里持续不断地积累并获取成就感开始的。对于编程开发而言，因为自己的一行代码能影响到千千万万的人，能使整个系统更加稳定，能让系统扛过大促、秒杀……这样一行行的代码都是日积月累学习的经验结晶。想源源不断地获得成就感，需要程序员持之以恒地探索知识、运用知识、验证知识，开发更多的核心业务系统。

方向不对，努力白费。
有些人平常也付出了很多时间学习，但没有取得多少效果。很多研发人员问我，该怎样学习一个之前没有接触过的技术？以我个人的经验，先不要学太多理论性的内容，而是要多尝试实践操作验证。这就像买了自行车，是先拆了看看运转原理是什么，还是先骑起来转几圈呢？
书不是看的，是用的。
关于新知识的学习方法，有很多初入研发编程行业的人员会有疑虑，就像明明看了、看的时候也懂了，但到实际使用的时候却用不上？其实这涉及对知识的理解程度，更重要的是动手实践能力。有的研发人员往往把看视频学习当作看电影，把看书学习当作看故事，在学习过程中没有经过深度思考，也没有实践操作，所以也就没有学会这些知识。只有把它用起来，逐字逐句地深挖，一点一滴地探求，把各项遇到的盲点全部扫清，才能真正掌握这些技能。

研发人员在编程开发时，除了编写正常流程，更多的时候会考虑异常流程。就像脑筋急转弯：树上有7只鸟，打死1只树上还剩下几只？我们可能会说，其他鸟飞走了，树上没有了。但在实际的编程开发中会考虑更多的情况，比如剩下6只鸟是真鸟还是假鸟、它们听力有没有障碍、有没有被绑在树上、枪声是否把其余6只震晕等。而这些奇怪的情况往往也是用户的行为体现到程序编码里的反映。
有些程序员在工作一段时间后都会想办法提升自己的技术栈能力，也是为了后续可以写出更好的程序。通常会尝试阅读一些源码，如 Spring、MyBaits、Dubbo 等。但在阅读时会发现，这件事并不那么容易。因为一个框架源码随着不断地迭代，会变得越来越复杂；同时，在框架代码中不仅用到很多的设计模式，甚至有时根本不是一个模式的单独使用，而是多种设计模式的综合运用。这与大部分研发人员平时开发的 CRUD 不一样，如果都是从上到下用if语句也就谈不上什么框架了。就像在Spring的源码中搜索关键字Adapter，就会出现很多实现类，例如UserCredentialsDataSourceAdapter。所以，阅读源码的学习复杂度就会增加。为了学会这些知识，需要研发人员不断地夯实基础，通过实践验证，把合适的技术运用到自己的业务代码中。

为什么你的代码里有那么多if…else？
同样的业务逻辑、同样的功能需求，为何会写出来那么多的if…else？很多时候，一些程序员在初次承接业务需求时，往往编码技术还不熟练，使用面向过程的方式编码。这种方式在项目初期确实能快速完成交付，但是后期在维护和扩展时将十分痛苦。因为一段代码的可读性越差，它的后期维护成本就越高。
合理地运用设计模式可以剔除大部分if…else代码。
如果在代码中出现篇幅较多的 if…else，大部分原因是研发人员没有考虑使用设计模式进行优化，就像同类服务的不同接口适配包装、同类物料不同组合的建造者、多种奖品组合的营销工厂等。设计模式可以让代码中原本使用if判断的地方，变成一组一组的业务逻辑类和面向对象的实现过程。
要想把工程开发好，就要多从实际场景思考，解决代码复杂逻辑中的痛点，使用最合适的设计模式优化。

前几年只要有人问该学哪种开发语言，或者哪种语言最好，肯定讨论得特别火热，有人支持PHP，有人建议用Java，也有人推荐C++和C＃。近几年，大家似乎并不会为此讨论得面红耳赤了，大多数时候只是开开玩笑。
在软件开发行业中，很多时候一些开发语言是共存的，依靠多种语言编写出的程序共同打造整个生态圈。研发人员选择的方式也更偏向于在不同领域选择适合的架构，搭配对应的编程语言，而不是一味地追求某种语言的好坏。这里可以给很多初学编程的读者一些提议，不要刻意地认为某种语言好，某种语言不好，应该在合适的场景下选择最需要的语言。选择主要学习哪种语言，可以参考招聘网站的需求量和薪资水平再综合做出决定。
编程开发不是炫技。
总会有人喜欢在项目开发中用一些新特性，试试自己新学的知识。这样并非不好，甚至可以说是热爱学习的人的创新和实践方式。但编程除了用新特性，还需要考虑整体的扩展性、可读性和可维护等方面。就像找了装修队，其中有一个工人喜欢炫技，在卫生间的淋浴花洒正下方安装了马桶。

很多人在编程时，除了可以把功能按照固定的流程编写出来，很难思考整个功能服务的扩展性和可维护性。尤其在一些大型的功能搭建方面，缺乏驾驭能力，从而导致最终的代码不能尽善尽美。

如果你感到容易，则一定有人为你承担了不容易。
这句话更像是描述生活场景的，面对许多的磕磕绊绊，总有人为你提供躲雨的屋檐和避风的港湾。其实，在编程开发的团队中也一样有人只负责 CRUD 中的简单调用，使用团队里的中、高级程序员开发出来的核心服务和接口。对于刚进入IT行业的新人来说，锻炼一下是可以接受的。随着工作得越来越久，如果一直做这种事情就很难成长，要努力做一些更有难度的项目，以此来提高个人的技术能力。
没有最好的编程语言，语言只是工具。
刀枪棍棒、斧钺钩叉，都是“语言”；五郎八卦棍、少林十二路谭腿、洪家铁线拳，都是“设计”。记得《叶问》里有一句台词。金山找：今天我北方拳术，输给你南方拳术了。叶问：你错了，不是南北拳的问题，是你的问题。所以，当编程开发时间久了，就不会特别在意用的是哪种语言，而是会为目标服务，用最好的设计能力提供完美的服务。这也是研发人员的价值所在！

程序员的上下文是什么？
很多时候有些研发人员只关注功能的实现，只要自己把负责的需求写完就可以了，像被动地交作业。出现这种问题一方面是由于研发人员没有深入思考自己的职业发展，另一方面是对于编程开发没有产生兴趣。就职业发展来看，如果不能很好地处理上文（产品）和下文（测试）的关系，就不能很好地了解业务发展和产品迭代，也不能编写出体系结构优秀的代码。日久天长，很难跨越一座座技术成长的分水岭。
拥有接受和学习新知识的能力。
是否有过这种感受：小时候虽然什么都不会，但接受知识的能力很强；随着长大成人，接受新鲜事物的能力却没有增长，不愿听取别人的意见，就像即使看到了一片森林，在视觉盲区的影响下，也会过滤掉80%的树木，因此导致能力不再有较快的提升。

在编程开发过程中如果遇到瓶颈期，往往是由于没有找到前进的方向。这时特别希望能有人告诉你，还欠缺什么或者应朝着哪个方向努力。而导致出现这一问题的主要原因是由于日常业务开发多是日复一日的重复工作。既没有经历过太多的挑战，也没有参与过较大体量的业务场景。除了缺少开发场景，还缺少组内的技术讨论氛围和技术分享活动，很少有人做传播者和布道者，自己也缺少学习各项技术的热情，最终导致一直徘徊，难以提升。
小公司和大公司，该选择哪个？
在不考虑薪资的情况下，会选择哪个？有人建议去小公司，因为可以接触到各种环境；也有人建议去大公司，因为大公司正规、体量大，可以学习更多的知识。有时技术成长缓慢也和自己的选择有关，虽然在小公司能接触各种环境，但如果公司的业务体量不高，那么用到的技术栈就会相对较少，研发人员对技术栈的研究深度也会较浅。在大公司里虽然不需要关心一个集群的部署和维护、一个中间件的开发过程、全套服务监控等事宜，但如果愿意了解这些技术，是可以在内部找到的，能够汲取更多的技术营养。

场地和场景的重要性。
射击需要在靶场练习，滑雪要在雪场体验，开车需要上路实践，而编程开发除了能完成产品的功能流程，还需要保证系统的可靠性。就像QPS、TPS、TP99、TP999、可用率和响应时长等系统监控指标，这些指标的总和评估决定着一个系统的健康度。如果没有听过这些技术名词，也没接触过类似的高并发场景，就会像虽然驾照考试科目一考了 100分，但也不能上路。如果没有经过在这种技术场景下的训练，不断地体会系统的“脾气秉性”，即便有再多的想法也是纸上谈兵。所以，如果想学习，一定要找到真实的场景。

没有设计图纸敢盖楼吗？
编程开发中最有价值的是什么？是设计，运用架构思维、经验心得和才华灵感，构建出最佳的系统。真正的研发人员会把自己写的代码当作品欣赏，在他们的眼里，这不仅是一份工作，更是一种工匠精神。就像自己会因为一个独特的设计而情不自禁，为能上线一个支撑每秒200万次访问量的系统而精神焕发。这种自豪感源于自己的日积月累，不断地把视野拓宽，既能看到上层设计，也能知晓根基建设；既可以把控全局，也可以治理细节。

持之以恒的重要性。
在初学编程的过程中，会遇到各种各样的问题，哪怕是别人正常运行的代码，照着写却会报错。时间和成长是相互关联的，在哪条路上坚持得越久，就越能发现这条路有多美。如果浪费了一次又一次努力的机会，那么同样也会错过很多机遇。坚持学习，努力成长，持之以恒地付出，一定会有所收获。
你愿意为一个知识盲区付出多长时间？
你心里会时而蹦出这种词吗：太难了我不会、找个人帮一下吧、放弃了……其实，谁都可能遇到难题，虽然可以去请教和咨询，但如果在此之前自己没有努力寻找答案，即使难题解决了，也没有融会贯通。日久天长，大脑中就会形成一棵凸点的知识树。缺少了自我学习的过程，也就缺少了查阅各种资料并深入理解的机会，哪怕得到了答案，最终也会忘记。

从对编程一无所知到能写出HelloWorld，并不会感觉有多难，也不会认为是无法做到的事。因为在这种学习过程中，有老师的指导，有书本的案例可以参考，有前人的经验可以借鉴。但随着工作的时间越来越长，需要解决更复杂的问题，面临更有挑战的技术难点，在网上搜索不到答案，这时是放弃，还是继续坚持不断地尝试解决问题？面对没有先例、需要自己解决的问题时，也许会被折磨到濒临崩溃，但只要执着地探索，就一定能攻克。哪怕没有解决问题，也可以在探索的路上取得其他的收获，为前进的道路打好基础。
拧螺钉？Ctrl+C、Ctrl+V？像贴膏药一样写代码？没有办法、没有时间，往往只是借口。因为没有实践过，很少参与过全场景的架构设计，所以才很难写出优良的代码。努力提高自身的编码修为，在各种场景中煅炼自己，才能更好地应对紧急情况。

同龄人的差距是从什么时候拉开的？
同样的学校、同样的课堂、同样的书本，有人学习好、有人学习差。不仅在求学阶段，人生几乎处处是赛道。当发令枪响起时，也就是人生的差距拉开之时。编程开发之路很长、很宽，有人跑得快，有人跑得慢。你是否想过，一点点的差距到遥不可及的距离，是从哪一天开始的？
日积月累的技术沉淀为的是厚积薄发。
粗略估算，如果从上大学开始每天写200行代码，一个月是6000行；如果一年写10个月，就是6万行，大三实习时就有接近20万行的代码量。如果你能做到这一点，找工作有何难？有时候很多事情就是积累而来的，没有捷径可走。自己的技术水平、业务能力，都是一点点积累而来的，不要浪费看似很短的时间，只要一年年地坚持下来，一定能提升自己的能力，给青春留下不平凡的足迹。

需求实现不了是研发人员的借口？
实现不了需求，有时是因为功能复杂度较高，有时是因为工期较短。因为编码的行为不好量化，同样一个功能每个人的实现方式不一样，遇到开发问题时的解决速度也不同。除此之外，无法很好地解释为什么需要这样长的工期，就像面对盖楼的图纸不好估算需要多少水泥一样。
研发人员应尽可能地通过一些经验，制订流程规范、设计、开发和评审等，确定一个可以完成的时间范围。当出现一些矛盾时，如果能压缩周期，要解释为什么之前需要的时间较长；如果不能压缩周期，也要给出合理的理由。
临阵的你好像一直很着急！
经常听到：老板明天就要了，你帮我弄弄吧；你给我写一下完事了，这次着急；现在不是没时间学吗？快给我看看。其实，类似的话还有很多，很纳闷这么着急是怎么导致的，老师怎么就那个时间要找你了，老板怎么就今天管你要了……是不是平时没有学习，临时抱佛脚乱着急！如果最后真的有人帮助了你，也不要放松，应该尽快学会，做到有备无患。

知道的越多，不知道的越多。
与编程开发相关的知识是无穷无尽的，就像最开始学习编程时敢说精通Java，随着学到的技术知识越来越多，会说了解Java，再过几年可能会说只懂一点点Java。当视野扩展后，会越来越发现自己的认识是多么浅显，就像站在地球上看宇宙一样。虽然不知道的越来越多，但也因此增加了学习更多技术的动力。
平衡好软件设计和实现成本的度。
有时一个软件的架构设计需要符合当前条件下的各项因素，不能因为心中想当然的有一个蓝图就开始执行。也许你的设计是非常优秀的，然而放在一定环境下可能很难满足业务的上线时间要求，当业务的基本诉求无法满足时，就很难拉动市场。没有产品的 DAU支撑，整个研发项目也会因此停滞。但研发人员又不能写一团乱麻似的代码，要找到一个适合的度，例如可以打好基础，做到在实现上可扩展，在具体的功能上先简化实现，再继续完善迭代。

写好代码的三个关键点。
如果把写代码想象成家里的软装，则会想到选择家具时要考虑和设计风格配套、大品牌、有质量保证、尺寸大小与房屋空间适合。把这一过程抽象成写代码，需要三个核心关键点：架构（房间的格局）、命名（品牌和质量）和注释（尺寸大小说明书），只有这三点都做好才能装修出一个赏心悦目的家。
技术传承的重要性。
也许是节奏太快，需求来得总是很急，恨不得当天就上线，导致团队的人都很慌、很急、很累，最终反复出现人员更替。在这个过程中，项目经过多次交接，存在文档不全、代码混乱的问题。对于这种项目，很难随着业务的发展而发展。

文无第一，武无第二。
同样努力的人，即使方向和水平不同，也都有自身的价值和优点。不要用自己手里的矛去攻击别人的盾，如果存在一时争辩，可能是自己承担的角色不同。互相学习、互相成长。就像上学期间大家会发现班里有一类学生似乎不怎么听课，但学习成绩很好。假如让他回家呆着，远离课堂，成绩还能好吗？类似的圈子还有图书馆、车友群和技术交流群等，大家一起营造学习氛围，找到分享技能的同类爱好者，共同进步。
能把复杂的知识讲得简单很重要。
在学习的过程中，我们看过很多音频、视频和文档等，往往一个知识点会有多种多样的讲解形式。有很多人的讲解非常优秀，例如李永乐老师的短视频课，可以在黑板上把复杂的知识讲解得通俗易懂。学习编程的人要学会把知识点讲明白，更要写明白。

黎明前的黑暗，坚持得住吗？
有人举过这样一个例子，先给你一张北京大学的录取通知书，但要求每天 5 点起床，12 点睡觉，刻苦学习，勤奋上进。只要坚持三年，这张通知书就有效。如果是你，你能坚持吗？其实这个假设很难在人生中出现，因为它目标明确，有准确的行军路线。就像如果生在富豪家庭，自己的一切被家里安排得明明白白，只要按部就班地生活就不会有问题。可大多数普通人并不具备这种条件，甚至不知道多久才能迎来自己的黎明。但是，谁又不渴望见到黎明呢？所以请坚持吧！
有时还好坚持了！
当为自己的一个决定而感到万分开心时，是不是也非常庆幸自己坚持住了？坚持、努力、终身学习，似乎与IT行业是分不开的。当意愿把编程当成可以努力提高的爱好时，就会愿意为此而努力。

能力，是你前行的最大保障！
年龄会不断地增长，什么才能让自己不慌张？一定是能力，即使是在一个看似很安稳的工作环境中也是一样，只有拥有能留下的本事和跳出去的能力，才会是安稳的。而能力的提升是不断突破自己的认知，也就是拓展宽度；并在专业领域建设个人影响力，也就是深度。如果日复一日，只是简单地重复，只能让手上增长老茧，又叹人生苦短。
站得高一定能看得远吗？
站得高确实能看得远，也能让自己有更高的追求。但是站得高了，原本看清的东西就变得看不清了。视角和关注重点不同，会让我们有很多不同的选择。脚踏实地地奠定能攀升起来的基石，从容地走向山顶，那时才是看得更远的时候。