最近在朋友圈看到别人分享的一篇知乎回答: 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╰)
只要是正在的码农,在我看来是没有区别的.所以没有小看或者高看的意思.
以上都是我的个人感受写给自己,看看差距,希望以后能做的更好吧.
来源: http://click.aliyun.com/m/11240/