有哪些新手程序员不知道的小技巧?

 
作者:大狐狸
链接: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/559577427
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

1. 不要毫无计划地写代码,思考、调研、计划、编码、测试、修改,一个都不能少;

2. 不要写代码前过度计划,在一头钻进代码前做点计划是好事,但是即便是好事,也可能物极必反。喝太多的水都会使你中毒呢;

3. 请勿低估代码质量的重要性,如果你只能够关注你所写的代码的一个方面,那么肯定是可读性。表意不明的代码就是垃圾,甚至是不可回收的垃圾;

4. 使用实现功能的最简单方案,作为专业的程序员,你的职责不是找出问题的一个解决方案,而是找出问题的最简单的解决方案;

5. 适时放弃,当你开始怀疑一个解决方案的时候,你就应该考虑抛弃它,并且重新思考这个问题。不管你已经在这个解决方案中投入了多少精力。像 GIT 这样的版本控制系统能够帮助你分开管理和尝试多种不同的解决方案,把它利用起来吧;

6. 擅用 Google,除非你正在使用一种极其前沿的技术,否则当你遇到一个问题时,很可能别人早就遇到过同样的问题了,并且也找到了解决方案了。给自己省点时间,先 Google 一下;

7. 做好封装,基本的想法就是你想你的代码高内聚低耦合,意思是说保持相关的代码在一起(在一个类中),降低不同类之间的相互依赖;

8. 做好规划,写好需求再写代码,尽可能编写目前正在实现的方案所需的最少量代码;

9. 要懂算法,使用合适的数据结构;

10. 不要写重复性代码,要用好配置文件,不要使用没必要的条件语句和临时变量;

11. 做好代码注释,但是不要给傻子都知道的代码写注释;

12. 一定要写好测试,如果可能的话,甚至在开始写代码实现需求之前,你就应该开始预估和设计需要测试校验的情况了。测试驱动开发 (Testing-driven development, TDD)不是什么花俏的炒作,它是会实实在在会对你思考功能特性、寻找更好的设计方案产生积极影响的。

13. 不要觉得代码运行起来就是正确的,有些时候代码的 bug 可能并不是显而易见的;

14. 要能够质疑既有代码,作为一个初学者,总是应该假定那些你读不懂的、且没有文档注释的代码很可能就是糟糕的代码。质疑之,询问之,使用 git blame 揪出罪魁祸首!

15. 不要过度迷恋最佳实践,我觉得“最佳实践”其实是害人的,它暗示着你不需要深入研究它,这就是有史以来最佳实践,不用质疑!

16. 不要过度迷恋性能优化,如果你在运行代码之前就在优化它了,那很可能你就是在过早优化代码了,也很可能你正在费时费力做的优化是完全没必要的。

17. 以用户体验为目标,要站在最终用户的角度看问题。专业的开发者要考虑这个特定功能的用户需要什么、怎样使用,要想方设法使得这个功能容易让用户发现和使用,而不是想方设法在应用中用最便捷添加这个功能,毫不考虑这个功能的可发现性和可用性。

18. 为你的开发任务挑选合适的工具,你可以使用最原始的工具建造房子,然后享受甜蜜时光。你也可以花费一些时间和金钱去了解先进的工具、更快地建造更好的房子。工具在不断地改进中,你要乐意去学习它们、使用它们。

19. 要理解好代码问题和数据问题之间的关系,即使是程序中最小的 bug 也会导致它所管理的数据去到一种不可预测的状态。尤其是当所有数据校验都完全在这个有 bug 的程序中进行时。

20. 切勿重复造轮子,使用好现有的轮子和各种开源库,会让你事半功倍。当然,不要仅仅为了使用一两个函数就引入一整个代码库,在 JavaScript 中的典型例子就是 lodash 代码库;

21. 对代码审查保持正确的态度,应该把每一次代码复审当作是学习的机会,欢迎他们、感激他们、从中学习,最重要的,当你从你的代码复审人员那里学习到东西的时候,要感谢他们;

22. 用好版本控制工具和系统,新手往往低估了一个好的版本控制系统的威力,我这里所说的好的版本控制系统其实就是指 Git;

23. 不要过度使用共享状态,一个新手可能会尝试使用定时器来解决这个共享变量的竞态条件问题,特别是当他们必须处理一个数据锁的问题时。这是危险的标志,别这么做,注意它,在代码复审中指出它,永远也不要接受这样的代码。

24. 正视 Error,Error 是好东西。Error 意味着你在进步,意味着你可以通过简单的后续修改就获得更多的进步。专业程序员喜爱 Error。新手则痛恨 Error;

25. 学会休息,任何人的大脑都需要休息,身体也需要休息。

 

 

代码体现一个人的能力,也体现一个人素质、工作态度以及修养。编码不易,且编且珍惜。好的代码是对项目的负责,对个人职业未来尊重,对团队对同事的尊重

posted @ 2019-05-07 09:31 LGGGGG 阅读(...) 评论(...) 编辑 收藏