本来题目里说的是两件事的，合在一篇里写，足以见证这一周的tough。
先说第二件事，其实和第一件也有关系。根据客户的需求，修改了index.html页面。本应该上传到/templates下，却一不小心上传到网站根目录/，把客户原本的flash首页给覆盖了。这下心想over了，俊哥那应该没有存底的，只好自己做一个吧，embed标签还是会的。
刚用编辑器建立一个新的html文件，要先写上keywords和description，就用google百度了一下客户的网站，看到了一句短短的描述。下意识的点了链接，发现点开的竟然不是index.php而是index.html的flash首页！Oh~搜狗浏览器威武~看来是搜狗把页面和域名都缓存了缘故。查看源代码，ctrl+c，Ctrl+v,Ctrl+s。。
（我们也可以通过查看网页快照找回从前的页面源代码，前提是你的站点被收录了）
吸取教训：1、以后静态首页扩展名用.htm，模板文件用.html或者.php，避免覆盖；2、或者首页模板文件不叫index.html而叫做default、Homepage；3、不管怎样，以后上传文件多加小心，合理给文件命名，最大程度避免杯具的再次发生。
说第一件事。
去年做的单子，客户是自动控制行业的一家公司。最近，原本负责他们公司网络的网管员（也是负责他们公司网站建设的人）走人了。新上任的这一位网管貌似有点想法，一直在联系我，前后提出了一些更改方案，主要的修改是把产品分类从三级增加到5级，我按他的要求做了。完了之后，说还是不完善，又提出让我过去当面沟通。
见面之后，我很诧异他竟然是个男的，电话里我一直以为是个御姐~o(∩_∩)o 哈哈。交流过程中，我发现他们走人的那位似乎工作交接没有做到位，这位新的网管简直是完全不知所以然，连个后台地址用的都是测试时候用的虚拟主机四级域名（年前就弃用了）。。
我向他展示了新后台的使用方法后，他倒是气定神闲提出了很多前台页面的修改需求，还不忘讽刺他那位前同事接手的这件事（网站建设）没做好。我当即表示，一开始需求就是你们客户提出的，另外我们对你们行业也不甚了解，自然要按照你们客户的需求来做。现在你觉得没有满足你的需求，那也正是说明当初你根本没弄清楚自己的需求，责任不在于我们开发人员。可以说，现在的情况是你们需求产生变动，不是我们当初没把你们需求做好。
他哪里知道，他提出的几点修改需求，足以让我让我和俊哥把产品分类推到重做，况且我之前花在产品分类和其他一些地方上的修改已经很多了。
我和俊哥说了，他说没事，需求变动大就要他们加钱。谁知过两天之后，客户又打来电话说，我给你个网站地址，你就照着上面的来做。。看了看 说行
前后两天的努力，总算按客户的意思做好了，前台页改得面目全非，动用到了数据表结构变更，url更是重新设计，分类列表的递归输出。。不过还好，最后终于上线了。
这次的事让我体会到跟踪客户需求变更的重要性，因为有时候，用户只是简单的一句话，对于项目的调整来说工作量是非常巨大的。。在项目的初期，我们应该先调研，帮客户弄清需求，并考虑将来可能遇到的需求变动；在适当的时候，我们可以让客户知道需求变更的代价。
通过这个项目，也开始有点体会到“随着 Web 应用程序变得越来越复杂，简单的 CRUD 操作已经无法满足对于复杂应用程序的开发要求。”接下来，要好好学习一下软件工程，并把面向对象的程序设计和实现运用到新项目当中去。。
回顾一下曾经开发过的 PHP 应用，大部分开发者都会发现这些应用中，数据的创建、读取、更新和删除操作是重复最多次的操作。但是不管我们如何简化这些 CRUD（创建、读取、更新、删除）操作，面对客户不断变化的需求，应用程序的内在结构总是逐渐变得凌乱。
而造成这种情况的根本原因就是我们没有正确使用面向对象的技术来设计和实现这些应用程序。由于业务逻辑固有的复杂性被所谓的 CRUD 快速开发能力所掩盖。本应是内聚的业务逻辑却拆散为一个个 CRUD 操作，分散到了应用程序的不同部分。如此一来，业务逻辑的变化必然会导致应用程序内部产生连锁反应式的改动，应用程序内在结构的逐渐腐朽变成了不可逆转的趋势。
近期评论