[10/01周主题] – Web 项目开发中的常见问题
Author: 小权这周来一直在赶一个Web项目，没多少时间focus到其他上面，于是这周的主题就干脆做个整理，整理下web项目开发时遇到的一些问题和解决办法。
本周主题：Web 项目开发中的常见问题
一、中文乱码
建议统一使用UTF8，或者全局做个filter处理。
二、表单校验
使用第三方校验框架， 而非自己去写，可以减少很多工作量。
三、Ajax的使用
首页尽量少用ajax，页面初次加载时常会加载不上来，尤其多个Ajax实例同时运行。
四、UI 规范
UI最好是出Demo，跟客户确认，定终稿，然后开发按最终效果图实现页面最好，否则没有页面或者效果图，即使有统一的规范，还是会浪费很多时间去调UI问题。
五、浏览器的兼容问题
虽然IE6基本上淘汰了，可老机器上使用IE6的还是不少的，Css 在处理兼容问题时，建议分开处理，在页面进行浏览器version判断，读取不同的css，这样管理和调整起来都方便。
六、比较完整的测试数据
页面框架搭完了，看着效果不错，可是填完数据后会发现和想象的不太一样。
七、用JPA Or JDBC 与数据库交互
JPA与JDBC相比之下，使用JPA大大减少了编程人员的工作量，因此还是偏向使用JPA，特殊环境下再选择JDBC
近期琐事
Author: 小权最近Twitter成为我获取信息的主要途径，几乎每天醒来第一件事情是躺床上翻推。
黑莓
换黑莓了，本想换android的手机，无奈太贵，忍住诱惑，先玩玩黑莓过些时间再折腾android。
学车
囡囡开始学车了，法培已考，办理了上车手续，不过元旦前可能比较小，海淀驾校太火爆了，约车难。
项目
年底前又开始了一个紧时间的项目，春节前要完成M1并上线，加上手上的未完项目要同时进行，这段时间几乎是掐着时间算。
出游
本来计划1月份出游的，折腾了几天，最终还是计划赶不上变化，黄了，只能安排到年后了。
周主题推迟一周
Author: 小权由于最近另一个项目的启动，工作方面基本上是掐着时间在忙，所以周主题的任务就只能稍微往后推一周了。
预计本周四结合公司的培训内容，出一个有关JQuery的入门介绍，这个内容顺便就补给上周的周主题。
顺便预告下：接下来这周和下周会整理有关Java.Net包下一些常用类的使用，包括HttpClient的使用，以及XML Parser方面的汇总。
项目越到尾声越怕改动
Author: 小权项目接近尾声，最怕这样那样的修改，今天一个电话，快烦死了。
是关于JTable的打印，之前就因为嫌麻烦没搞彻底，简单表格的打印功能提供了，复杂点的就没弄，和业务员交流，导出Excel也可以，于是就直接让导出Excel再打印了，结果今天一个电话，和业务流程使用不相关的一个小头让全部统一提供打印功能，无语了！
唉，看看明天去摆扯的结果了，弄不好还得把剩下的打印功能加上，就看JasperReport和Swing绘制哪个稍微能不麻烦点！:(
Bug bug Bug bug
Author: 小权
看到这样的标题, 估计大概也知道本文要谈论的内容了, 是的, 有关bug的. 这里不得不感慨下, 最近修bug修出感悟来了, 这里总结下为什么. 1. 最重要的归根结底的是由于开发人员没有考虑全面, 大体功能完成了, 但是没有完善好, 各式各样的小bug, 能把人烦死. 2. 需求不明确导致的排第2位, 开发人员拿到需求, 开始做了, 但是不知道的是这个需求不完整, 于是乎做完了, 给测试, 给客户看了, 反馈回来改了, 测了, 又给客户看, 反馈又回来, 可能到头来, 整个功能绕了个圈, 脾气不好的绝对能气炸了. 3. 客户不把需求讲明白, 挤牙膏似的, 一点点给你挤, 需求从头到尾, 客户一直在给你添盐加醋, 到头来可以把他们自己绕进去, 之前说A, 现在说B, 后面又说C, 搞不死也差不多了. 4. 项目进入后期的bug修复阶段, 一般不是全员上的, 可能就留几个人来修复bug, 这下好了, 非自己bug的就开始踢皮球了, 一个bug可以被Assigh好多次, 无语. 5. 情绪 – 到了项目后期, 基本上大家都做皮了, 不想做了, 巴不得赶紧结束, 换个环境换个心情, 于是当面对各类bug时, 能有个好心情好情绪实属难得了, 所以请不要再添盐加醋. 6. 情绪后该做的还得好好做的, 不然修正一个bug, 不小心引入另一个bug或者几个bug, 会更抓狂的, 事实是这样的情况很普遍.
这段时间工作中的一些领悟
Author: 小权这段时间忙的一个项目,估计是目前为止忙活的最为郁闷的一个项目.
客户可以说是一家老国企, 我们所接触的客户方面从上到下分三层, 最上面是大头, 其次是部门小头和他们的技术部门小头, 再者是项目的最终用户,部门成员, 大头定方向, 部门小头按部门需求定框架,技术小头呢想到哪说哪, 最后的部门成员根据自身需求定细节.
项目从大小来说不大, 不过从开始做到现在并没有觉得比大项目好做.
首先是接受问题, 部门成员大都上了年纪, 电脑除了工作, 连网页浏览都很少用, Email不会用, 接受能力欠佳, 都喜欢按部就班, 能不改就不改, 能不动就不动, 那怕他们手动去处理.
其次是需求问题, 客户没有需求文档,我们自己整理,结果是大头说个大概, 小头们是想到哪说哪, 今天这个不错, 明天突然又想起那个好, 三天两头有新的需求变动, 部门成员更是从自己的切身利益想方设法让我们做变动.
再者就是我们自己的问题, 一个成长中的团队, 必然有好多东西需要学习和积累.
或许也是因为在这个项目上走了不少弯路, 遇到了一些问题, 近来更是吃到一些前面犯下错误的苦, 才导致这几天一直在考虑自己在此应该注意的一些事情, 以免后面再犯.
1. 开始编程之前, 计划和规划一定要做好, 而不是一股脑的先实现了基本功能, 然后再去这修修那补补, 这样导致的最直接后果就是项目做的越久Bug越多, 以至到了项目结尾了, 数据结构还在变化, 因为没有一个牢固的基础.
2.一个模块的代码最好由一个人完成, 其他人接手也最好将之前的代码吸收掉, 而不是直接拿来就用, 不然出了问题都不知道怎么回事, 到头来还得按照自己的想法来做.
3.需求变更, 这个问题几乎是所有项目都要遇到的, 目前所做的项目更是普遍, 虽然我们也做了一些和客户确认等工作, 但是没有发现有什么效果, 这因人而已, 因客户而已, 在前期将需求调研做到位,只能说尽量去做好.
4.注释, 尽量在自己写的代码里加上注释, 尤其是一些逻辑比较复杂的方法里面, 首先其他人不好理解,再者过些时日, 自己也要从头慢慢体会了.
5.结对编程, 之前一直对这个编程方式不是很感冒, 但是在最近的工作中发现还是值得提倡的, 尤其是在一些自认为比较费时的编程部分, 找人一起写, 这样时效性最好, 不然你在这部分花费的时间绝对是Double以上的, 而且过程可能还很痛苦, 两个人搞, 第一取长补短有交流, 有收获, 第二能大幅保证进度和正确性.
6.引用李笑来老师的一句对自己提醒: "别装, 千万别装, 你也没什么可装的". 时时刻刻谦虚学习.
7.需要统一的东西, 从刚开始遇到就去做统一, 不然等大家都各自弄完了, 标准不一样, 再去做统一工作, 任务就大了.
8.发现别人的代码规范不对, 或者实现有问题, 不是帮他修正, 而是提醒他, 让他自己修正, 不然他不会知道, 而且下次很有可能再犯.
9. 一些公共的事务, 比如服务器管理, 系统部署等大家都要用到的东西, 至少有2个人可以胜任, 不然就一个人管理, 总会有一天, 这个人会因其他事情而耽误团队时间.
10. 这个问题可能稍微严重了点, 那就是变更系统实施方案, 到了项目后期, 如果这个还在变动的话, 那就是前期没做足调研, 这里面的风险不小, 首先否定了一直使用的方案, 团队接受是一个问题, 其次新方案有没有足够的调研,会不会产生其他问题, 最后是客户方面, 需要去说服,来接受新方案.
11. 时间观念, 团队对时间观念的不重视, 必然会导致项目的拖延.
12. 分享和活动, 团队应该定期或者不定期的举行一些技术甚至非技术的知识分享或者其他活动, 一方面有助于团队技术的提高, 另一方面有助于凝聚团队力量.
13. 这个应该是最重要的了, 有了规定, 规范, 团队应该去执行, 定了但不执行或者执行力度不够, 不但前期的投入白费了, 而且影响了后期的项目建设.
14. 备份工作, 说到这个就不得不说下, 我们客户竟然在不通知我们的情况下格盘重装系统, 导致数据丢失, 不过也从另一方面说明我们的备份工作没做好, 没辙, 一些数据得重新录入.