有哪些老鸟程序员知道而新手不知道的小技巧?自我感受

最近在朋友圈看到别人分享的一篇知乎回答:https://www.zhihu.com/question/36426051/answer/76031743

我觉得写得挺有道理的,作为一个写了10多年C#代码的老程序员来说,很多地方我能感同身受,所以也谈谈我的自我感受。


1.重构是程序员的主力技能。

是的,我之前经常也提到一点,就是好多设计模式不是提前就设计出来的,而是重构出来的。很多情况是我们在做设计的时候考虑不到的,是写代码时也考虑不到的,只有在项目上线后,客户使用过程中才会反应出来,这个时候就需要对项目进行扩展,版本升级,这时就体现老程序员实力的时候了,就是根据已有的情形,结合新的客户需求,使用合适的设计模式,使得代码能够优雅的扩展。
2.工作日志能提升脑容量。

这个我没有什么体会,我平时也写工作日志,但是那是项目工作的需要,不是我本人的主观意愿。不过我个人觉得技术博客能够提升脑容量才是真的。很多项目中遇到的问题,解决了,也许以后还会再次遇到,也许别人也会遇到,那么就写成博客,自我总结,方便以后自己或者其他程序员遇到同样的问题。
3.先用profiler调查,才有脸谈优化。

是的,我之前也专门做过SQL Server的性能优化,很有体会,Profiler是第一步。如果做.net代码的优化,也有对应的Profiler工具,这个可以帮我们快速的定位瓶颈在哪里。找到了瓶颈才有接下来的优化工作。
4.注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释,实际就是背景噪音。

我不是很同意这个说法,还有更极端的观点是不需要注释,命名就是注释,好的命名就能注释一切。我觉得好的命名那是必须的,但是在复杂的逻辑中,我们有必要在代码中注释我们的思路,为什么会用这样一种写法。
5.普通程序员+google=超级程序员。

确实,很多不懂的,解决不了的就Google吧,一般Google会告诉你,Stackoverflow知道答案。
6.单元测试总是合算的。

这个观点我赞同,也许对于很多程序员来说,单元测试就是浪费时间,但是当项目复杂了以后,真的很需要单元测试,尤其是在不断的hotfix和版本升级的过程中。
7.不要先写框架再写实现。最好反过来,从原型中提炼框架。

这个就是我前面第一点提到的一样,很多框架设计好了,但是不一定适应当前这个项目,那就是画蛇添足。
8.代码结构清晰,其它问题都不算事儿。

这个就是编码规范的问题,代码写的漂亮,让Debug没那么痛苦,让别人Review你的代码也没那么痛苦。
9.好的项目作风硬派,一键测试,一键发布,一键部署; 烂的项目生性猥琐,口口相传,不立文字,神神秘秘。

这个也是我最近在研究的CI(持续集成),适应TeamCity可以把测试,发布,部署都自动化搞定。
10.编码不要畏惧变化,要拥抱变化。

基于接口的编程,我们只关注接口,实现嘛,随时可以变。
11.常充电。程序员只有一种死法:土死的。

好吧,程序员的命就是这样,技术变化太快了。
12. 编程之事,隔离是方向,起名是关键,测试是主角,调试是补充,版本控制是后悔药。

面向接口,控制反转与依赖注入,都是编写复杂的软件的必备良药。测试,调试,没啥可说的,必备。版本控制,那是必须的!即使是只有一个开发人员的项目,也需要版本控制。
13. 一行代码一个兵。形成等建制才能有效指挥。单位规模不宜过大。千人班,万人排,容易变成万人坑。

这里说的一个关于函数的规范问题,有一种说法是一个函数的内容不应该超过7行,如果超过7行,那么肯定是把多个Function合并到一个函数中的,应该拆分成多个函数。这个要求可能有点高,很难做到。不过上百行,上千行的函数那是不应该的,必须拆分!
14. 重构/优化/修复Bug,同时只能作一件。

这个我还是有点体会的,把多个目标合并到一次修改中,那是多么困难的事情,真的不好做。最好是分开,先重构,保证重构后的功能和原来的功能一致,然后再Fix Bug。
15. 简单模块注意封装,复杂模块注意分层。

面向对象编程基本要点,封装,企业应用架构的基础就是分层。最经典的三层架构做企业应用的应该都知道。
16. 人脑性能有限,整洁胜于杂乱。读不懂的代码,尝试整理下格式; 不好用的接口,尝试重新封装下。

还是说到编码规范的问题,简洁易懂,接口要清晰。
17. 迭代速度决定工作强度。想多快好省,简化开发流程,加快迭代速度。

软件工程中的快速迭代,敏捷开发,涉及到前面提到的持续集成。
18. 忘掉优化写代码,忘掉代码作优化。因为过早优化,往往事倍功半; 不通过全局性能度量,优化也难有建树。

