关于项目结构的问题

李若炎
  • 1.4k

在一些小的初创型公司里面,一般一个前端工作人员要维护编写多个业务方向的代码。包括

  1. 活动宣传页(主要CSS3, canvas)

  2. mobile主战/分享页 (主要webkit内核, flexbox,微信sdk)

  3. pc主页 (主要考虑IE浏览器兼容性,基本布局)

  4. 后台系统 (主要考虑快速开发,快速成型)

一般来说在小公司这些东西可能是一个人在编写并管理的,那应该怎样去考虑整个项目结构呢。

按照常理来说,应该没个项目单独去管理代码,但是项目之间也是有可能会用到同样的模块的,样式也有可能会用到同样的一份。需要去抽离这一部分可能公共的代码?

特别混乱,求指点迷津

回复
阅读 2.4k
3 个回答

其实,你上面描述的,有的公司就是干这个的,专门帮人做这方面的活动。其实HTML 5刚开始的时候,我也考虑过,尝试做这方面的活动,可惜我设计不行,所以最终搁置。

之所以,提到这个-有专门的公司处理这个。想说的是,一般的公司会涉及到这部分内容,但是业务分离,肯定不会像他们那样专业。

还有就是,抛开具体业务来说项目结构(个人理解为架构),都是不合理的,所以,要根据自己公司的业务来。

其实,你已经梳理出来了几个部分。
比如公司有A业务,B业务,A业务会涉及到这样的活动,B业务也会涉及到这样的流程。可以考虑将这样的活动抽离为C业务,专门处理活动。

问题就变成了,如何针对C业务具体处理!
主要包含,两个部分,前端和后端,前端部分抽离相对容易一些,无非是一些常用的资源文件放在一起而已(包括抽象常见的活动处理脚本)。
后端的抽离,我想让题主困惑的是,涉及到A和B的业务逻辑,我是放在A呢,还是B呢,还是C?
我个人的观点是,如果和A,B依赖性很强,比如需要调用其中的相关模块,那么处理逻辑就最好放在对应的业务中,在C中调用A,B提供的接口就可以了。
C还是偏向于活动相关的处理,而非具体业务的处理。当然,在处理活动的过程中,也会涉及到C自己的业务。

比如,经常会处理一些抽奖的活动,那么涉及到的这部分业务与A和B的关系都不到,很可能部分数据是来自于A或者B,但是具体活动的业务还是在C完成的。

你提到的第4点,后台系统,这部分最好放在最后来处理,如果公司类似的活动的个性化不是很强,而且发布活动比较频繁,这部分相对来说还好处理,也有必要。如果公司的活动个性化比较强,今天是这样,明天是那样,你会发现还不如没有这部分。
其实,目前很多公司提供的在线制作活动的部分,其实就类似于你这里的后台系统。你最好去看几个常用的,这里就不推荐了。

如果你发现,他们在线制作的活动,不能满足贵公司的需求,那么你得问自己我们公司是否有这个时间和经历来处理这部分内容(别人是专业的,我们是业余的)。

处理这部分的时候,已经不是你一个人的事了,最好同你们的活动发起方,UI设计之类的交流一下,还有就是到网上更多的了解这方面。

表示经验不丰富, 我的话会优先考虑几个方面的问题,

  • 重用的代码是否足够明确, 明确到可以拆分出来

  • 模块化方案是否强大, 保证拆分模块之后不会遇到奇怪的问题

  • 未来的业务能否因为拆分模块而获益

实际项目当中判断拆分模块是否合适有点难, 建议还是根据项目开发需要自己判断.

井上心葉
  • -5
新手上路,请多包涵

先抽象出实体,然后再根据实体和业务划分大模块,之后再根据单一职责原则等七项原则设计合理的业务层,单一职责很重要,最后controller层是按视图设计还是按restful设计就随意了,理清业务逻辑,根据单一职责原则设计业务层很重要,当然实体设计的好坏也十分重要,以上是我做后端的浅薄经验…

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