本人自学，最近做了个人项目，为期两个月，是个 b2c 商城，技术栈是 sass、jquery、thinkphp，经过一套摸索下来，勉强能运行，项目大部分东西是自己瞎想出来的，没怎么参考到前人经验，因为找不到，我发现自己对项目开发流程等没什么概念，这些似乎是属于架构的东西？想查些资料学习，但这方面的资料属实难找（当然也可能是我查的方法不对），因此提问，下面是几个具体的问题，可能会不定期更新。

一、项目开发流程的基本组成部分有哪些？目前我的认知里是需求分析、设计整体业务流程、设计数据模型、代码实现。可能用词不太标准，「设计整体业务流程」、「设计数据模型」是我自己瞎想的叫法。

二、如何系统的、有步骤的确定一个项目的业务流程？

三、如何在初期确定项目整体的运作模型？即对项目整体的前期设计？这是个很难的问题，需要考虑的很全面，很容易出纰漏，因为这个「考虑」总是建立在没做的基础上，要在没做时就考虑到整个项目的方方面面边边角角，既要想到「该有什么」，又要想到「该如何组合、协调」它们，还要想到「某个部位具体的技术细节」，甚至想到如果以后要加一些东西，该怎么预留位置，要做好这些，真的好难。

（新增）四、如何设计数据模型？或者说怎么设计数据表？似乎很大程度上是基于经验来设计的，目前我认为，根据前端的功能需要来设计数据模型比较好，也就是为实现功能而设计尽可能方便的数据模型。

关于第三个问题，经过这次项目的思考总结后，我有点见解，我发现让前期设计与前端页面编写同步进行是个不错的选择，因为只编写页面模版并不需要多少数据支撑，想改也是很快的，而页面模版能比较明确的反映出需求到底有哪些，需要什么样的数据模型，我觉得这对前期设计的帮助还是很大的，这是我这次做完后才想到的方法，目前还未实践过。

下面是我在本次项目初期时画的一些脑图，制作过程几乎完全基于个人瞎猜，欢迎大佬评论指正，由于设计问题，其中退货、优惠券、折扣部分最终并未完成：

这些东西是基于经验来的的没错。你所需要做的就是，每当你有一个架构想法的时候，你就把它做出来，总结一下为什么吃了屎，久而久之你的方法就成熟了。

一个成功的架构，要易于维护，易于扩展，还要能经得住傻逼同事的折腾。

谢邀。

一套系统的建立，大公司和小公司可以说是大相径庭。

大公司由于更加注重流程，所以很多人自嘲Java，.Net各种代码都不写，只写PPT和Word，从而产生了一个岗位叫PPT项目经理。没办法，CMMI要啊，这东西对流程、文档看的特别重。对于大公司而言，不一定需要最前沿的科技，最花哨的写法，但是要最全的文档，最严谨的流程。

小公司则不然，更加注重的是结果。文档林志玲，产品郭晶晶（没贬低的意思，就是。。顺口？），用户不买单，对于小公司来说就是致命打击。

目标不同，过程不同。

还有你所提到的框架，任何一家科技公司，可能都或多或少有几套自己用著最顺手的框架。而一个合理的框架应该包括以下几个要素

  • 顺手，如果一家公司的技术栈偏Java，那如果非逼著程序员去用其他语言框架赶工期，没必要。
  • 不应过分复杂，码农界有一个不太好的风气，就是互相攀比谁的代码更让人看不懂（或者说是谁的代码看起来更酷炫），实则这一风气并不值得赞扬。这就像做一个汉堡，并不一定非要在两片面饼（是这么称呼么。。）之间加8层肉，7层蔬菜，还加上各种香料，这好吃么？我觉得一层鸡腿肉，一层蔬菜就已经很可口了。
  • 尽量选择有一定用户基础的框架，这样遇到问题也能比较方便的解决。
  • 做框架是在做减法，如果使用了框架使得开发过程更加复杂，那框架的意义就没了。
  • 层级架构明显，比如.Net做WebAPI的项目经常会拆成Controller，BLL，DAL，Model，Converter，DB，DataEntity等几层，每一层都各司其职，用起来非常清晰。
  • 并不一定别人觉得好的框架就适合你，也并不一定非要去追随别人的脚步选择一些GitHub上的高星产品。适合的才是最好的。

归根结底一句话，用框架的目的是让代码规范，开发流畅，而不是炫技。

对于你的一些其他问题，我也有部分个人见解，是否一定要在业务逻辑想的特别清楚的情况下再开始动手写代码？

我并不敢苟同，因为无论怎么想，总归会在制作的过程中遇到问题。我更建议在对大局有一个基本的认知以后，就可以先从前端开始制作。

