学以致用啊。反过来就是：用不到的就不学。。。

日拱一卒！！！曰：苟日新，日日新，又日新。

没什么客户端不客户端的，有的只是需求。B 端的市场非常广阔，不要只盯着 C 端。

我刚搞了一个简单的生产管理系统，可以帮工厂主实现生产工艺和工序的管理，顺便实现计件工资的自动计薪。后台不多说，有个非常简单的 APP，就是扫码收件加工和扫码质检验收。后台目前是手工录单，只要对接一个商城，就是互联网新制造。

>许多细节上的问题在没有真正写代码前意识不到，只有在真正开始写代码的时候才会发现

这个不就是「盲人摸象」吗？好好地理解业务，正确定义业务对象，理顺对象之间的关系。不要见着平面就是墙，见着细条就是绳子。

@huijiewei 但 MVC 这种设计模式却是早在 1970 年就出来了，可能比这里所有人的年龄都大呢。。。

法币会贬值都出来了……法币是会贬值，但法币好歹是有财政做担保，有政·府信用做支撑。你发的币有什么？路边捡几个瓶盖么？

订单列表里面的用户名就是个伪需求。业务部门关心具体某个订单是阿猫还是阿狗？

好吧，真有这种需求的话，聚合查询才是正道。

因为真正执行 Console.Write($"{i} ");不是在 for 循环里面，而是在 foreach 迭代里面呀。

难道还有名实相副的旅游景点？？？不如把问题换成：哪些景点值得一去。

好厉害的喵喵(≧∇≦)ﾉ

这个叫类型推断，不是没有数据类型好吧。var a = new String();变量 a 难道就不是 String 类型了？编译器能够从 new String()得到 a 的类型，不需要你特意指定 a 的类型而已。

idea 有个插件，可以把类型隐藏掉，然后显示为 var……

@ebony0319 这种大多是群控搞的，就是有几万台设备，一个设备上有若干账号，然后通过群控工具一下子给你投票。

虽然一个用户有多个 openId，但这些 id 是和公共号一一对应的。你伪造的上哪里去对应？对不上就拿不到用户身份，就没法通过验证。

正在慢慢搞，这个行业大多需要定制化的，很不好搞啊。salesforce 这种很多地方是玩不转的。

@fengchang 我一个人开发也搞微服务。只需要写业务模块的代码就搞定整个项目，完全不需要关心那些和业务无关的功能，包括但不限于：用户、组织机构、权限、账务、支付、字典、报表模板、短信、邮件、消息通知、失败重试等等……

微服务属于那种一次投入终身受益的事。既然已经投入过了，我何苦不接受这个好处非得每个项目自己搞一套呢？用一套现成的他不香吗？

微服务有必要。对付这种需求变更频繁，业务组成复杂的情况，微服务就是最好的解决方案了。但搞微服务，你们要先搞定 devops，要对 ddd 有所理解，然后才能成。

至于高并发，你当他是买一送一的就行了。事实上微服务本身就是个分布式系统。搞定高并发，就是多部署几个实例的事。钱能直接解决的问题也就不是问题了。。。

rts 和 rpg 理论上可以做到全部运算都在服务端，客户端只能下指令。但 fps 只能客户端运算，所以作弊外挂屡禁不绝。

@594duck 现在也一样啊。微服务要做好是需要一些基石的，譬如 DevOps 、DDD 、Spring cloud，还有用户中心、账务中心、消息中心等业务无关的支撑服务。这些都是搞定了，就只剩下写写业务代码了。这样的微服务是很爽的，每个服务都很简单，开发快、上线快，并且易于扩展和维护。

微服务的核心优势就是把系统复杂度从开发转移给了运维，而运维靠 docker 、CI/CD 、k8s 这些技术解决了开发甩过来的复杂度，所以大家都很快乐。但如果你没有能力搞定运维，就会被干趴下，于是微服务对你就不是什么好事了。在服务拆分上面也一样，拆得不好，维护起来比单体更麻烦。

所以，是不是要上微服务，不是看规模大小，也不是看行业，而是看团队有没有这个能力。有能力就上，没能力就不要赶时髦硬上了。