这代码看的有点懵了。。。

Question

无注释，无设计文档，没有任何可参考的一个工程代码，是你的话你用什么恰当的办法能把这些代码之间的逻辑与思路理出来？还原当时写代码的人的设计思路不容易啊~~~

Answer 1

哈哈
某人说中国IT的情况，中国的IT就如要斗快画出蒙罗丽莎一样
而外国的，会精雕细琢，绝不跟你都快那你明白为什么不写注释了吧？

Answer 2

我看的代码，一个init函数，一千好几行，注释倒是有，就是看不懂。
注释大概是这样的//初始化//参数处理//后续处理//后续处理1//后续处理2//后续处理3//后续处理4
这样的注释，我觉得还不如不写。

Answer 3

16#别人明明说的是：只想要注视（注释）
到你这里就变成了：“鼓励别人不写注释”；
就你这可怜的逻辑推理能力，还写啥代码。注释其实还真不是最重要的，命名规范和模块划分、解耦、分层做好了，比写一大推似是而非的注释（尤其是修改代码后没有同步修改的注释）好多了。
比如尽量不使用全局变量，用也尽量在一个地方用，控制好出入口，
尽量将事件入口，参数传递，消息监控等集中在一起，这些都是变化引发的原因，统一处理好，以参数形式传递给底层业务处理模型，保证业务模型的稳定性。
封装业务实体，针对实体来进行业务抽象
按业务划分接口，用接口统一规范。。
太多，就不细说了。
其实就是solid思想的体现，
也可以看看“反模式”

Answer 4

我会告诉你们 ，我现在维护一个09年的老项目，里面大量这种代码么？
 AddIds += dr["ColumnID"].ToString() + ",";
                    sb.Append("<tr id='trAd" + dr["ColumnID"].ToString() + "' align='center' class='bg01' onmouseout='return CancelSelectbgcolor(this,1)' onmouseover='return SetSelectbgcolor(this)'>");
                    sb.Append("<td height='25'  align='center' class='doubleline'>" + dr["SectionName"] + "</td>");
                    sb.Append("<td height='25'  align='center' class='end'>" + dr["sectionChildName"] + "</td>");
                    sb.Append("<td align='center' class='end' >" + dr["ColumnCode"] + "<input type=\"hidden\" value=\"" + dr["ColumnCode"] + "\"  id=\"ColumnName_" + dr["ColumnID"].ToString() + "\"/></td>");
                    sb.Append("<td align='center' class='end' >" + dr["Location"] + "</td>");
                    
                    sb.Append("<td height='25'  align='center' class='end'>" + GetAdNumber(dr["AdNumber"].ToString()) + "</td>");
                    if (dt.Columns["BuildAmount"] == null)
                    {
                        sb.Append("<td align='center' class='end' ><input onkeypress='event.returnValue=IsNumberText()' class='com_textbox_input'  id='overheadExpenses_" + dr["ColumnID"].ToString() + "' type='text' value='0.00'  style='width:80px;' /></td>");
                        AddOverheadExpenses += "0.00,";
                    }
                    else
                    {
                        AddOverheadExpenses += dr["BuildAmount"].ToString() + ",";
                        sb.Append("<td align='center' class='end' ><input onkeypress='event.returnValue=IsNumberText()' class='com_textbox_input' id='overheadExpenses_" + dr["ColumnID"].ToString() + "' type='text' value='" + (Convert.IsDBNull(dr["BuildAmount"]) ? "0.00" : dr["BuildAmount"].ToString()) + "'  style='width:80px;' /></td>");
                    }                    sb.Append("<td align='center' class='end'><img style='cursor:hand' onclick='deleteAd(" + dr["ColumnID"].ToString() + ")' src='../images/icons/Delete.png' /></td>");
                    sb.Append("</tr>");
                }
            }

Answer 5

16#别人明明说的是：只想要注视（注释）
到你这里就变成了：“鼓励别人不写注释”；
就你这可怜的逻辑推理能力，还写啥代码。注释其实还真不是最重要的，命名规范和模块划分、解耦、分层做好了，比写一大推似是而非的注释（尤其是修改代码后没有同步修改的注释）好多了。
比如尽量不使用全局变量，用也尽量在一个地方用，控制好出入口，
尽量将事件入口，参数传递，消息监控等集中在一起，这些都是变化引发的原因，统一处理好，以参数形式传递给底层业务处理模型，保证业务模型的稳定性。
封装业务实体，针对实体来进行业务抽象
按业务划分接口，用接口统一规范。。
太多，就不细说了。
其实就是solid思想的体现，
也可以看看“反模式”
尽量不使用全局变量为什么呢？

