为什么产品经理总看不懂你写的代码
总有那么一段时间会看到产品经理和某个程序员因为代码的问题展开“声情并茂”（激烈）的讨论，程序员抱怨产品经理看不懂代码，产品经理指责程序员写的代码没有表现力。随着软件行业的不断发展，历史遗留的程序越来越多，代码的维护成本越来越大，甚至大于开发成本。而新功能的开发又常常依赖于旧代码，阅读旧代码所花费的时间几乎要大于写新功能的代码。
“复杂的代码往往都是新手所写，只有经验老道的高手才能写出简单，富有表现力的代码”此话虽然说的有点夸张，可是也说明了经验的重要性。我们所写的代码除了让机器执行外，还需要别人来阅读。所以我们要：写让别人能读懂的代码、写可扩展的代码。
写可测试的代码(代码应该具备可测试性，对没有可测试性的代码写测试，是浪费生命的表现)我们来看看如何写出让人看得懂的代码?需要注意些什么?
基于两个指导原则：
一.DRY(Don’t repeat yourself)
此原则如此重要，代码越少，Bug也越少，没有重复逻辑的代码更易于维护，当你修复了一个bug，如果相同的逻辑还出现在另外一个地方，而你没意识到，你有没有觉得自己很冤?
二.TED原则
简洁(Terse)
具有表达力(Expressive)
只做一件事(Do one thing)
三.举例说明
1.拒绝注释，用代码来阐述注释
反例：
///
/// ！@#$%^&^&*((！@#$%^&^&*((！@#$%^&^&*((！@#$%^&^&*((
///
//！@#$%^&^&*((！@#$%^&^&*((
var a = new List{ 2m, 3m, 10m };
var b = 2;
var c = 0m;
//！@#$%^&^&*((！@#$%^&^&*((！@#$%^&^&*((
foreach (var p in a)
{
c += p*b;
}
return c;
}
重构后：
public decimal CalculateTotalCash
{
var prices=new List{2m,3m,10m};
var itemCount = 2;
return prices.Sum(p => p*itemCount);
}
良好的代码命名完全可以替代注释的作用，如果你正在试图写一段注释，从某种角度来看，你正在试图写一段别人无法理解的代码。
当你无法为你的方法起一个准确的名称时，很可能你的方法不止做了一件事，违反了(Do one thing)。特别是你想在方法名中加入：And，Or，If等词时
2. 为布尔变量赋值
反例：
public bool IsAdult(int age)
{
bool isAdult;
if (age > 18)
{
isAdult = true;
}
else
{
isAdult = false;
}
return isAdult;
}
重构后：
public bool IsAdult(int age)
{
var isAdult = age > 18;
return isAdult;
}
4.拒绝HardCode,拒绝挖坑
反例：
if (carName == "Nissan")
{
}
重构后：
if (car == Car.Nissan)
{
}
四.关于DRY
平时大家重构代码，一个重要的思想就是DRY，项目在架构过程中会有各种各样的MODEL层，例如：
DomainModel，ViewModel，DTO。很多时候这几个Model里的字段大部分是相同的，于是有人就会想到DRY原则，干脆直接用一种类型，省得粘贴复制，来回转换。
五.利用先进的生产工具
以vs插件中的Reshaper为例，本文列举的大部分反例，Reshaprer均能给予不同程度的提示。经过一段时间的练习，当你的代码Reshaper给予不了任何提示的时候，你的代码会有一个明显的提高。
真希望我们某位程序员也看看这篇内容，平时写代码的时候多注意一下，因为小编实在是不想再看安静的办公室，突如其来几声吼啊！