思考的问题

在最近两年的工作中，我思考过这样一些问题：

项目----项目的总体评估，工期和报价，工作与休息的节奏等。
需求----从需求到编码，业务描述的方法（怎样清晰的描述业务有利于编码），功能设计标准（怎样的功能设计不会让用户疑惑）等。
编码----主要是在完善框架和技巧，来实现快速编码。
修改----代码调试，改bug，快速修改方面的技巧。
运维----总结运维的原则等。

工作的重要阶段

虽然阶段很多，但是现在说说对于下面3个，我的一些思考：

1是，项目评估。

2是，从需求到编码。

3是，修改。

1.项目评估

我现在有一套方法，能够评估出工期和报价。

主要的依据：

一是，我能把项目大体需要什么页面设想出来。

二是，做什么样的页面大体需要的编码时间我能估算（评估是按普通人通常情况下的编码时间来衡量的，虽然我的框架帮我更快完成）。

三是，项目中，纯编码时间：其他时间 = 1：2。

四是，时间有个参考的单价。

2.从需求到编码

我现在有以下的方法或技巧：

一是，在描述方面：

　　1.复杂的业务流程，可以通过业务流程图来说明。

　　2.一个页面的功能，可以从【数据初始化】【事件反应】两方面描述。

　　3.一个页面的显示，可以从【布局定位】【图形样式】两方面描述。我们经常说的有：【位置，宽高】，【背景，颜色，字体】等等。

二是，加快编码的具体技巧：

　　1.我有自己的框架和代码生成器，并且在工作过程中按照工作的需要完善，可以加快编码的速度。

　　2.对于单个的复杂的运算过程，我可以用【注释脚本技巧】平滑过渡。

软件设计与开发，最重要的2个过程是：

1.从需求到设计。

2.从设计到实现。

最重要的2种能力是：

梳理，推演。

3.修改

关于软件的修改，我在工作过程中有一些经验：

一是，写完代码要测试，不要出低级的错误。

二是，改代码前先整理，划分好段落，改的时候就更容易定位。

三是，对不熟悉的老代码的修改要谨慎，在有限时间里不要过于代码整洁强迫症，而要把实现业务逻辑作为第一问题。

最需要的能力和技巧

整理需求。

分解大问题成小问题。

查找问题。

前一段时间的侧重点

加强程序的可调试性。想的办法有：输出窗口，脚本调试，花式的变量打印和转换（例如根据内存的DataTable打印出建表加数据的sql语句）。

加强梳理需求的能力。就是要根据用户给的上下文，推出需要的设计；有时用户自己一套“术语”，就要想办法弄明白。

现在认为比较重要的步骤

1.从需求整理到设计。靠讨论》设计》确认。

2.快速编码和简单测试调通和代码整理。靠框架，代码生成器，技巧。

3.实际数据测试和修改。靠分析和技巧。

4.新技术研究学习。就算是靠阅读能力吧。

费时间长的

上面的几个【现在认为比较重要的步骤】，就是有可能花费时间比较长的项目。

什么时候费的时间会很长呢？

我觉的是：面对新问题时。问题越是新，越是熟悉的部分少，就越会花费更多的时间。

先按照目前认识到的重要步骤，强化这些重要的单项能力。

然后就是碰到什么问题，研究什么问题了。