简短的代码(好的代码就像刚出浴的美人)

我是一名移动端程序员,目前已经工作六年多了。

六年的职场生涯,让我从一个职场小白,到现在从容面对各类工作挑战。

不禁感叹,时间真是过得飞快,我现在还清晰记得六年前我刚入职时的茫然无措。

最近在读《程序员的38堂成长课》,感触颇多,这本书分为五部分:

简短的代码(好的代码就像刚出浴的美人)(1)

这五部分每一部分单独拿出来自成一体,连在一起又相得益彰,覆盖了大部分程序员成长过程中遇到的问题。

的确,程序员的成长并不是一蹴而就的。它是一个循序渐进的过程,结合此书,我想和大家聊一聊我对于程序员成长的一些看法。

编程乃余事

编程是一名程序员的本职工作,同时也是最基础的工作。

但不同程序员对于代码有不同看法:

  • 初级程序员专注于功能实现,堆砌代码;
  • 高级程序员兼顾功能实现与代码的健壮性,以便后期维护和拓展;
  • 架构师则从全局出发,搭建项目架构,制定编码规则。

可以这么说,越往上走,你操心的事儿就越多,也更容易开始关注自己的发际线。不过从另一个角度看,如果一个发量不是很乐观的程序员去面试,很可能被面试官当做专家。

在编码的过程中,有几个值得我们注意的地方:编码规范、测试、bug追踪、架构演进。处理好这几方面,对于提升我们的技术工作很有帮助。

1、编码规范

每一门编程语言都有自己的编码规范,每个互联网公司内部也会有自己的编码规范。

当你入职新公司的时候,首先要做的,就是通过具体的文档或者项目中现有代码,来熟悉当前公司的编码规范,然后尽量与之靠拢并保持一致。

当然,如果你感觉自己的编码规范更加合理,也可以提出来,和同事讨论决定,最终使得编码规范一致。

简短的代码(好的代码就像刚出浴的美人)(2)

2、测试和bug追踪

艾兹格·迪杰斯特拉说过:“如果调试程序是移除bug的过程,那么编写程序就是把bug放进来的过程。”

这里的测试是指自测,而不是测试人员进行的测试。程序员如果没有自测,或者敷衍自测流程,那就代码价值就会越来越低。

保持良好状态可以防止破坏和犯罪,这就是典型的破窗效应。

《程序员的38堂成长课》给出了多种bug追踪方案,我觉得还是比较实用的,比如异常捕获(使用断言和日志)、二分法、软件考古(查询版本控制系统中提交的历史记录)、排除法、迂回策略(放空一下再回头看、说给别人听)等等。

简短的代码(好的代码就像刚出浴的美人)(3)

3、架构演进

架构不是一成不变的,或者说没有什么东西是一成不变的。

就像公司的组织架构一样,有的互联网公司半年或者一年就会进行一次调整,以便适应公司的发展策略。

项目架构同样如此,随着业务的骤增或者骤减,原先的架构支撑现有业务已经很吃力,这个时候不可避免就需要进行架构演进。

简短的代码(好的代码就像刚出浴的美人)(4)

刻意练习,成就卓越

作为一名程序员,日常工作中,我们或许需要注意这三个方面,以便让我们工作起来得心应手,事半功倍:

1、刻意练习

作家格拉德威尔在《异类》一书中提出了一万小时定律。“要成为某个领域的专家,需要10000小时(1.1415525年),按比例计算就是:如果每天工作八个小时,一周工作五天,那么成为一个领域的专家至少需要五年。这就是一万小时定律。”

刻意练习是指的是坚持做一件事情,比如每天坚持阅读优秀源码并进行总结,想想代码这样写有哪些好处,长此以往,当你再回首看你以前写的项目代码时,发现你现在可以仅用三分之一原先的代码即可完成功能开发,并且更高效,更简洁、更安全,这就是一个成长的过程,成就卓越的过程。

2、版本控制

版本控制是代码的时间机器,使得软件考古更加容易,同时提供了中央备份。它同时支持可逆性,如果发现项目历史中的任何更改是错误的,则可以通过撤销回滚它。

