程序员,你其实可以做得更好

程序员如何更优秀
服务器君一共花费了149.237 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议
  1. 小范围的选择一些有用技术,透彻的学习它们,拥抱它们。然后不断的扩展这个范围。
  2. 理解各种数据结构的优点和缺点,包括它们在内存中和在硬盘上的各自表现。
  3. 理解各种算法的优点和缺点。
  4. 了解你的工作领域。关上电脑,去做你的用户们在做的事。
  5. 有准备,有愿望,有能力在任何时候投入到多种技术层面中。你必须知道表象下的技术原理。在“各个技术层面的掌握程度”和“编程能力”上有着密切的联系。
  6. 发挥你的想象力。永远都要问,“有更好的方法吗?”跳出常规思维约束。最好的解决方案也许还没有被发现。
  7. 优秀程序员:我优化代码。更优秀程序员:我设计数据。最优秀程序员:他们的不同之处是什么?
  8. 正确的构造你的数据。任何的缺陷都将造成你的代码里无尽的技术债务。
  9. 正确的命名事物。使用“动词-形容词-名词”格式来命名程序和函数。变量名要足够长,尽量短,有意义。如果其他程序员不能够理解你的代码,说明你写的不够清楚。在大多数情况下,针对下一个程序员而编码要比针对环境而编码重要的多。
  10. 把分析和编程分离开做。它们不是同类的事物,需要不同类型的劳力资源,需要在完全不同的时间和地点分开做。如果同时做它们,你一样都做不好。(我喜欢在一天的末尾做不涉及技术的分析,而在第二天早上进行编程。)
  11. 永远不要图省事走近道。永远不要把相同的代码部署两次。永远不要把一个变量命名成另一个变量名的一部分。也许你不明白这些规则,也许你要辩解。但如果你是遵守着这样做的,这些规则就会约束你正确的构造你的程序。图省事的做法是让那些低等级的程序员永远停留在低等级的原因。
  12. 学习如何测评程序性能。你会惊奇的发现从中能学到很多之外的知识。
  13. 学会区别对待问题细节和问题后果。问题细节不会导致太大的差别,而问题后果能导致世界灭亡。只关注后果。
  14. 密切关注你的用户/客户/管理人员。帮助他们认清楚他们的“what”,这比帮助他们明白他们的“how”要重要的多。
  15. 写一个框架,不论你是否打算用它。你将从中学到从其它途径中学不到的东西。
  16. 把你知道的东西教给他人——通过口口交流或通过写作。最终这将成为教育自己的机会。
  17. 永远要对你的客户/用户说“Yes”,即使在你不确定的情况下。90% 的情况下,你会最终找到方法实现它。10% 的机会,你将会去向他们道歉。这是重要的个人成长中付出的一点小代价。
  18. 寻找别人的做出神奇的事情但却一滩糊涂的代码。重构它。然后丢掉它,并发誓自己永远不要犯他们犯下的相同错误。(这样的程序你会发现很多。)
  19. 数据永远大于理论或观点。通过开发东西来学习数据。
  20. 有可能的话,开创自己的业务(服务或产品)。你将从中学到很多你做雇员永远学不到的关于编程的知识。

本文地址:http://www.nowamagic.net/librarys/veda/detail/2311,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2311

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《重构:改善既有代码的设计》 福勒(Martin Fowler) (作者), 熊节 (译者)

《重构:改善既有代码的设计》清晰地揭示了重构的过程,解释了重构的原理和最佳实践方式,并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了70多个可行的重构,每个重构都介绍了一种经过验证的代码变换手法的动机和技术。《重构:改善既有代码的设计》提出的重构准则将帮助你一次一小步地修改你的代码,从而减少了开发过程中的风险。

更多计算机宝库...