3月心得

3月，从402回到601。抢盐抢厕所之余，偶然的一个机会，看了下敏捷相关的几本书。   XP这档子事儿，之前一直认为很虚，很不靠谱。在那时，一套代码早已烂熟于心。基本上需求都可以在这上面轻松地实现。因为，总是面对着自己的代码。没有什么实现觉得不能理解的。一切都是顺理成章。   但是，当我读到别人的一整套解决方案时。感觉完全无法理解。除开智力问题，这里面有许多原因。一、没有文档，哪怕是图也没有。注释也基本不全，还有些是过时的错误注释。二、这是一个遗留系统。各种更改，他们发生的原因，早已消弭于流逝的岁月中，成为坊间流传的灵异故事。三、编程风格前后不一。一个面向对象的框架，其中塞满了面向过程的代码。四、各种未知的错误隐藏其中。没有人可以对我保证任何事情。一切皆有可能。五、控制过程散落在绘图线程中，就像银河中的璀璨群星，每一颗都散发相同的智慧光芒。   当然，现在这一切都已经过去。往事不堪回首，都在加班的月明中。 那时，我只是觉得，应该有文档，更改记录。我想如果能用自己的那套解决方案，一切都没有问题。在我看来，我所熟悉的那套方案，是能够帮助我轻松解决问题的。但是，这种事情是绝对不可能发生的。而且，我错了。   问题的关键，不在于哪套方案更优。而是缺少软件制作过程的控制。曾经自己开发SLG的整个过程，同样很痛苦。之后，做ARPG，同样不轻松。自己的代码，拿来给其他程序员用。其他程序员还是能找到很多问题。解释清楚一个战斗过程，居然用了一个星期的时间。自己认为开发得很好的东西，别人一样认为不健壮。   那么，我的代码，同样也面临着这样的一些问题。一、没有文档，代码全靠言传身教。二、没有测试，无法作出任何保证。三、没有版本控制。随着一遍又一遍地修改，总有一天我不再认识那曾是我开发过的。四、没有把变化很好地隔离开。应对变化是修改而非扩展。五、软件面临腐烂的危险。总有一天，它也会变成一个遗留系统。其他人读这个代码时，也会经历如我一般的痛苦。   面对这些问题，我变得有些不再敢写程序。如果我写出的程序都是这样的遗留系统。那岂不是在制造浪费其他人时间的垃圾？如果仅仅以写出能够运行的软件为目标，就是在制造垃圾。所以，那些认为程序只有对错之分的看法。应该扔到垃圾桶里了。程序也有优雅和丑陋之分。丑陋的程序就是最大的错误。   要让程序变得更加地灵活，开发过程变得更加敏捷。不是快速，是敏捷。不可能让后来的程序员读枕头一样的用户手册再进公司。程序必须传承下去，不是每次都推倒重来。程序必须变得越来越灵活而强壮，而不是变得越来越臃肿，越来越腐烂。   怎么办？一开始就确定所有需求，签字画押，绝不更改。这是不可能的。只有编程练习会是这样。那么，考虑所有的可能性，把所有的可能性都写到代码里面。即使现在不用，总有一天会用得到。这只是画了一个更大的圈而已。而且也并不灵活。要不，干脆不要改了。做自己的软件让程序员画圈圈去吧。   不绕圈子了。   必须适应越来越快的变化节奏。让用户满意，让用户选择。不要替需要软件的人做主。只做用户需要的软件。更多地沟通，和沉默软件说再见。（一直沉默，直到软件发布的那天，蹦出一个大块头出来，吓所有人一跳。）   把一步提供完整解决方案的想法改掉，每天都提供可以运行的软件。让反馈在一开始就发生。把事无巨细的计划扔掉，谁都不可能真的提供这样一份计划。既然每次总结的时候，都发现没有完全正确的计划。何必浪费时间去做这样一份错误的计划呢。只计划马上可以搞定的事情。   一开始就测试。将要做的事情变成要做的测试列表。测试>失败>编码>测试>成功>重构>测试。从测试开始，一开始就以保证正确为目标。并且让正确这档子事儿有唯一的标准。而以重构为结束。让代码的每一个结构都是灵活的。都是面对变化，隔离变化的。让面向对象的语言编写的代码真正有面向对象的结构。   代码集体所有制。公开代码，轮流复审。只留下最能说明设计的图形或简短文字。让代码原子化，不要太多函数中注释。   每个周期之前必须回归测试。保证每一步都在正确的基础上前进。每日提供可运行的软件，每日都要反馈。修改意见留在下一个周期中解决。项目进度不再仅仅写在纸上，而是装到运行的设备里。开发速度不会无法量化，只会越来越精确。   这些就是三月到现在读那几本书的心得。这几本书改变了我对编程的认识。我想无论今后是哪门语言或者什么技术，这样的观念都会对我有用。但是，观念认同归观念认同。实践起来并不轻松。如何获得需求，如何转化成测试列表，在我进行场编修改的过程中就是一个重大的障碍。还需要更多地实践来完成自己的变化吧。