好看的代码千篇⼀律，恶⼼的程序升职加薪。
该说不说⼏乎是程序员就都知道或者了解设计模式，但⼤部分⼩伙伴写代码总是习惯于⼀把梭。⽆论多少业务逻辑就⼀个类⼏千⾏，这样的开发也可以归纳为三步；定义属性、创建⽅法、调⽤展示，Done！只不过开发⼀时爽，᯿构⽕葬场。
代码⼀把梭，兄弟来背锅。
⼤部分做开发的⼩伙伴初⼼都希望把代码写好，除了把编程当作⼯作以外他们还是具备⼯匠精神的从业者。但很多时候⼜很难让你把初⼼坚持下去，就像；接了个烂⼿的项⽬、产品功能要的急、个⼈能⼒不⾜，等等原因导致⼯程代码臃肿不堪，线上频出事故，最终离职⾛⼈。
乱码七糟 [luàn qī bā zāo]，我时常怀疑这个成语是来形容程序猿的！
⽆论承接什么样的需求，是不是身边总有那么⼏个⼈代码写的烂，但是却时常有测试⼩姐姐过来聊天(求 改bug)、有产品⼩伙伴送吃的(求写需求)、有业务⼩妹妹陪着改代码(求上线)，直⾄领导都认为他的⼯作很重要，⽽在旁边的你只能蹭点吃的。
那你说，CRUD的代码还想让我怎么样？
这样的⼩伙伴，可能把代码写的很直接， ifelse 多⽤⼀点，满⾜于先临时⽀持⼀下，想着这也没什么的。⽽且这样的业务需求要的急⼜都是增删改查的内容，实在不想做设计。⽽如果有⼈提到说好好设计下，可能也会被反对不要过渡设计。
贴膏药似的修修补补，⼀次⽐⼀次恐怖！
第⼀次完成产品需求实在是很快，但互联⽹的代码不⽐传统企业。在传统⾏业可能⼀套代码能⽤⼗年，但在互联⽹⾼速的迭代下你的⼯程，⼀年就要变动⼏⼗次。如果从⼀开始就想着只要完成功能就可以，那么随之⽽来的是后续的需求难以承接，每次看着成⽚成⽚的代码，实在不知如何下⼿。
在研发流程规范下执⾏，才能写出好程序！
⼀个项⽬的上线往往要经历 业务需求 、 产品设计 、 研发实现 、 测试验证 、 上线部署 到 正式开量 ，⽽这其中对研发⾮常᯿要的⼀换就是研发实现的过程，⼜可以包括为； 架构选型 、 功能设计 、 设计评审 、代码实现 、 代码评审 、 单测覆盖率检查 、 编写⽂档 、 提交测试 。所以在⼀些流程规范下，其实很难让你随意开发代码。开发代码的过程不是炫技 ，就像盖房⼦如果不按照图纸来修建，回⾸就在⼭墙上搭⼀个厨房卫浴！可能在现实场景中这很荒唐，但在功能开发中却总有这样的代码。所以我们也需要⼀些设计模式的标准思想，去建设代码结构，提升全局把控能⼒。
讲道理没有ifelse解决不了的逻辑，不⾏就在加⼀⾏！
⽼板你加钱我的代码能⻜
程序员这份⼯作⾥有两种⼈；⼀类是热爱喜欢的、⼀类是仅当成⼯作的。⽽喜欢代码编程的这部分⼈会极其主动学习去丰富⾃⼰的⽻翼，也⾮常喜欢对技术探索⼒求将学到的知识赋能到平时的业务需求开发中。对于这部分⼩伙伴来说上班写代码还能赚钱真的是幸福！
怎么成为喜欢编码都那部分⼈
⽆论做哪⾏那业你都喜欢，往往来⾃从中持续不断都获取成就感。就开发编程⽽⾔因为你的⼀⾏代码影响到了千千万万的⼈、因为你的⼀⾏代码整个系统更加稳定、因为你的⼀⾏代码扛过了所有秒杀等等，这样⼀⾏⾏的代码都是你⽇积⽉累学习到的经验。那如果你也想成为这样有成就感的程序员就需要不断的学习，不断的⽤更多的技能知识把⾃⼰编写的代码运⽤到更核⼼的系统。
擦屁屁纸80%的⾯积都是保护⼿的！
⼯作到3年左右很⼤⼀部分程序员都想提升⾃⼰的技术栈，开始尝试去阅读⼀些源码，例如Spring 、 Mybaits 、 Dubbo 等，但读着读着发现越来越难懂，⼀会从这过来⼀会跑到那去。甚⾄怀疑⾃⼰技术太差，慢慢也就不愿意再触碰这部分知识。⽽这主要的原因是⼀个框架随着时间的发展，它的复杂程度是越来越⾼的，从最开始只有⼀个⾮常核⼼的点到最后开枝散叶。这就像你⾃⼰开发的业务代码或者某个组件⼀样，最开始的那部分核⼼代码也许只能占到20%，⽽其他⼤部分代码都是为了保证核⼼流程能正常运⾏的。所以这也是你读源码费劲的⼀部分原因。
框架中⽤到了设计模式吗？
框架中不仅⽤到设计模式还⽤了很多，⽽且有些时候根本不是⼀个模式的单独使⽤，⽽是多种设计模式的综合运⽤。与⼤部分⼩伙伴平时开发的CRUD可就不⼀样了，如果都是if语句从上到下，也就算得不上什么框架了。
对于代码你有编程感觉吗
很多⼈写代码往往是没有编程感觉的，也就是除了可以把功能按照固定的流程编写出流⽔式的代码外，很难去思考整套功能服务的扩展性和可维护性。尤其是在⼀些较⼤型的功能搭建上，⽐较缺失⼀些驾驭能⼒，从⽽导致最终的代码相对来说不能做到尽善尽美。江洋⼤盗与江洋⼤偷两个本想描述⼀样的意思的词，只因⼀字只差就让⼈觉得⼀个是好⽜，⼀个好搞笑。往往我们去开发编程写代码时也经常将⼀些不恰当的⽤法⽤于业务需求实现中，但却不能意识到。⼀⽅⾯是由于编码不多缺少较⼤型项⽬的实践，另⼀⽅⾯是不思进取的总在以完成需求为⽬标缺少精益求精的⼯匠精神。
书从来不是看的⽽是⽤的在这个学习资料⼏乎爆炸的时代，甚⾄你可以轻易就获取⼏个T的视频，⼩⼿轻轻⼀点就收藏⼀堆⽂
章，但却很少去看。学习的过程从不只是简单的看⼀遍就可以，对于⼀些实操性的技术书籍，如果真的希望学习到知识，那么⼀定是把这本书⽤起来⽽绝对不是看起来。
程序员的上下⽂是什么？ !
很多时候⼀⼤部分编程开发的⼈员都只是关注于功能的实现，只要⾃⼰把这部分需求写完就可以了，有点像被动的交作业。这样的问题⼀⽅⾯是由于很多新⼈还不了解程序员的职业发展，还有⼀部分是对于编程开发只是⼯作并⾮兴趣。但在程序员的发展来看，如果不能很好的处理上⽂( 产品 )，下⽂( 测试 )，在这样不能很好的了解业务和产品发展，也不能编写出很有体系结构的代码，⽇久天⻓，1到3年、3到5年，就很难跨越⼀个个技术成⻓的分⽔岭。
拥有接受和学习新知识的能⼒你是否有感受过⼩时候在什么都还不会的时候接受知识的能⼒很强，但随着我们开始⻓⼤后，慢慢学习能⼒、处事⽅式、性格品⾏，往往会固定。⼀⽅⾯是形成了各⾃的性格特征，⼀⽅⾯是圈⼦已经固定。但也正因为这样的故步，⽽很少愿意听取别⼈的意⻅，就像即使看到了⼀整⽚内容，在视觉盲区下也会过掉到80%，就在眼前也看不⻅，也因此导致了能⼒不再有较⼤的提升。
编程能⼒怎样会成⻓的最快
⼯作内容往往有些像在⼯⼚ 拧螺丝，⼤部分内容是᯿复的，也可以想象过去的⼀年你有过多少创新和 学习了新的技能。那么这时候⼀般为了多学些内容会买⼀些技术书籍，但！技术类书籍和其他书籍不同，只要不去⽤看了也就只是轻描淡写，很难接纳和理解。就像设计模式，虽然可能看了⼏遍，但是在实际编码中仍然很少会⽤，⼤部分原因还是没有认认真真的跟着实操。事必躬亲才是学习编程的最好是⽅式。
难以跨越的瓶颈期，把你拿捏滴死死的！
编程开发学习过程中遇到的瓶颈期，往往是由于看不到前进的⽅向。这个时候你特别希望能有⼈告诉你，你还⽋缺些什么朝着哪个⽅向努⼒。⽽导致这⼀问题的主要原因是由于⽇常的业务开发太过于复制过去，⽇复⼀⽇的重复。没有太多的挑战，也没参与过较⼤体量的业务场景，除了这些开发场景因素外，还有缺少组内的技术氛围和技术分享，没有⼈做传播和布道者，也缺少⾃⼰对各项技术学习的热情，从⽽导致⼀直游荡在瓶颈之下，难以提升。
⼩公司与⼤公司，选择哪个？
刨除掉薪资以外你会选择什么，是不有⼈建议⼩公司，因为可以接触到各个环境，也有⼈建议⼤公司，因为正规体量⼤可以学习到更多。有些时候你的技术成⻓缓慢也是因为你的不同选择⽽导致的，⼩公司确实要接触各个环境，但往往如果你所做的业务体量不⾼，那么你会⽤到的技术栈就会相对较少，同时也会技术栈研究的深度也会较浅。⼤公司中确实有时候你不需要去关⼼⼀个集群的部署和维护、⼀个中间件的开发、全套服务监控等等，但如果你愿意了解这些技术在内部都是公开的，你会拥有⽆限的技术营养可以补充。
除了业务中的CRUD开发，有些技术你真的很难接触到！
可能很多⼩伙伴认为技术开发就是承接下产品需求，写写CRUD，不会的百度⼀下，就完事了，总觉得别⼈问的东⻄像再造⽕箭⼀样。但在⾼体量、⾼并发的业务场景下，每⼀次的压测优化，性能提升，都像在研究⼀道数学题⼀样，反复的锤炼，压榨性能。不断的深究，找到最合适的设计。除了这些优化提升外，还有那么⼴阔的技术体系栈，都可能因为你只是注᯿CRUD⽽被忽略；字节码编程、领域驱动设计架构、代理模式中间件开发、JVM虚拟机实现原理等等。
网友评论