《Act with Prudence》读后感

《97 Things Every Should Know》中第一个编程方面的建议

文章链接：行事谨慎

　　很赞同文章中的观点，在做项目中是要谨慎行事和考虑后果。一直在项目前期考虑不够周到，以至于在项目后期不断解决项目前期带来的技术问题。刚入行半年，希望能在项目开始能考虑得全面一点，使得技术债务能轻一点或者没有。

文章翻译：

“无论你做什么，都要谨慎行事以及考虑后果”——Anon.

　　无论时间表在一开始迭代的时候看起来有多么的舒适，有时候你都无法避免压力。如果你发现你必须在“正确地做这件事”和“快速地解决这件事”之间做出选择，通常“快速地解决这件事”是很有吸引力的，因为你知道你以后会回来解决这个问题的。当你对你自己、你的团队、你的伙伴做出这个承诺，你是认真的（you mean it参考有道翻译）。但是通常下一个迭代会带来新的问题，而你会将注意力放在这些问题上。这一系列可延期的工作被称为技术债务，不是你的朋友。特别的，Martin Fowler 在他的技术债务中称这种故意的技术债务不应该与无意的技术债务混淆。

　　技术债务就像是借贷：你在短期时间内会从中受益，但你必须为此支付利息直到它被偿还完。代码中的捷径会使添加功能或者重构你的代码变得困难。他们是缺陷和脆弱测试案例的滋生地。你离开它越久，它就会变得更糟糕。当你着手进行最初修复时，可能会有一堆不太正确的设计选择叠加在最初问题之上，使得代码变得难以重构和纠正。事实上，通常只有当事情变得糟糕到你必须要解决它，你才会回头去解决它。到那时候问题是如此难以解决，你真的没有时间或风险。

　　有时，你必须承受技术债务以满足最后技术债务或实现某个特征的一小部分。不要尝试着处于这种状态，但是如果情况绝对需要，那就去做吧。但是（这是个大大的但是），你必须追踪技术债务并迅速偿还，否则事情就会迅速恶化。一旦你做出妥协的决定，写任务卡或者记录在你的问题追踪系统中以确保它不会被遗忘。

　　如果你计划在下一个迭代中长话债务，那么花销将是最小的。不偿还债务会产生利息，而利息应该被追踪以使花销可见。这将强调技术债务对业务价值的影响，并能适当确定偿还的优先循序。如何计算和追踪利息的选择将取决于特殊的项目，但你必须追踪它。

　　尽可能快地偿还完技术债务，否则这将会是轻率的。

　　翻译如有错误欢迎指正！