不要先建立资料库！

不要先建立资料库！

不要先建立资料库！

对于一个需求还并不非常明朗的小项目而言，首先要做的是界面上的内容足够用。比如你现在做的商城，可能先照著淘宝的页面画了个类似的，有一些初始的数据栏位，在你做的过程中会慢慢的发现其他问题。这时候会发觉，之前的资料库结构可能不太对，需要增加栏位，而栏位增加在哪，直接增加表栏位还是加个新的表，等等问题都会在你踩坑的过程中一一迎刃而解。

我作为独立开发者，对于一个新项目，也会运用类似的思考方式。

  • 我要做什么
  • 做了干什么用
  • 大概什么样子
  • 编造些假数据
  • 页面基本敲定，后台配合资料库一起开发

个人深刻的感受到，对于项目而言，怕不思考，但是也怕过度思考。该出手时就出手，写，才能发现问题，想，只能发现表面问题。

技术栈应该如何选择

看你做这个练手项目的真实目的了，如果只是为了练手，那么jQuery，thinkPHP之类的没有问题，练习一下挺好的。但是如果你的目的是最后可以上线，或者说稍作修改可以上线，那么技术栈的选择就有点问题了。毕竟当今世界，网页端的流量已经很少了，可以尝试学学做App，或者小程序之类，毕竟手机才是当今市场最大的一块乳酪。

首先不得不赞一下，做的不错。图设计的都挺漂亮的。

弱弱的问一下，有没有sku的设计？

开发流程嘛，每个公司都不太一样，都会根据公司的特点进行调整。

总体来说和你说的也差不多。

说一下数据结构设计的事。

理想情况下，注意是理想情况：

1,需求分析

2,功能设计

然后这里出现分支，前后端同时进行。

前端就是你说的那些。

后端主要是模型设计，或者是资料库设计，这个看是面向资料库还是面向对象。

总之，资料库设计的时候，关注的是需求和关系型资料库的特点，尽量不要去想前端的需求。

这个要求就有点高了。

同理，前端设计的时候，也是想著需求和前端的特点。

然后呢，重点来了，前后端怎么结合？介面怎么设计？

其实这个才是ORM的核心内容！

两端都独立设计好了之后，再考虑如何对应。

这么做的好处是，可以把各种都特色发挥出来

缺点就是，难度有点高，有时候配不起来，双方都得做出点让步和妥协才行。

所以简单的开发方式就是，前端往后推，或者后端往前推。

其实说了这些吧，其实都没啥关系用。

还是要开你以后的打算。

如果要去公司打工的话，那就看公司的规定了，公司说怎么开发那就是怎么开发。

除非公司让你负责制定开发流程。

这个也就是看你自己的定位，你想负责哪个部分。

大公司，每个环境都设计好了，去了就是螺丝钉，然后一点一点接触更大的范围，如果有可能的话。

小公司嘛，就复杂了，各种情况都有。

如果你想自己创业，那么就要下功夫去研究了。

如果有兴趣的话，可以透露一下你的定位和想法。

你很厉害，超过了很多人了。

很多公司很多情况下，前期设计的再好，天天变都是可能的

唯有不变的是变化本身。

ui最恶心，由ui驱动需求和由数据驱动需求，最后互相妥协的更恶心。只要能插上话的，都会来说一说ui的事。

标准流程也有，产品经理先搞个大概，做出原型，然后前后端一起看看，修改，定板，评估时间，ui设计，前端评估。开搞。中途有少量临时变更，讨论，改。然后做得差不多了，测试进来，需求迭代。

以上是比较好的流程。实际中乱的一笔。今天这个想法，明天那个想法的是常态。队友靠不靠谱，公司靠不靠谱很重要。

大多数人在一个轮回又一个轮回中罢了

具体的业务，商城是个很复杂的东西，支付，订单，售后，购物车，这些都是比较难的，想清楚一个整个流程，并且这个方案是好多种的哪一种，比如售后，这个穿插在之前还是订单之后，这个售后流程，还有退货退款的各种情况。财务状态和订单状态的各种情况。这个业务不是一个人能想清楚的。都是经历很多次的磨合才能想清楚，到底有多少种售后模型，为什么选了其中的这种。财务状态和订单状态和售后状态能对好都不容易（实际代码中）了

开发流程中，很多的时间其实是，搞清楚人真正想要什么的过程

开始这样写挺不错了，业务流程设计中规中矩。但是不属于架构设计的内容。架构设计首先是一种编码规范，规定业务代码的编码方式和提高代码水平以及一致性。许多人把业务理解成架构，这是不对的，业务驱动架构，架构为业务服务，架构高等论只是对自身的狂妄自大而已。

