|
很多新手程序员在工作岗位上总会遇到这样那样的问题，或者工作了一段时间遇到瓶颈期不上不下，除了基本功的掌握意外，还有很大一部分原因在于你有没有养成良好的工作习惯，没掌握工作技巧。今天的文章，小编就带大家分享一下那些只有老程序员才知道的干货技巧。
1.重构是程序员的主力技能。
好多设计模式不是提前就设计出来的，而是重构出来的。很多情况是我们在做设计的时候考虑不到的，是写代码时也考虑不到的，只有在项目上线后，客户使用过程中才会反应出来，这个时候就需要对项目进行扩展，版本升级，这时就体现老程序员实力的时候了，就是根据已有的情形，结合新的客户需求，使用合适的设计模式，使得代码能够优雅的扩展。
2.工作日志能提升脑容量。
技术博客能够提升脑容量才是真的。很多项目中遇到的问题，解决了，也许以后还会再次遇到，也许别人也会遇到，那么就写成博客，自我总结，方便以后自己或者其他程序员遇到同样的问题。
3.先用profiler调查，才有脸谈优化。
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 2Face的交流过程中，交流后顶多拍照留存，根本无法建立有效的知识库，以后想到之前的讨论，怎么检索？怎么修改？写Wiki才是王道，Markdown只是一种写Wiki的方式罢了。
20. leader问你任务时间，你答不上来。很可能是任务拆分不够细。
细分到没有疑问吧。应该是的，如果不知道任务时间，那么说明要么你根本不懂这个任务怎么做，完全不会，要么就是任务太大了，不好估计时间。
21. 宁可多算一周，不可少估一天。别总因为你的“乐观”而boss受惊吓。
是啊。程序员在估计工时的时候总是太乐观。随便开口就是一个小时就能搞定，半天就能做完。完全没有想到该修改对其他模块的影响。一个修改后的单元测试，可接受测试，UAT环境测试，再到上线，很多地方都得花时间的。一旦某个测试不通过，然后又得调试，修改，再进行单元测试，可接受测试~~~~
22. 最有用的语言是English，其次的可能是Python。
好吧，我英语不好。Python在当下确实是有着简单易上手，应用面广兼容性强的优点，很适合0基础新手学习。
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. 永远别小看程序媛
不要产生莫须有的偏见，女生有着先天的细心特质，所以在写代码中间往往更加细致完善，所以永远不要小看了和你有竞争关系的程序媛。
了这么多，你都掌握了吗？程序员多金体面好就业，想加入这个行业吗？那就来北大青鸟徐州中博吧，0基础入门，在职技能提升，技术多元拓展，懂你多样化的需求，更能给你一个美好的前程。
 |
