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