乐趣区

关于程序员:程序员修炼之路你该知道的-7-个必经阶段

作者 | 杨长元
起源 | 阿里巴巴云原生公众号

导读:数据结构、算法、设计模式被认为是程序员必修的三大内功,你对设计模式有什么了解?你是什么时候意识到本人须要好好学习设计模式的?本文将分享作者多年编程路线上的一些思考和心得,以及对如何晋升设计能力的几点倡议。

当我做完设计相干的培训分享过后,有同学来问我:如何能力疾速晋升本人的设计能力?我感觉这个问题十分有代表性,代表了一大波程序猿在艰苦的修炼路上的心声。现将我对这个问题的思考、心得体会分享进去,供大家参考,也欢送提出不同的意见与认识,独特探讨。

编码历练

代码行教训是个十分重要的货色,当你还没有 1 万行代码教训的时候,你来问如何晋升设计能力的问题,我只能通知你不要太纠结,实践看看就好,老老实实写代码吧。

据说,一个程序员均匀每天码代码的速度是 200~300 行,你可能会说,我一天怎么也要写上 1000 行吧,别忘了,当你码完代码后,你还须要测试、调试、优化、BUG Fix,这些工夫你没法始终码代码的。

编码标准就不多说了,如果你的代码还是横七竖八的状态,就先别谈什么设计与架构了,我会感觉有点扯淡。

另外,作为代码洁癖患者,举荐大家不要把代码写完后,批量格式化解决,或者手工再去整顿代码,而是每敲一个字符下来,它都是符合规范的。习惯真的很重要,有时在招聘面试的时候,我真想增加一个环节,现场编写程序实现一个简略但容易出错的工作。

实践学习

简略说就是看书,看博客,你所能失去的资源,品质高的就行。例如:《重构 – 改善既有代码的设计》、《麻利软件开发:准则、模式与实际》、《UML 和模式利用》、” 面向对象设计准则 ”(五大准则)、《设计模式》等。

《设计模式》这本书是很古老的一本书了,只有短短 200 页,然而,这是最难看懂的一本书,一个月都可能看不完(看小说的话,200 页 3 个小时兴许就看完了吧),而且就算看完了,也不会全看懂,很可能看懂不超过 30%。看不懂没关系,看了就行,不必太纠结,这不能阐明什么问题。

另外,我想说一下,多线程技术是程序员必须把握的,而且须要了解透彻,当初的高级技术例如 GCD,会覆盖你对多线程了解有余的问题,因为应用切实太简略了。别说你没写过多线程仍然实现了简单的我的项目,更别说你顺手写出的多线程代码如同也没出什么问题啊,把你的代码给我,我写个 Demo 让它出错乃至解体,如果我做不到,祝贺你。

实际

当初,你曾经具备了肯定的编码教训,而且曾经学习了足够的理论知识,接下来就是真正练手的时候了。好好重复思考你学习的这些理论知识,要如何使用到我的项目中去,事必躬亲的去实际,肯定要把那些实践搞清楚,用于领导你的实际,收起从前的自信,首先否定本人以前的做法,保障每次做出的货色相比以前是有提高有改良的。

重温实践

你曾经能看到本人的提高了,发现比以前做的更好了,然而总感觉还不够,如同有瓶颈似的,祝贺你,我曾经能看到你将来的后劲了。

从新拿起书本,重温一遍之前看的似懂非懂的货色,你会发现之前没弄懂的货色,当初恍然大悟了,不再是那种难于了解的艰涩感了。就算是以前你感觉曾经弄懂的,也再看一遍,通常会有新的播种。

再实际

这个阶段,你曾经把握了较多的货色了,岂但实践经验丰盛,各种实践也能手到擒来了,然而你发现你的设计仍然不够业余。而且你回过头去看你以前写的代码,你会诧异:天啊,这是谁写的代码,怎么能这样干!而后。。。我就不多说了,你曾经进入了自省的阶段,把握了适宜本人的学习办法,再要学习什么新货色,都不再是个事。

总结

先别太得意(不信?那你去做一堂讲座看看),你须要总结了,总结本人的学习办法,总结我的项目教训,总结设计理论知识。

