老程序员的20条编码原则
所属分类 architecture
浏览量 2169
不要纠结于开发工具,不管是库、编程语言还是平台。
尽可能使用原生的构件。不要歪曲技术,也不要歪曲了问题本身。
为要解决的问题选择合适的工具,否则要为你所选择的工具重新安排你的工作。
代码不是给机器看的,而是给同事和未来的你看的(除非你写的是一次性代码或汇编代码)。
写代码的时候要考虑一下初级开发者
优秀的软件是协作开发的结果。高效沟通,进行开放式的协作。
信任他人,并让他人也信任你。尊重他人胜过尊重代码。
分而治之。为分离的关注点开发单独的低耦合模块。
进行单独的模块测试和集成测试。
尽可能按照实际情况测试,同时也要测试到各种边界情况。
不要把自己与代码捆绑在一起,
要想办法让其他人也能修改你的代码或者添加新的功能,
这样你才能更容易脱身去参与其他项目,或者去其他公司。
不要捆绑自己,否则很难成长。
安全性是分层的,每一层需要进行单独的评估,同时又与整体相关。
风险是一个业务决策,与脆弱性和概率有直接的关系。
每一个产品或组织都有不同的风险偏好(为了获得更大的收益,他们愿意承担风险)。
通常这三个关注点之间存在相互冲突:用户体验、安全性和性能。
要意识到每一行代码都有其生命周期,它们最终都会死掉。
有时候,一些代码会在发布之前就死掉,所以要学会放手。
代码可以分为三种:
一种是核心代码,就像汽车的引擎,没有了它,产品就毫无意义;
一种是必要的代码,就像是汽车的备胎,平时用得少,但一旦需要,它决定了系统的成败;
一种是增值的代码,就像汽车的杯托,如果有那是再好不过,但如果没有也不会影响产品。
不要把你的个人标识融入到代码里,人和代码应该是分离的。
不要把其他人对代码的评价与你自身联系到一起,在评价他人的代码时也要十分谨慎。
技术债务就像快餐一样,偶尔欠下一点技术债务是可接受的,
但如果你习惯了这样,它会毁掉你的产品(而且是以让你措手不及的方式)。
在寻找解决方案时,请按照这样的优先级进行决策:
安全性 > 可用性(可访问性和用户体验)> 可维护性 > 简单性(开发者体验)> 简洁性(代码量)> 性能。
但不能盲目照搬,而是要根据产品的特点进行取舍。
你积累的经验越多,就越是能够在这些因素之间做出权衡。
例如,在设计游戏引擎时,性能享有最高的优先级,但在开发银行应用程序时,安全性则最为重要。
拷贝粘贴是滋生 bug 的温床。
对你所拷贝或导入的东西加以审查,bug 一般会藏身在复杂性中。
依赖项复杂没有关系,但不能让它存在于代码中。
不要只顾着写正常的代码,处理异常的代码也要好好写。
让人们明白为什么会发生异常、如何检测到的以及怎样解决。
对所有的系统输入(包括用户输入)进行验证:尽早失败,并尽可能从错误中恢复。
我们要假设用户手里握着一把枪:你努力让用户输入一些其他的东西,而不是让他们的子弹射在你的脑门上。
不要使用依赖项,除非使用它们的成本比你自己写代码的成本低很多。
因为使用依赖项要导入、维护、处理 bug,在必要的时候还要进行重构,这些都是成本。
远离“炒作驱动开发”,但你要去了解它们,做一些尝试。
走出舒适区,每天都要学习。把学到的东西分享出来。
如果你以大师自居,就不是在学习。
接触更多的编程语言、技术、文化,保持一颗好奇心。
好代码不需要注释,而优秀的代码提供了良好的注释,
可以让任何一个原先没有参与代码演进、试错和需求过程的人更容易阅读、修改它。
尽量避免使用重载、继承和隐式的智能特性。
使用纯函数,它们更容易测试和诊断,否则的话就使用类。实现不同功能的函数要使用不同的名字。
在彻底了解问题之前不要急着写代码。
花在倾听和了解问题上的时间通常比花在写代码上的时间要多。
在写代码之前要先了解问题域。
问题就像迷宫一样,你要循序渐进,反复进行“编码 - 测试 - 改进”,直到把问题解决为止。
不要尝试去解决不存在的问题。不要进行投机性编程。
只有在确定代码确实需要具备扩展性之后才让代码具备可扩展性。
通常情况下,当代码被扩展之后,你会发现问题会变得与原先认为的不一样了。
大家一起开发软件会更加有趣。建立可持续发展的社区。倾听,激发灵感,学习,分享。
上一篇
下一篇
linux熵池太小导致随机函数阻塞
Random和SecureRandom
熵池与SecureRandom
sql优化建议
jvm codecache 相关整理
JVM MemoryUsage中init,committed,used,max说明