Answer 6

ctrl+f,找到调用的方法，函数等，然后在纸上画图，慢慢来，就可以还原成程序流程图

Answer 7

16#别人明明说的是：只想要注视（注释）
到你这里就变成了：“鼓励别人不写注释”；
就你这可怜的逻辑推理能力，还写啥代码。注释其实还真不是最重要的，命名规范和模块划分、解耦、分层做好了，比写一大推似是而非的注释（尤其是修改代码后没有同步修改的注释）好多了。
比如尽量不使用全局变量，用也尽量在一个地方用，控制好出入口，
尽量将事件入口，参数传递，消息监控等集中在一起，这些都是变化引发的原因，统一处理好，以参数形式传递给底层业务处理模型，保证业务模型的稳定性。
封装业务实体，针对实体来进行业务抽象
按业务划分接口，用接口统一规范。。
太多，就不细说了。
其实就是solid思想的体现，
也可以看看“反模式”
尽量不使用全局变量为什么呢？
变化集中处理，函数需要什么数据，用参数的方式传递过去。而不是肆意读取全局变量，第一是函数的范围一下子扩大到与变量相同了。第二是不易控制，你也不知道哪里还会修改这个变量，要维护这个变量，必然要写大量面向过程的代码。
第三是不利于线程同步。

Answer 8

我深有体会啊当初公司要求我写一个设置模块IP，端口和波特率啥的一个设置软件。还给了我源代码，说改改就行了。我一看，他么的要疯了！居然vb写的，2000多行代码，几十个函数，有的还层层嵌套，一口气读下来累个半死，除了几个显而易见的函数有注释，其他一个注释也没有，然后硬着头皮，看了一个星期，终于看明白了。同意楼上的，先从功能分析入手，然后跟踪调试

Answer 9

没看出很奇怪的地方啊？展示 和 逻辑代码耦合,这个一般用模板的方式解耦,这么写以后,每次改展示效果,必须经过项目生成,比较痛苦但是异步获取数据库数据，并且在鼠标经过事件，作为tips显示在前台的时候，除了后台拼接还有别的什么好方法吗,求指教？

Answer 10

没看出很奇怪的地方啊？展示 和 逻辑代码耦合,这个一般用模板的方式解耦,这么写以后,每次改展示效果,必须经过项目生成,比较痛苦但是异步获取数据库数据，并且在鼠标经过事件，作为tips显示在前台的时候，除了后台拼接还有别的什么好方法吗,求指教？json + 前端模板, 或者是后端数据结构+模板这样做前期开发的工作量稍大,维护很容易,主要是模式可以使人的思考聚焦，需要改表现的时候，不用管逻辑也有利于行业分工

Answer 11

没看出很奇怪的地方啊？展示 和 逻辑代码耦合,这个一般用模板的方式解耦,这么写以后,每次改展示效果,必须经过项目生成,比较痛苦但是异步获取数据库数据，并且在鼠标经过事件，作为tips显示在前台的时候，除了后台拼接还有别的什么好方法吗,求指教？json + 前端模板, 或者是后端数据结构+模板这样做前期开发的工作量稍大,维护很容易,主要是模式可以使人的思考聚焦，需要改表现的时候，不用管逻辑也有利于行业分工
嗯 懂了 谢谢

Answer 12

16#别人明明说的是：只想要注视（注释）
到你这里就变成了：“鼓励别人不写注释”；
就你这可怜的逻辑推理能力，还写啥代码。注释其实还真不是最重要的，命名规范和模块划分、解耦、分层做好了，比写一大推似是而非的注释（尤其是修改代码后没有同步修改的注释）好多了。
比如尽量不使用全局变量，用也尽量在一个地方用，控制好出入口，
尽量将事件入口，参数传递，消息监控等集中在一起，这些都是变化引发的原因，统一处理好，以参数形式传递给底层业务处理模型，保证业务模型的稳定性。
封装业务实体，针对实体来进行业务抽象
按业务划分接口，用接口统一规范。。
太多，就不细说了。
其实就是solid思想的体现，
也可以看看“反模式”
现在有时也觉得不想,或没必要,我说的不是这个意思,我当然知道代码在逻辑优化后,有时没有必要写注释,我的意思是,有时注释可以记忆,或在必要的时候,我没有说是每个地方都注释哈.工程大了,多了,注释有时很有用,凡是都不要太绝对哈,注释也要有个度.