不是很认同,有经验的程序员,在写代码时采用的就是最优的算法,最好的查询方式。没有什么忘掉优化写代码的事情,在写代码时,想到的就是最优的算法,因为在他看来就这种算法才是对的。
19. 最好的工具是纸笔;其次好的是markdown。

纸和笔只适用于在Face 2 Face的交流过程中,交流后顶多拍照留存,根本无法建立有效的知识库,以后想到之前的讨论,怎么检索?怎么修改?。写Wiki才是王道,Markdown只是一种写Wiki的方式罢了。
20. leader问你任务时间,你答不上来。很可能是任务拆分不够细。细分到没有疑问吧。

应该是的,如果不知道任务时间,那么说明要么你根本不懂这个任务怎么做,完全不会,要么就是任务太大了,不好估计时间。
21. 宁可多算一周,不可少估一天。别总因为你的“乐观”而boss受惊吓。

是啊。程序员在估计工时的时候总是太乐观。随便开口就是一个小时就能搞定,半天就能做完。完全没有想到该修改对其他模块的影响。一个修改后的单元测试,可接受测试,UAT环境测试,再到上线,很多地方都得花时间的。一旦某个测试不通过,然后又得调试,修改,再进行单元测试,可接受测试~~~~,好吧,谁能保证每次修改都是一次通过呢。
22. 最有用的语言是English。其次的可能是Python。

好吧,我英语不好,Python更不懂。我不评论。
23. 百闻不如一见。画出结果,调试耗时将急剧缩短。

没懂这里在说什么。
24. 资源、代码应一道受版本管理。资源匹配错误远比代码匹配错误更难排查。

这个应该是这样。在项目文件夹中,有很多个子文件夹,其中一个文件夹叫src,那里存放的才是代码,那么其他的文件夹呢?就可能存放相关的设计啊、测试啊、工具之类的。
25. 不要基于想象开发, 要基于原型开发。原型的价值是快速验证想法,帮大家节省时间。

恩,是啊,最好是先画出原型。有了原型才方便讨论,明确需求。
26. 序列化首选明文文本 。诸如二进制、混淆、加密、压缩等等有需要时再加。

应该是吧,比如Json是比较好的序列化选项。
27. 编译器永远比你懂微观优化。只能向它不擅长的方向努力。

有了好的设计和算法,谁关系编译器内部怎么做的。
28. 不要定过大、过远、过细的计划。即使定了也没有用。

过大过远的目标还是可以定吧,规划一下下一个版本的Roadmap,也许还没有开始做,但是愿景可以建立。只是经常会有计划赶不上变化的情况,所以远期的计划不需要太详细,反正也会不断变。
29. 至少半数时间将花在集成上。

这得看做什么项目了吧,很多项目就是一个完全独立的孤岛,没啥好集成的。最近的基础可能就是单点登录的集成,太简单花不了多少时间。另外常见的是HR系统的员工数据的集成还有财务系统的财务数据集成,确实很花时间。
30. 与主流意见/方法/风格/习惯相悖时,先检讨自己最可靠。

没啥说的。
31. 出现bug主动查,不管是不是你的。这能让你业务能力猛涨、个人形象飙升; 如果你的bug被别人就出来,那你会很被动~≧﹏≦

查Bug是也很难的事情,自己做的项目,自己再支持运维一段时间,看看自己的代码写的有多烂,有多难修改,多难调试。真的可以让自己能力提升很多。
32. 不知怎么选技术书时就挑薄的。起码不会太贵,且你能看完。

我很懒,很多书都看了一半就看不下去了。
33. git是最棒的。简单,可靠,免费。

源代码管理,必选Git,自己可以架设Git Server,也可以用GitHub。
34. 仅对“可预测的非理性”抛断言。

恩。是啊,尤其用户输入的时候。
35. Log要写时间与分类。并且要能重定向输出。

这个用现成的Log组件即可。有Log4J,Log4Net,真的很好用。
36. 注释是稍差的文档。更好的是清晰的命名。让代码讲自己的故事。

前面已经说过了。
37. 造轮子是很好的锻炼方法。前提是你见过别的轮子。

这里说的是程序员的自我修炼的过程。确实,对于一个需求场景,我们应该先想想有没有现成的开源项目可以用,然后再看能否把开源项目拿来改,最后自身足够强大了,就自己做一个轮子。
38. code review最好以小组或结对为主。因为对业务有足够了解建议才更有价值。而且不会成为负担。注意,提交过程中的管理员review很容易成为瓶颈。

这点我做的不好,在我这么多年的工作中,也只有为数不多的Code Review Meeting。
39. 提问前先做调研。节约大家的时间。

是啊,Google能够直接告诉你答案的,那就不用再问别人了。
40. 永远别小看程序媛(╯3╰)

只要是正在的码农,在我看来是没有区别的。所以没有小看或者高看的意思。

以上都是我的个人感受写给自己,看看差距,希望以后能做的更好吧。

posted @ 2016-01-28 15:39  深蓝  阅读(1375)  评论(1编辑  收藏  举报

我要啦免费统计