架构包含的内容有，资料库访问，缓存机制，编程语言选择，设计模式（MVC），使用示例，测试示例，编码规范。单体架构大概就是这样。分散式，微服务跟复杂些。

ORM能不用就不用了，自己写一个资料库访问类就好。缓存机制用不好全是坑，做好细节，哪里用怎么用要明白。语言最好是静态语言，强制类型，对大家都好。示例编写的好坏决定了业务编码的水平高低，最好是业务代码可以直接拷贝的的代码，改改就能用的，新人上手块不易出错，代码质量有保证。

不要拿现成的Spring，beego等待架构直接写业务，根据自身业务封装一层

不错，但是，你的这个能力会在进入标准化流程后丧失。标准的目的是把人变成螺丝钉，让一个组织可以做到只要保障了过程就能保障结果，有著大量的额外工作仅仅是为了上层可以观察。至于螺丝钉的感受嘛，不好使就再换一个呗。

尝试简单回答一下问题：

一、项目开发流程的基本组成部分有哪些？目前我的认知里是需求分析、设计整体业务流程、设计数据模型、代码实现。可能用词不太标准，「设计整体业务流程」、「设计数据模型」是我自己瞎想的叫法。

开发流程大致就是： 需求、设计、开发、测试，具体执行又分瀑布、迭代（也有叫螺旋的），经常说的敏捷开发可以算在迭代里。每个环节展开还有很多细节，感兴趣可以参考CMMI或者RUP的文档。

二、如何系统的、有步骤的确定一个项目的业务流程？

目前非专业人士用的最多的就是流程图，专业一点的话就是用例法、用户故事地图等方式。这个展开说篇幅就长了。

三、如何在初期确定项目整体的运作模型？即对项目整体的前期设计？这是个很难的问题，需要考虑的很全面，很容易出纰漏，因为这个「考虑」总是建立在没做的基础上，要在没做时就考虑到整个项目的方方面面边边角角，既要想到「该有什么」，又要想到「该如何组合、协调」它们，还要想到「某个部位具体的技术细节」，甚至想到如果以后要加一些东西，该怎么预留位置，要做好这些，真的好难。

考虑问题的思路还是从大到小，逐步分解。先确定项目的范围和边界（用例法可以做到），然后逐步分解、细化，这样就不容易遗漏。至于以后要加的东西，现在不要考虑太多，不要过度设计。

（新增）四、如何设计数据模型？或者说怎么设计数据表？似乎很大程度上是基于经验来设计的，目前我认为，根据前端的功能需要来设计数据模型比较好，也就是为实现功能而设计尽可能方便的数据模型。

数据模型的设计要看项目本身的复杂程度，如果项目比较简单，资料库设计只需要画ER图，遵循三范式即可，业务复杂的情况可以用DDD的领域模型思路设计。至于你感觉的根据前端功能设计数据模型，一般会叫此类数据模型为DTO或者VO，跟后台的数据结构不一定一致。

总体来说，架构设计还是有很多现成的方法论可以遵循的，建议你还是多看一些相关的书籍。

可以了解下CMMI，没有定义具体的流程，但是定义了不同成熟度级别需要覆盖的内容。

另外，你的问题描述很多是架构设计的范畴，和项目流程无关。

永生。

也就是说，每个层面，都由一些一旦设定永远不需要改动的东西支撑。

越多越成熟。

你去网上可以搜索到的。

我们公司用的瀑布流加敏捷。

你是要做项目管理架构还是项目架构。

如果是项目的技术架构，要考虑的其实比较多。命名规范，迭代管理，结构管理，架构模式不同的技术可以用不同的架构方式。MVC,MVP,MVVM。多人开发一定要考虑好结构，减少代码冲突的可能性。

其实我觉得架构设计更多的是关注缓存，关注扩展，关注业务建模。

至于什么前端页面，这些其实都不重要，他们天天变化，你要是变化 还要兼容老的业务，所以我从不关心产品经理的需求，我只关心他究竟在说什么，大部分人没办法形成业务闭环。

够学术！

计算机或者软体工程领域，是建立在成熟的基础理论与广泛实践基础上的。建议去广泛系统的进行学习吧。尤其，不能限于一两门编程语言，也不能局限与一两个应用框架。另外，在掌握一两门主流语言之后，争取进入主流的工程领域去一边学习一边实践吧。

另外，最简单去GitHub看看，多一些了解开源世界的宏大与强大。

最浪费时间的，就是仅仅依靠自己开脑洞去探索。

实话实说，不喜勿恼；如有不妥，就当瞎说。

祝发展越来越好！

推荐阅读：
相关文章