1700453814
（6）多写文档
1700453815
1700453816
写注释、写说明、写报告都是对代码或项目的回顾和总结，不仅仅是为了后续的参与人员，同时也是为了整理自己头脑中混乱的思维。
1700453817
1700453818
（7）保持程序版本的简单性
1700453819
1700453820
一个项目不要保持多个版本，即使有分支也必须定义出项目合并的条件，或者时间约束，或者目标约束，不可任由版本扩散。
1700453821
1700453822
（8）做好备份
1700453823
1700453824
世界上没有万无一失的事情，不做备份，一旦灾难发生就无挽救的余地了，经常把代码拷贝到不同的主机上备份是一个好习惯，如果能够自动备份那将是一个非常好的方式。
1700453825
1700453826
（9）做单元测试
1700453827
1700453828
单元测试不仅能增强你的信心，也能给你带来好名声—后续者一看，“哇哦，单元测试写得这么完整，肯定是一个认真、负责的人”。
1700453829
1700453830
（10）不要重复发明轮子
1700453831
1700453832
在项目中使用已经成熟的工具或框架，而不是自己编写。但是如果想共享一个新的MVC框架，那就尽管去重复发明轮子吧，它不是以交付为目的的，而是以技术研究为目标的。
1700453833
1700453834
（11）不要拷贝
1700453835
1700453836
当您按下Ctrl+C的时候，问问自己“我在做什么？拷贝是否是唯一能做的？为什么不能重构一下呢”，不要让大段的代码散落在各处，不要做搬运工，不要做拷贝工，要做技术工。
1700453837
1700453838
（12）让代码充满灵性
1700453839
1700453840
为变量、类、方法起个好听的名字是一个不错的主意，为代码增加必要的注释也是很好的办法，“One Line”能解决一个上百行代码的问题，也是一个优秀的实现。
1700453841
1700453842
（13）测试自动化
1700453843
1700453844
不管是性能测试、单元测试，还是功能测试，想尽办法让它自动化，不要在测试之前手动配置或触发条件，这不够人性化，也同时让代码“汗颜”—本是用来自动执行的，但却被手动设置了条件。
1700453845
1700453846
（14）做压力测试
1700453847
1700453848
不要相信业务人员“最多200个用户使用”之类的话，把业务人员制定的指标扩大3倍，然后再做压力测试。不要迷信自己的代码很健壮，在高并发时只有上帝知道发生了何事，你又怎么能知道？
1700453849
1700453850
（15）“剽窃”不可耻
1700453851
1700453852
多看开源代码，学习一下人家是如何编码的，然后经常“剽窃”一下，这也是提高技能的最佳途径，我们不是孔乙己，“剽窃”不可耻。
1700453853
1700453854
（16）坚持向敏捷学习
1700453855
1700453856
不管“敏捷”与“非敏捷”之间的争论有多激烈，敏捷中的一些思想是非常优秀的，例如TDD测试驱动开发、交流的重要性、循序渐渐开发等。
1700453857
1700453858
（17）重里更重面
1700453859
1700453860
UI（User Interface）是“面”，Java程序是“里”，客户首先感受到的是“面”，然后才是“里”，要想获得良好的第一印象，那就需要有一个简洁、清晰、便捷的UI，即使“金玉其外败絮其中”，我们也可以继续重构。
1700453861
1700453862
（18）分享
1700453863
[
上一页 ]
[ :1.700453814e+09 ]
[
下一页 ]