谈点技术方面吧!比如大项目要用到缓存什么的

解决方案 »

  1.   

    没有本质的区别,就看开发的人怎么对待。怎么说呢,就是框架的问题,比如一座很高的楼,你就要考虑框架了,否则建不了太高就会跨掉,如果只是一个土房子,随便点都可以搭上去。
    相对于一个应用软件来说一样的道理。
      

  2.   

    设计模式和构架很重要.
    当你编写千千万万小型应用的时候,是不可能深会体会得到做大型项目的痛苦的.
    1.模块繁多,彼此之间的联系千丝万缕;
    2.代码臃肿,调试起来非常困难;
    3.业务逻辑与执行效率永远都矛盾地存在;
    4.灵活性与健壮性极度不协调;
    5.进程通讯\多线程异步和同步\资源共享\访问越界和死锁\数据完整性\抽象接口\系统安全等等,都是你头痛的来源;
    6.经过结构和算法多次改善后,潜意识里还是会希望通过升级硬件达到期望的运行速度;建议:
    在实际项目进行之前先找到一个合理的模式(构架)来满足当前项目的要求;
    在做需求分析的时候一定要找到多种构架方案以供项目组讨论时作出选择;
    让有经验的人员担当构架师,至少是做过很多小型应用的人员来做;
    统一接口标准,以免成员之间产生多次协调仍然没有结果的现象;
    项目组研发人员的安排最好采用纵向部署,即分层(如:业务层和数据层等)开发而非模块(如:权限控制模块和数据监测模块等)开发;
    规范你们项目组的测试人员的测试行为,培养开拓发散的思维;
    如果可能,要定期举行项目成员之间的研讨会,举办业务知识和研发技术的培训课程,让你的团队渴望创新,永远保存激情.
      

  3.   

    何为大何为小?复杂度?负载?范围?费用?大小本是相对的...没有绝对的标准...没有标准的东西无法讨论...