知乎几条不错的想法

作者：大狐狸 链接：https://www.zhihu.com/question/36426051/answer/76031743 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

本来只是分享几条看法，没想到会有这么多人喜欢。我再补充一些，希望能对进阶中的程序朋友有帮助。手机敲得，比较凌乱。作为个人意见仅供参考。 1.重构是程序员的主力技能。 2.工作日志能提升脑容量。 3.先用profiler调查，才有脸谈优化。 4.注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释，实际就是背景噪音。 5.普通程序员+google=超级程序员。 6.单元测试总是合算的。 7.不要先写框架再写实现。最好反过来，从原型中提炼框架。 8.代码结构清晰，其它问题都不算事儿。 9.好的项目作风硬派，一键测试，一键发布，一键部署; 烂的项目生性猥琐，口口相传，不立文字，神神秘秘。 10.编码不要畏惧变化，要拥抱变化。 11.常充电。程序员只有一种死法：土死的。 12. 编程之事，隔离是方向，起名是关键，测试是主角，调试是补充，版本控制是后悔药。 13. 一行代码一个兵。形成建制才能有战斗力。单位规模不宜过大，千人班，万人排易成万人坑。 14. 重构/优化/修复Bug，同时只能作一件。 15. 简单模块注意封装，复杂模块注意分层。 16. 人脑性能有限，整洁胜于杂乱。读不懂的代码，尝试整理下格式; 不好用的接口，尝试重新封装下。 17. 迭代速度决定工作强度。想多快好省，就从简化开发流程，加快迭代速度开始。 18. 忘掉优化写代码。过早优化等同恶意破坏；忘掉代码作优化。优化要基于性能测试，而不是纠结于字里行间。 19. 最好的工具是纸笔;其次好的是markdown。 20. leader问任务时间，若答不上来，可能是任务拆分还不够细。 21. 宁可多算一周，不可少估一天。过于“乐观”容易让boss受惊吓。 22. 最有用的语言是English。其次的可能是Python。 23. 百闻不如一见。画出结果，一目了然。调试耗时将大大缩短。 24. 资源、代码应一道受版本管理。资源匹配错误远比代码匹配错误更难排查。 25. 不要基于想象开发， 要基于原型开发。原型的价值是快速验证想法，帮大家节省时间。 26. 序列化首选明文文本 。诸如二进制、混淆、加密、压缩等等有需要时再加。 27. 编译器永远比你懂微观优化。只能向它不擅长的方向努力。 28. 不要定过大、过远、过细的计划。即使定了也没有用。 29. 至少半数时间将花在集成上。时间，时间，时间总是不够。 30. 与主流意见/方法/风格/习惯相悖时，先检讨自己最可靠。 31. 出现bug主动查，不管是不是你的。这能让你业务能力猛涨、个人形象飙升; 如果你的bug被别人揪出来.....呵呵，那你会很被动～≧﹏≦ 32. 不知怎么选技术书时就挑薄的。起码不会太贵，且你能看完。 33. git是最棒的。简单，可靠，免费。 34. 仅对“可预测的非理性”抛断言。 35. Log要写时间与分类。并且要能重定向输出。 36. 注释是稍差的文档。更好的是清晰的命名。让代码讲自己的故事。 37. 造轮子是很好的锻炼方法。前提是你见过别的轮子。 38. code review最好以小组/结对的形式。对业务有一定了解，建议会更有价值（但不绝对）。而且不会成为负担。管理员个人review则很容易成team的瓶颈。 39. 提问前先做调研。问不到点上既被鄙视，又浪费自己的时间。 40. 永远别小看程序媛(╯3╰) 

作者：司马奔腾 链接：https://www.zhihu.com/question/36426051/answer/82579790 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1. 程序不等于数据结构加算法，而等于搜索引擎加英语。 2. 技术群是萌新的搜索引擎，同时也是老鸟的效率陷阱。很奇怪，喜爱社交的手艺人技术总是不咋地。 3. 遇到匪夷所思的Bug时，不要信邪，错误一定出在你自己身上。要坚信，引擎、类库以及语言本身，就像你的女友或老婆一样，永远正确。同样，所谓“运行效率低”也是一样。 4. 推荐一本技术书：《逻辑学导论》。 5. 魅力低的人能力总是被低估，团队中不善言辞以及长得丑的人值得留意。反之也成立，“你长得真好看”，“你给人的感觉很不错”，可以作为“你丫技术真烂”的委婉说辞。 6. 同事骂策划或产品傻逼，自己跟着骂骂就得了，千万别真的那么想，否则会降低你的可合作性。可合作性是项很重要的能力。 7. 《设计模式》、《人月神话》、《人件》、《我的编程感悟》等业内知名度很高的书，其实没什么卵用，但依然推荐阅读，可以用来和同行聊天时装逼。尤其是和写Java的程序员聊设计模式，能把人给唬跪了。但不要和用C系列语言的程序员聊这个。 8. 自动识别是IDE的标配，因此匈牙利命名法除了降低编码效率之外没什么别的好处。除非你用记事本敲代码，你长得真好看，你牛逼。 9. iOS开发真的是……非常简单，连初中小孩都学得会。招人难只不过因为Mac电脑普及率低。推荐给不明前途的新人。 10. 新人如果面试iOS，记得花一小时把斯坦福大学的某节有关MVC的公开课看明白，面试时候使劲讲。对面主程草包一点的话，没准会觉得醍醐灌顶，终于找到了之前遇到的一些奇葩问题的根源。 11. 有一种傻逼，总是嫌弃别人造的轮子不够圆，非要自己亲手造个方轮子。这种傻逼到处都是。以现成的类库坑多为由不用，非要自己写，不过是避开了现有的坑，转而亲手挖坑亲自跳。 12. H5真的没什么前途，那概念是用来忽悠傻钱的，始作俑者是李开复大大。新人可别被坑了。 13. cocos真是好啊！大家都快去用！Unity真垃圾！一大堆坑而且闭源没法改！千万别用！做游戏的都快去用cocos去！触控靠谱！cocos大法好！都别用Unity嗯。都别用才好。 14. 翻译官方文档是通向“业界大拿”的捷径。 15. 以极客自居的，多为极品。 16. 语言之间的隔阂，不过是要花一周熟悉下语法。勤奋点三天就够了。技术是技术，语言是语言，一门技术可以跨多门语言，程序员以技术分，而非以语言分。只有外行和新人才混为一谈。当然有不少写了多年程序依然停留在语法层面的老新人也分不清这个。 

1. 搜索。。。80%的问题可以通过搜索找出答案，当然了要用Google不要用百度。 2. debug。。。80%的问题都可以通过断点找出答案。 3. 多看书。。。80%的问题在书本/规范里面都有答案。 4. 多写代码。。。80%的问题都是由于缺乏实践造成的。 5. 多思考。。。80%的程序员都因为缺乏思考而被20%的优秀程序员落下。 6. 多学习新知识。。。80%的知识来自自学。 7. 多运动。。。80%的程序员处于亚健康状态，其中部分还有猝死风险。

作者：鲁小夫 链接：https://www.zhihu.com/question/36426051/answer/67423215 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。