part-time-human-being on Nostr: ...

是既不要写前端、也不要写后端，先把整个项目整理清楚——先做什么、后做什么、不做什么。比如说，你打算写一个类似淘宝的在线销售系统，那么首先绝不能是动手——这在你写大作业时或许是可以的；但只要稍微复杂一点……先别动手，先分析。第一，我这个系统，将来会卖多少种商品？都是什么样的商品？电器？大米？充值卡？服务器租赁？第二，我这个系统，支持多少种支付形式？立即支付？花呗？银行卡？微信？定期扣费？第三，我这个系统，可能有多少用户浏览、多少用户下单、大概需要多少资源？第四，我这个系统，支持不支持退款？是七天无理由还是别的什么形式？用户如何申诉？申诉后整个流程如何？这些必须先搞清楚。比如，我们只卖家具，提供上门安装服务（可选）——那么，商品设计可能就不能像卖点卡一样简单了。再比如，我们只支持支付宝，那就可以相对简单；但如果还要支持更多，那么必须有个地方可以选择支付方式。还有，如果你预计用户有10万，最高并发5000，那么单台服务器可能就够了；否则可能就需要考虑集群、要做。最后，和钱有关，那么你的账目就必须慎之又慎，每一笔交易、每个操作步骤，都要通过日志、数据库记录等方式多重记录，且可以通过这些记录恢复整个交易的任何细节——比如，用户坐在渡船上下单，结果点付费的一瞬间手一滑手机掉水里了：请问，这笔交易是否支付成功了？能否允许用户退款？退款流程如何？以及，如果用户之前是电话号码注册，如何恢复他的账号？把所有这些考量全都记下来、想明白，最后列出要做哪些、不做哪些。这就是不把这个搞出来，那么后面自然是写着写着多一条、写着写着多一块、写着写着……完蛋！给我推倒重来！</p><p data-pid="LNYS_h2T">换句话说，你遇到的困境和“先写前端或者先写后端”没有半点关系，纯粹是你没有做好前期设计。需求搞完了，仍然不能开始开发。这时候，你要找业界已有的框架，看看它们能给你什么功能。比如是否有事务支持、是否有原子性/是否有错误通知/恢复机制——如果没有，你就得自己写。类似的，数据库都提供了哪些功能、哪些功能（比如日志）可以偷懒、直接使用数据库现有设施、如何利用——以及，这种数据库性能够不够？将来万一压力太大要升级，它是否还能继续扩展？还是只能推倒重来？甚至，如果你的需求大到所有现有数据库都无法支持，那么你当然就不能随意和它绑定了，否则将来你将不得不用postgresql去模拟mysql的特殊接口。于是，你就不得不自己搞一个“数据隔离层”，为将来的异构数据库、nosql或者自研的某种数据存储架构做一个兼容（比如著名的odbc）。总之，现在你要做好规划，每个功能如何做、在哪做、和其他模块如何对接，都要落到实处。这就是所谓的总体设计。总体设计之后，你可能需要继续为每个模块的具体实现做好规划。比如说，支付模块，一共要支持多少种支付模式、如何实现、如何呈现、如何选择；当客户退货时，退款“原路返回”如何实现，等等。模块化/细节设计。当然，很多时候，你要做的东西，别人早就做完了所有设计；你要做的，仅仅是填空……举例来说，如果你要写的东西仅仅是一个简单的计算器或者简单的记账软件，那么，现在所有的GUI都是MVC或者它的变种；你只要按照本能往里填写自己的逻辑，程序大概就写不错了。其中，M是model，也就是你的数据组织形式；你要想办法用GUI库提供的容器存放它。V是view，也就是你的数据呈现形式，或者说界面；你要按照预定的绑定规则把model和它联系起来。C是control，也就是你的控制逻辑。在哪个窗口点哪个按钮激活什么逻辑然后把数据做了什么处理、变成了另一个model然后绑给了另一个view，这就是控制逻辑要做的事。你看，很简单，很轻松，对吧。但，要知道，MVC并不是天生就在那放着。一开始业界可以说走了好多年的弯路，搞什么MFC之类，然后MVC模式崛起，从此一统市场。类似的，浏览器-后台这种BS模式其实也和MVC有脱不开的关系；只是分离的更彻底（服务器和客户端是物理分离的）也更不彻底（可以在html里面嵌入代码）而已。之所以有人觉得“个人开发不需要区分前后端”、或者像题主一样，觉得无论先写前端还是先写后端都无从下手，说白了就是没有大项目开发经验或者自己不会做设计——前者只要在MVC里面填空就行了，谁知道什么是设计；后者呢，或者是连在MVC里面填空都不会、或者是要做的项目已经不是简单的“在MVC里面填空”就能搞定的了、但他自己并不知道，自然也就意识不到其实缺的是需求分析和总体设计这些步骤