版本控制系统的演进:

简短的代码(好的代码就像刚出浴的美人)(5)

版本控制提交信息应当是清晰、简洁、明确,这样便于其他人以及自己以后查找回溯。

3、软件发布

软件开发流程就像是一个有机肥料的管道,但又不太正确,因为它不是一个线性过程 。

简短的代码(好的代码就像刚出浴的美人)(6)

但实际开发中,这样是不可取的,主要问题出在程序员开发过程和QA之间的协作,正确的做法应该是紧密结合,程序员开发出一个功能模块,QA就立马进行测试,及时反馈,这样开发人员可以尽早安排修复,以至于在最后期限前交付完美软件。

束身修行

更聪明而不是更努力的工作。

程序员最好做好如下几点,保障工作顺利进行下去:

1、自测

比如单元测试的开展,即使没有单元测试,也要有实际测试,避免一些眼高手低的问题

2、明确发布意图

不要直接把打包的内容发给测试人员,然后随便说一句“看看这个怎么样?”应该明确说明此次发布更新了哪些内容,或者修复了哪些bug。让测试人员可以更好的抓住测试重点,避免做无用功。

3、欲速则不达

不要急于构建发布版本,因为匆忙之下做的决定大部分是不完善的,要做到心中有数。

4、自动化

你可以通过创建一个脚本来自动签出代码、进行构建、运行所有单元测试、创建安装程序和部署到测试服务器,并将构建结果及其版本说明上传到服务器,这样就可以消除多个步骤中出现人为错误的可能性。

使用自动化来避免人为错误,有助于每次都能创建可以正确安装且不包含回归的版本,QA人员会因此而感激你。

5、尊重

不要直接将未经测试的软件交付给测试人员,以免出现尴尬局面。

6、正确看待故障报告

QA人员发布的故障报告,被领导不经意见看到了,这个时候开发人员心理难免会犯嘀咕,你这不是故意找我茬吗?改变这样的心态~

简短的代码(好的代码就像刚出浴的美人)(7)

计日成功

预防坏习惯比改掉坏习惯要容易得多。

拒绝成为荒岛式开发,没有哪个开发人员应该成为孤岛,这样做太过危险,也太过狭隘,过于拘泥于一个角度看问题,以至于看不到问题的全貌,更不用说去解决它了。

那么如何解决孤岛式开发呢?

  • 结对编程,定期与其它程序员进行回顾和代码评审,以求改进。
  • 适当放低个人姿态,勇于和别人交流,接受别人善意的援助。

有时候一个人很容易走进死胡同,这个时候一定要站起来休息一下,喝杯咖啡,然后找个人诉说一下你目前的想法,然后像过电影一样,这样子自己很容易就可以找到问题所在,如果实在找不到人,那么对着办公桌上面的玩具诉说也是可以的,这个还是它是你的倾诉对象。

多角度思考问题,有时候你想到的第一个方案往往不是最优的,可以发散一下思维,想多种解决方案,从中再选取最优解。

我们解决问题的态度应该是这样:最有效的解决问题,并且克服本能,不要一个人在那里低头蛮干,走入死胡同而不自知,这个只会距离解决问题越来越远,有时候要学会利用团队的力量。

寻找良师益友

我们是所处环境的产物,就像植物需要土壤和水分,需要一个良好的氛围健康成长,我们也一样。

优秀的程序员能够与同事愉快的合作共事,如果你想变得优秀,那一定要学会和别人通力合作,更要学会取长补短,从善如流。

近朱者赤近墨者黑,要刻意让自己融入到一群杰出的程序员当中,每天耳濡目染、简单而又影响深远,这使得每天都能在编程技巧和态度方面有所积累。

沟通也很重要,与机器沟通,让机器能够看懂你编写的代码,与评审你代码的人沟通,代码就是沟通的桥梁,不要让你的代码成为你个人的专属代码。

以上就是我读完这本书之后的一些感悟,共勉!


好书推荐


幽默诙谐,提炼方法和技巧

38个话题,提升你的代码感

简短的代码(好的代码就像刚出浴的美人)(8)

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页