你是不是被所谓的软件工程误导了
当然这里没有攻击软件工程的意思，我指的是在这些写软件工程的相应的文章上面。
很多时候，我们总会去嘲笑那些代码写成这样的人
return n==0 ? 1 : n * factorial(n-1);（不好意思，今天看一下文章上面的例子）。
于是我就在想，什么样的东西可以应用上所谓的，好的软件工程。
软件工程又是怎么样的一个应用在现在我们所处的项目上。
以上面的例子来讲，我们这样去评价一个人的代码是不是好的，那是不准确。
每一个人写出什么样的代码，总是有原因的，而且总是有应用的地方，
写代码在我们这一阶层的人（指三年到十年叠码经验）第一个反应，通常就是拿一个最简单实现的方式。
从来没有去考虑过：接手我代码的人能力是什么样的，能看得懂吗。
而这一方面通常也被那些软件工程份子鄙视，甚至是嘲笑的理由。
注：我其实很想说，这些人可能没有啥编码的经验，只会吹牛。
那些软件工程书上面那些要求，更多的是一种个人修为上面的练达。
可能又有很多人跳出来骂我：看看，你又不懂了吧，小子一定没做过像样的项目。
对于我来说，软件工程这些方面的应用，在一些传统的软件上面适用度比较高。
传统软件定义：需要大的技术性沟通，不断升级及功能扩张。这个有难理解，大概意义上的通用软件吧。
而大部分的项目，能做到：代码书写相对标准，变量名意思清晰，函数定义规范。
已是相当不容易，为啥（因为时间紧，甚至那些做小项目的人，都没有做压力测试）
这个我看过我身边很多朋友所处的环境，以及我刚出道的时候经历得来。
虽然真实的项目中这样写代码的太少了。
甚至我现在做的事情中，也有非常多的GOTO（老一代的）。
再者，项目接手的人要求是什么样的。这样的要求是不是要得到某些方面的技术评估？
接手的人水平怎么样，能不能理解现在项目用到的几个技术点，
熟悉现在这种操作系统的特性吗？等等。
这些人，搞人力的从来没有会为我们评估过，虽然我们也一直在抱怨。
然后那帮新来的家伙也一直就这样骂老一辈的人为什么要这么写，写得真烂，
烂到我们都看不懂。
好，废话这么多了，应该想一下怎么样做好所谓的软件工程。
就像武功一样，我给这些定义一个等级
１：代码书写相对标准，变量名意思清晰，函数定义规范。
为什么是这样的，适用在什么地方？
适合所有的项目，这些东西坚持一下相对有好处的。
包括注释能让自个儿和别人看得懂（XP，你说给别人听吧，直到他听得懂）
出错控制说明清楚等等。。
２：良好的系统架构
我是想说，这个是做一个大系统的基础。
如果你连功能模块都分不清楚，哪些功能负责什么，怎么样去处理数据来源和数据递交到哪里，
怎么样做数据流向控制，怎么样做到系统的可扩展性，如何良好地应用到操作系统的特性和机制，
以上等等搞不定，别想做大系统了。
注：大系统的定义，应该是代码量超过五十万行。您还别嫌多，少于五十万还真拿不出手。
而在国内，这方面能做得好的，有哪几个人敢拍胸口？
有谁在编码开始之前做过这种像样的构架？
我想不多吧。
那些天天扯什么SE的人，有几个写过这样的程序？
哎，我不是鄙视这些人的意义，只是说手法有问题。
３：代码量评估
很多人在这一块估计没有什么底气了。。
为啥？
因为我们所涉及到的项目没有一个能够在这些软件工程里面通通适用的代码量评估标准。
说得烂XX一点，连一个大概的行业项目技术评估表都没有。
那些搞这帮家伙的人，没有一个人知道，在不同项目里面，具体的模块应该有多少代码量。
为啥？
因为不知道怎么实现，如何去实现才能适用第２个原则（这个应该是向下兼容的）
所以，估计也只能瞎扯。
所以得出来的评估，往往是天差地别的。
而这个代码量的评估，应该是在行业里面有经验，而且对应用的操作系统相关领域相当熟悉的人
BTW：这些个家伙可是相当吃香的啊。
而这样的人才需要多少时间培养出来？
七年时间～
只会多不会少。
为啥？
我们就来一个软件工程式的评估。
以现国内本科生毕业，现从事行业所用编程语言为C，为例。
出来搞C三年，才有点像样的思维，对当前操作系统的特性和工作原理，大概有一个了解。
再三年，用来做什么？知道怎么做才有效率，在既定的效率基础上面实现稳定。
还有一年用来做什么？娶老婆或者把MM，或者感叹人生为什么没有MM看上我。
这里面，还是需要努力的，应该还有学习，功能模块规划，语言特性与操作系统结合等等。
所以说七年只会多不会少。。
４：可继承性
相对牛B一点的，应该是这些代码能让一个同等水平，或者水平相对低一点点的人，
能够知道这些个破系统是做什么的，实现什么样的功能，然后继续维护添加一些新功能。
这一点，如果做到那就算有点个软件工程控制的样子了。
但是，我们也只能期望，那个做的维护的家伙水平能足够好。
否则也是白搭。如果没有出现这样的人，那我们只能一边骂人力和边手把手教了。
５：能让人学习和模仿
大的系统都是好的加烂的掺和在一起，而一个好的代码应该起到让人学习。
LUA的代码那些家伙不知道有没有看过了，
如果看过的话，估计又要被骂得不行了，
为啥？
很难看得懂啊。
人家几个小老头搞了十几年了。。
换成SE们的作法，那这玩意儿也别想折腾了。
这里申明一下，我不是反对软件工程控制。
而是反对那些没有经过大脑，要求在项目中要这要那的人。
做事情，唯一的要求就是把事情做正确。
这里面又会包含很多个思想，怎么做，时间，速度，效率，稳定性控制（这个很少人碰到，因为大家的程序没有7*24小时服务着，没有要求在失败的情况下怎么恢复，等等）
然后再考虑过这些事情上面，如何去取裁这些代码上面的控制才是正确的做法。
一味地去追求某些东西，更多的物极必反。。
这个就是我简单的观点，
不喜欢的，你也不用评论了，
因为我不喜欢别人骂我。。哈。。
很多时候，我们总会去嘲笑那些代码写成这样的人
return n==0 ? 1 : n * factorial(n-1);（不好意思，今天看一下文章上面的例子）。
于是我就在想，什么样的东西可以应用上所谓的，好的软件工程。
软件工程又是怎么样的一个应用在现在我们所处的项目上。
以上面的例子来讲，我们这样去评价一个人的代码是不是好的，那是不准确。
每一个人写出什么样的代码，总是有原因的，而且总是有应用的地方，
写代码在我们这一阶层的人（指三年到十年叠码经验）第一个反应，通常就是拿一个最简单实现的方式。
从来没有去考虑过：接手我代码的人能力是什么样的，能看得懂吗。
而这一方面通常也被那些软件工程份子鄙视，甚至是嘲笑的理由。
注：我其实很想说，这些人可能没有啥编码的经验，只会吹牛。
那些软件工程书上面那些要求，更多的是一种个人修为上面的练达。
可能又有很多人跳出来骂我：看看，你又不懂了吧，小子一定没做过像样的项目。
对于我来说，软件工程这些方面的应用，在一些传统的软件上面适用度比较高。
传统软件定义：需要大的技术性沟通，不断升级及功能扩张。这个有难理解，大概意义上的通用软件吧。
而大部分的项目，能做到：代码书写相对标准，变量名意思清晰，函数定义规范。
已是相当不容易，为啥（因为时间紧，甚至那些做小项目的人，都没有做压力测试）
这个我看过我身边很多朋友所处的环境，以及我刚出道的时候经历得来。
虽然真实的项目中这样写代码的太少了。
甚至我现在做的事情中，也有非常多的GOTO（老一代的）。
再者，项目接手的人要求是什么样的。这样的要求是不是要得到某些方面的技术评估？
接手的人水平怎么样，能不能理解现在项目用到的几个技术点，
熟悉现在这种操作系统的特性吗？等等。
这些人，搞人力的从来没有会为我们评估过，虽然我们也一直在抱怨。
然后那帮新来的家伙也一直就这样骂老一辈的人为什么要这么写，写得真烂，
烂到我们都看不懂。
好，废话这么多了，应该想一下怎么样做好所谓的软件工程。
就像武功一样，我给这些定义一个等级
１：代码书写相对标准，变量名意思清晰，函数定义规范。
为什么是这样的，适用在什么地方？
适合所有的项目，这些东西坚持一下相对有好处的。
包括注释能让自个儿和别人看得懂（XP，你说给别人听吧，直到他听得懂）
出错控制说明清楚等等。。
２：良好的系统架构
我是想说，这个是做一个大系统的基础。
如果你连功能模块都分不清楚，哪些功能负责什么，怎么样去处理数据来源和数据递交到哪里，
怎么样做数据流向控制，怎么样做到系统的可扩展性，如何良好地应用到操作系统的特性和机制，
以上等等搞不定，别想做大系统了。
注：大系统的定义，应该是代码量超过五十万行。您还别嫌多，少于五十万还真拿不出手。
而在国内，这方面能做得好的，有哪几个人敢拍胸口？
有谁在编码开始之前做过这种像样的构架？
我想不多吧。
那些天天扯什么SE的人，有几个写过这样的程序？
哎，我不是鄙视这些人的意义，只是说手法有问题。
３：代码量评估
很多人在这一块估计没有什么底气了。。
为啥？
因为我们所涉及到的项目没有一个能够在这些软件工程里面通通适用的代码量评估标准。
说得烂XX一点，连一个大概的行业项目技术评估表都没有。
那些搞这帮家伙的人，没有一个人知道，在不同项目里面，具体的模块应该有多少代码量。
为啥？
因为不知道怎么实现，如何去实现才能适用第２个原则（这个应该是向下兼容的）
所以，估计也只能瞎扯。
所以得出来的评估，往往是天差地别的。
而这个代码量的评估，应该是在行业里面有经验，而且对应用的操作系统相关领域相当熟悉的人
BTW：这些个家伙可是相当吃香的啊。
而这样的人才需要多少时间培养出来？
七年时间～
只会多不会少。
为啥？
我们就来一个软件工程式的评估。
以现国内本科生毕业，现从事行业所用编程语言为C，为例。
出来搞C三年，才有点像样的思维，对当前操作系统的特性和工作原理，大概有一个了解。
再三年，用来做什么？知道怎么做才有效率，在既定的效率基础上面实现稳定。
还有一年用来做什么？娶老婆或者把MM，或者感叹人生为什么没有MM看上我。
这里面，还是需要努力的，应该还有学习，功能模块规划，语言特性与操作系统结合等等。
所以说七年只会多不会少。。
４：可继承性
相对牛B一点的，应该是这些代码能让一个同等水平，或者水平相对低一点点的人，
能够知道这些个破系统是做什么的，实现什么样的功能，然后继续维护添加一些新功能。
这一点，如果做到那就算有点个软件工程控制的样子了。
但是，我们也只能期望，那个做的维护的家伙水平能足够好。
否则也是白搭。如果没有出现这样的人，那我们只能一边骂人力和边手把手教了。
５：能让人学习和模仿
大的系统都是好的加烂的掺和在一起，而一个好的代码应该起到让人学习。
LUA的代码那些家伙不知道有没有看过了，
如果看过的话，估计又要被骂得不行了，
为啥？
很难看得懂啊。
人家几个小老头搞了十几年了。。
换成SE们的作法，那这玩意儿也别想折腾了。
这里申明一下，我不是反对软件工程控制。
而是反对那些没有经过大脑，要求在项目中要这要那的人。
做事情，唯一的要求就是把事情做正确。
这里面又会包含很多个思想，怎么做，时间，速度，效率，稳定性控制（这个很少人碰到，因为大家的程序没有7*24小时服务着，没有要求在失败的情况下怎么恢复，等等）
然后再考虑过这些事情上面，如何去取裁这些代码上面的控制才是正确的做法。
一味地去追求某些东西，更多的物极必反。。
这个就是我简单的观点，
不喜欢的，你也不用评论了，
因为我不喜欢别人骂我。。哈。。