标准版本现阶段介绍及以后思路整理

标准版本现阶段介绍及以后思路整理 标准版本现阶段情况及以后思路项目进度?3.5.0遗留问题已经迁移完成?课程制作原型已经评审完，矫永志正在设计界面，预计11月16日出来基本信息界面?本次修改对课程内容页面进行调优，用户操作有所变化未开始的业务?3.5.1版本课程制作详细评审?手机端api接口方法与迁移?标准版后台控制器及模型迁移?资源大平台业务原型设计与调研?统一大后台管理业务原型与设计个人项目计划（还没有和李洁沟通） 一、现在不知道企业培训的计划是什么，先按不做企业培训项目?先把现在有程序迁移完成我想在3.5.1功能提测后，并行把瘦课后台控制器及模型与手机api接口做为一期迁移完。 ?开发周期这块几乎完全后端程序迁移，不需要前端的介入，开发周期应该会很快，和兴龙沟通了一下，8个工作日左右。 ?测试周期因为牵扯到移动端与web端；web端后台的逻辑也没有太复杂的，我们可以指定一人协助测试；移动端今天李洁不在，具体我们在讨论一下，可以安排移动端分别就android与ios指定2个人协助测试；理想情况是12月底整个弄完?基于新的结构可以考虑新业务开发的流程与规范?尝试前后端分离的开发方式 二、现在如果按做企业培训项目?基于现在有结构开发新功能，但新功能按新的结构及框架开发。 ?新功能完成后，把瘦课后台控制器及模型与手机api接口做为一期迁移完。 ?开发周期对于开发，后端程序直接迁移，不需要前端的介入，开发周期应该会很快，和兴龙沟通了一下，8个工作日左右。 ?测试周期web端添加新功能,web端要测试后台和新功能，我们可以指定一人协助测试，但测试周期可能要长点；移动端今天李洁不在，具体我们在讨论一下，可以安排移动端分别就android与ios指定2个人协助测试；?尝试前后端分离的开发方式 三、关于资源平台个人想法1.从程序代码角度现在的问题主要是不太清楚资源平台的定位如果是定位以后可做为单独的系统销售，我推荐重新做一套平台，把账号体系通过uia打通，主要考虑以下几方面优点?降低Sooc代码复杂度，松耦合?资源平台的代码可以完成重写，为后期前后端分离准备?功能单一，后期维护成本不高，业务熟悉也快缺点?不可复用Sooc相关功能（或者说Sooc功能要迁移）如果定位的是Sooc的功能点，那推荐放到后台，就像凯哥说的，添加资源管理后台，前端使用网盘功能进行扩展，主要考虑以下几方面优点?和Sooc功能集成度高，做为Sooc的子功能开发?可复用Sooc的相关功能缺点?Sooc代码复杂度高，耦合有点紧，分拆要有成本?后期维护成本相比要高点，业务功能掺和一块，业务熟悉成本高推荐第二种方式，代码耦合度低，业务功能单一，可维护性更强 四、Sooc以后基础架构考虑1.从不同的平台，不同性质角度 (1).双创平台总分结构，一个总平台（省级平台）+N个子平台（校级平台）；总平台控制主要功能点，比如制作课程，上传素材等，子平台只进行课程学习等数据读取的操作，从这个角度可以考虑省校级融合一套系统，从数据层面划分子平台，按角色不同配置不同的权限，资源平台就融合的系统进行开发优点?从数据层面划分学校，不需要程序部署，减少运维成本?统计信息，资源信息可共用，不需要在采集数据?权限或角色可统一管理，方便配置?代码只需要维护一套就可以，减少维护成本?代码功能可复用缺点?Sooc代码复杂度高，耦合有点紧，分拆要有成本?业务熟悉成本高，功能点多现在有平台情况个人意见?把省级平台功能迁移到校级平台，根据角色划分功能?以校级平台为准，进行数据划分（包括后期新功能点）?开发周期相比要快?但?这样后期代码维护成本高（毕竟新旧都有），有没有的功能都要忽略现在平台情况个人意见?省级与校级平台代码进行重构，对功能进行梳理，合并公共功能，去掉没用功能，优化部分功能?代码重构，按功能点进行划分，部分功能进行封装?规划的时候从数据的角度对子平台进行划分?但?开发周期相比要长推荐咱自己的双创平台可以考虑第二个方案 (2).党政平台与企培平台党政平台党校的资料一般都是保密的多，并且党政机关需求比较固定，但账号体系与其他不太一样，更多偏重的后台数据的统计与分析。 企培平台面向的用户群体本身就很大众，猜测每个用户都不太想与其他平台雷同，可以考虑把核心功能打包，其他功能定制开发，让所有用户使用统一的后台不太现实，至少如果是我，我不会愿意。 这个觉得前后台分离，至少把首页，课程中心等最前端几个页面进行处理，方便定制现在有平台情况个人意见最新版本标准版本迁移完成后可进行二次开发与定制优点?大部分功能已经完成，后期只需求添加新功能就可以缺点?Sooc代码复杂度高，耦合有点紧，分拆要有成本?业务熟悉成本高，功能点多?如果旧版本功能不相同，可能存在新旧功能冲突忽略现在平台情况个人意见?针对标准版本对功能进行梳理，合并公共功能，去掉没用功能，优化部分功能?按功能划分成功能列表，成对应的api?把核心功能打包成公共api,定制的分组定制api?把经常调整的页面进行前后端分离优点?只要逻辑不动，后端程序就可以不调整?提供功能列表，想用哪个功能，前端直接调用就可以?功能相对独立，维护可以不需要全部功能了解?android,ios,web可共用api?api编写可使用java等其他语言，不仅限为PHP缺点?维护api可能会多?现在情况没有做过，可能会遇到坑2.从功能点角度我们现在三大平台，有很多相同的功能点，可能考虑核心功能点，打包成核心代码库（或核心api）,其他功能可以做成定制包（或定制api）现在考虑到要做的事情?功能列表，最好是细到单一独立功能点，相互没有影响-很重要?建立核心代码库或核心api列表?建立定制代码库或定制api列表?前后端分离，android,ios已经分离，主要是web端进行前后端分离总结从长久来看，个人推荐方