如果你能有本人独到的了解,而不是停留在只会应用成熟的设计模式什么的,能依据本人的经验教训总结一些设计准则进去,那天然是极好的。

分享

分享是最好的学习催化剂,当你要筹备一场培训分享的时候,你会发现你先前认为曾经了解的货色其实并没有真正了解透彻,因为你无奈把它讲清楚,实际上就是钻研不够,这时会迫使你去从新深刻学习,融汇贯通,而后你才敢走上讲台。否则当他人发问的时候,你基本答复不上来。

以上,便是我认为的程序员修炼路线的必经阶段。

而后,我再说说其余对晋升十分重要的几点:

1. 养成先设计,再编码的习惯

简直所有的程序员,一开始都不太违心写文档,也不太违心去精心设计,拿到需要总是忍不住那双躁动的手,总感觉敲在键盘上,一行一行的代码飙进去,才有成就感,才是正确的工作姿势。

没探讨分明不要编码,不然你肯定会返工。

2. 设计重于编码,接口重于实现

制订接口的过程,自身就是设计过程,接口肯定要反复推敲,尽量做减法而不是加法,在能满足需要的状况下越简略越好。

另外,不要一个人左思右想,先简略做一个雏形进去,而后拿去找应用方沟通,直到对方称心为止。
不要齐全依据应用需要去设计接口,参考 MVVM,ViewModel 就是依据 View 的须要而对 Model 进行的再封装,不能将这些接口间接设计到 Model 中。

3. 不盲从设计模式

设计模式只是一种解决问题的套路办法,你也能够有本人的办法,当然设计模式如果用好了,会让你的设计显得业余与优雅,毕竟前辈们的心血结晶。然而滥用的话,也会导致更重大的问题,甚至可能成为劫难。集体感觉面向对象设计准则更加重要,有些准则是必须恪守的(如单向依赖、SRP 等),而设计模式自身都是恪守这些准则的,有些模式就是为了遵循某准则而设计进去的。

形象不是万能的,在适当的中央应用,须要认真斟酌。当有更好的计划不必形象就能解决问题时,尽量避免形象,笔者见过太多的形象过分适度设计的案例了,减少了太多保护老本,还不如依照最天然的形式去写。

4. 空杯心态,向身边的同学学习,站在伟人的肩上,站在他人的肩上

有人提意见,先收下它(无论承受与否)。

很多程序猿,也都有一个故障,就是感觉本人技术牛的不行,不违心承受他人的意见,尤其是否定意见(文人相轻)。

而无论是实践的学习,还是编码实际,向身边的同学学习将是对本人影响最大的(三人行,必有我师),比刻意加入相干培训要有用的多。

我本人就常常在跟团队同学的探讨中获益,当百思不得解的时候,把问题抛出来讨论一下,通常都能失去一个最佳计划。

另外,跟团队其他人探讨还有一个益处,就是当你的设计有斗争,有些不业余的时候,他人看到代码也不会产生质疑,因为他参加了探讨的,你不必花那么多工夫去做解释。

设计期间就肯定要找别人探讨,我始终比拟拥护一个人把设计做完了,把文档写完了,而后才找大家开个评审会那种模式,尽管也有成果,然而成果真的达不到极致,大家没有参加到设计中来,通过一场会议的工夫了解不肯定有那么深,最要害的是,如果设计有些问题的时候,但也不是致命问题,难道还让打回从新设计么?

等后期探讨足够后,大家都晓得你的思路与计划,而且最初也有设计文档,当其他人来浏览你的代码的时候,基本无需你再指引,今后的工作交接都不是很须要了,何乐而不为呢?

最初,我想在此呐喊一下,当你去批改保护他人的代码时,最好找模块负责人做深刻的探讨沟通,让他明确你的需要以及你的计划,请他帮忙评估计划是否可行,是否会踩坑、埋坑等。这样咱们的我的项目才不会呈现坏滋味蔓延,而如果你恰好是某模块负责人,请行使你的势力,回绝有问题的不符合要求的代码提交入库。

大家共勉。

退出移动版