本文主要是介绍干货预警,程序员修炼之路:你该知道的 7 个必经阶段,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
编码历练
代码行经验是个非常重要的东西,当你还没有 1 万行代码经验的时候,你来问如何提升设计能力的问题,我只能告诉你不要太纠结,理论看看就好,老老实实写代码吧。
据说,一个程序员平均每天码代码的速度是 200~300 行,你可能会说,我一天怎么也要写上 1000 行吧,别忘了,当你码完代码后,你还需要测试、调试、优化、BUG Fix,这些时间你没法一直码代码的。
编码规范就不多说了,如果你的代码还是杂乱无章的状态,就先别谈什么设计与架构了,我会觉得有点扯淡。
另外,作为代码洁癖患者,推荐大家不要把代码写完后,批量格式化处理,或者手工再去整理代码,而是每敲一个字符上去,它都是符合规范的。习惯真的很重要,有时在招聘面试的时候,我真想添加一个环节,现场编写程序完成一个简单但容易出错的任务。
理论学习
简单说就是看书,看博客,你所能得到的资源,质量高的就行。例如:《重构 – 改善既有代码的设计》、《敏捷软件开发:原则、模式与实践》、《UML 和模式应用》、” 面向对象设计原则”(五大原则)、《设计模式》等。
《设计模式》这本书是很古老的一本书了,只有短短 200 页,但是,这是最难看懂的一本书,一个月都可能看不完(看小说的话,200 页 3 个小时也许就看完了吧),而且就算看完了,也不会全看懂,很可能看懂不超过 30%。看不懂没关系,看了就行,不用太纠结,这不能说明什么问题。
另外,我想说一下,多线程技术是程序员必须掌握的,而且需要理解透彻,现在的高级技术例如 GCD,会掩盖你对多线程理解不足的问题,因为使用实在太简单了。别说你没写过多线程依然完成了复杂的项目,更别说你随手写出的多线程代码好像也没出什么问题啊,把你的代码给我,我写个 Demo 让它出错乃至崩溃,如果我做不到,恭喜你。
实践
现在,你已经具备了一定的编码经验,而且已经学习了足够的理论知识,接下来就是真正练手的时候了。好好反复思考你学习的这些理论知识,要如何运用到项目中去,身体力行的去实践,一定要把那些理论搞清楚,用于指导你的实践,收起从前的自信,首先否定自己以前的做法,保证每次做出的东西相比以前是有进步有改进的。
重温理论
你已经能看到自己的进步了,发现比以前做的更好了,但是总感觉还不够,好像有瓶颈似的,恭喜你,我已经能看到你未来的潜力了。
重新拿起书本,重温一遍之前看的似懂非懂的东西,你会发现之前没弄懂的东西,现在豁然开朗了,不再是那种难于理解的晦涩感了。就算是以前你觉得已经弄懂的,也再看一遍,通常会有新的收获。
再实践
这个阶段,你已经掌握了较多的东西了,不但实践经验丰富,各种理论也能手到擒来了,但是你发现你的设计依然不够专业。而且你回过头去看你以前写的代码,你会惊讶:天啊,这是谁写的代码,怎么能这样干!然后。。。我就不多说了,你已经进入了自省的阶段,掌握了适合自己的学习方法,再要学习什么新东西,都不再是个事。
总结
先别太得意(不信?那你去做一堂讲座看看),你需要总结了,总结自己的学习方法,总结项目经验,总结设计理论知识。
如果你能有自己独到的理解,而不是停留在只会使用成熟的设计模式什么的,能根据自己的经验教训总结一些设计原则出来,那自然是极好的。
分享
分享是最好的学习催化剂,当你要准备一场培训分享的时候,你会发现你先前以为已经理解的东西其实并没有真正理解透彻,因为你无法把它讲清楚,实际上就是研究不够,这时会迫使你去重新深入学习,融汇贯通,然后你才敢走上讲台。否则当别人提问的时候,你根本回答不上来。
以上,便是我认为的程序员修炼道路的必经阶段。
然后,我再说说其他对提升非常重要的几点:
1. 养成先设计,再编码的习惯
几乎所有的程序员,一开始都不太愿意写文档,也不太愿意去精心设计,拿到需求总是忍不住那双躁动的手,总觉得敲在键盘上,一行一行的代码飙出来,才有成就感,才是正确的工作姿势。
没讨论清楚不要编码,不然你一定会返工。
2. 设计重于编码,接口重于实现
制定接口的过程,本身就是设计过程,接口一定要反复推敲,尽量做减法而不是加法,在能满足需求的情况下越简单越好。
另外,不要一个人冥思苦想,先简单做一个雏形出来,然后拿去找使用方沟通,直到对方满意为止。 不要完全根据使用需求去设计接口,参考 MVVM,ViewModel 就是根据 View 的需要而对 Model 进行的再封装,不能将这些接口直接设计到 Model 中。
3. 不盲从设计模式
设计模式只是一种解决问题的套路方法,你也可以有自己的方法,当然设计模式如果用好了,会让你的设计显得专业与优雅,毕竟前辈们的心血结晶。但是滥用的话,也会导致更严重的问题,甚至可能成为灾难。个人觉得面向对象设计原则更加重要,有些原则是必须遵守的(如单向依赖、SRP 等),而设计模式本身都是遵守这些原则的,有些模式就是为了遵循某原则而设计出来的。
抽象不是万能的,在适当的地方使用,需要仔细推敲。当有更好的方案不用抽象就能解决问题时,尽量避免抽象,笔者见过太多的抽象过火过度设计的案例了,增加了太多维护成本,还不如按照最自然的方式去写。
4. 空杯心态,向身边的同学学习,站在巨人的肩上,站在别人的肩上
有人提意见,先收下它(无论接受与否)。
很多程序猿,也都有一个毛病,就是觉得自己技术牛的不行,不愿意接受别人的意见,尤其是否定意见(文人相轻)。
而无论是理论的学习,还是编码实践,向身边的同学学习将是对自己影响最大的(三人行,必有我师),比刻意参加相关培训要有用的多。
我自己就经常在跟团队同学的讨论中获益,当百思不得解的时候,把问题抛出来讨论一下,通常都能得到一个最佳方案。
另外,跟团队其他人讨论还有一个好处,就是当你的设计有妥协,有些不专业的时候,别人看到代码也不会产生质疑,因为他参与了讨论的,你不用花那么多时间去做解释。
设计期间就一定要找他人讨论,我一直比较反对一个人把设计做完了,把文档写完了,然后才找大家开个评审会那种模式,虽然也有效果,但是效果真的达不到极致,大家没有参与到设计中来,通过一场会议的时间理解不一定有那么深,最关键的是,如果设计有些问题的时候,但也不是致命问题,难道还让打回重新设计么?
等前期讨论足够后,大家都知道你的思路与方案,而且最后也有设计文档,当其他人来阅读你的代码的时候,根本无需你再指引,今后的工作交接都不是很需要了,何乐而不为呢?
最后,我想在此呼吁一下,当你去修改维护别人的代码时,最好找模块负责人做深入的讨论沟通,让他明白你的需求以及你的方案,请他帮忙评估方案是否可行,是否会踩坑、埋坑等。这样我们的项目才不会出现坏味道蔓延,而如果你恰好是某模块负责人,请行使你的权力,拒绝有问题的不符合要求的代码提交入库。
这篇关于干货预警,程序员修炼之路:你该知道的 7 个必经阶段的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!