@linhongye Electron 本质是个浏览器，里面跑的东西就是 web 前端，vscode 比较狠的地方在于它的 web 部分是用原生 JS 写的，没有使用任何 UI 库之类的东西，而且使用了很多“魔法”进行优化。这是绝大部分 Electron 开发者压根做不到的事情，他们基本都需要借用第三方 UI 库，也不可能进行“魔法”级的优化。就算是这样，vscode 的性能也只能说在 Electron 开发的程序中算非常优秀，和那些用原生技术开发的编辑器比比性能照样会败下阵来。

@sheep3 凡是用过 PC 原生程序的人，都不会对 Electron 这种动不动占上百 M 内存的软件有任何好感，更别说基于 Web 的 UI 目前在性能上差原生远的很，也就是新生代觉得可以接受，老 PC 用户根本无法接受这种性能。

另外你也别拿 Vscode 和 idea 来说事，vscode 从来就不是以性能出众的（虽然在它用的技术这个领域里它性能已经算出众了）。和一票老牌的原生编辑器比 vscode 的性能一比遭，无非是作为新生编辑器社区够大，生态够大，所以性能不出众的问题大家也就忍了而已。至于 IDEA，我就一句话，我不得不用 IDEA 作为生产力工具，是因为 java 的 IDE 基本都是拿 Java 写的，大家性能差不多的烂，IDEA 功能还算可以，也只能捏着鼻子用了。

我们只是没办法，不得不忍受这种非原生程序的性能，不是我们愿意我们喜欢，吹这些非原生程序的时候你可以说他们功能好用，社区庞大，但是唯独别吹什么性能。把 PC 当生产力工具的领域的用户太多都是原生时代过来的老油条，原生和非原生之间的性能差距远没到让人感觉不出来的时候，说这些非原生程序性能不行，没有任何错误

@cubecube 空项目有啥用呢，你加个最基础的 web 依赖试试

这还要争多久啊？

喜欢 ORM 的思路，选 JPA 。

喜欢 SQL 帮助工具，选 Mybatis(的各种增强版，抱歉，原版 Mybatis 我也用不下去，普通的 OLTP 查询也要写 sql 我受不了)。

实际现在真正流行的东西，是 OLTP 的 ORM 和自定义查询的 SQL 帮助工具的结合体。Mybatis 的几个增强工具其实就是这个思路，这也是为啥这东西流行的原因。觉得[Spring Data JPA 这么好用]。纯粹是你还没遇到能戳到它弱点的需求而已，被戳一次你就再也不会想用 Spring Data JPA

@bnm965321 作者用词可不是瑕疵，用的是“错误”和“困境”。你觉得你比作者更理解 npm ？

我也不想和你争论这个，没意义，我们互相不可能说服对方的，我能理解有些 noder 对 node 唯一一个包管理器 npm 的维护情绪。但我本身是多门语言一路玩过来的，我更喜欢批判而不是维护。我也不打算去说服别人，你的存在恰好证明了我的观点，前端社区对什么是好，什么不好，根本不统一，社区意见都不统一，工具链发展自然是左右摇摆的探索期

@joesonw
@des
请教，如何解决数据访问权问题，授权和鉴权往往只能解决角色(你是谁)和一般性授权问题（你能访问这个接口吗），但是实际业务中，往往要解决“你访问的数据是属于你的吗”这个问题，这个问题严格说也是鉴权，但是是业务强相关的。业务强相关的东西，网关做不了

去尝试写一下 CSS 和 JS 。如果你自我感觉 CSS 写的比 JS 还溜，甚至能轻松的修改别人的 CSS 。你就更适合前端，反之就是后端。

CSS 是测试前端的试金石，甚至可以说，现在大部分正在从事前端工作的人，在 CSS 这块都是不合格的。证据就是他们写出来的 CSS 没法让别人改，别人写的 CSS 他们也搞不明白，解决别人写的 CSS 的布局问题的方式是拿自己熟悉的方式自己重写。。。虽然 CSS 自从加入了 flex 后，以及现在 web 开发多是在开发 App UI 而不是复杂排版页，导致对 CSS 的要求大大降低了。CSS 仍然是测试前端的试金石，因为这东西代表着另外一个领域；和普通的顺序式编程思路完全不同

工程化的思维是近 10 年才引入前端的，后端则早的多了，至少人月神话那个时候就开始了。前端的构建工具不够好用的根源还是时间太短，坑没踩完。不说别的就光一个 npm 设计问题，连作者都觉得设计失败的玩意还是很多人说 npm 设计的好。。。再过个 10 年，等社区对什么是真正的好，达成共识了，估计前端工程化就成熟了，现在内部意见都不统一，你觉得好的东西我觉得是屎，这种环境下工具链不可能让人满意

需要性能的岗位，看能否取代 C++。目前还是处于早期试用阶段，所以你比较难发现一些大型案例

分布式关系数据库目前还处于技术完善期，其实后端业务说来说去，除了某些对算法要求极高的领域，基本都是卡在数据库这一块了，数据库作为后端存储状态的关键点，在海量数据的这个时代是一个 [薄弱点] ，一旦这个点被攻破，可认为后端编程就是无脑的

电车目前从技术上仍然处于完善期，但是油车现在几乎在所有的地方都限上牌。汽车目前处于技术换代时期，最好的建议就是不要买。等等党永不会输

快到不惑而没有 200w 存款的人一大把，楼主是不是在凡尔赛？

@charlie21 我已经非常明确的描述了我的观点，我并不抵触严谨代码结构。我只是强调应该根据不同的的情况选择不同的方式，我非常开心能够不用和你这种永远停留在自己的舒适区的人一起共事，之前也遇到过这样，号称“不按他的规范来就开除”，然后我就看着他有一天就撞到了他的规范无法处理，然后必须妥协的时候，最后此人的选择就是一走了之。。。

在 Controller 里写数据库处理逻辑非常常见，很早就有技术文章描述过这种“事务脚本编程”方式的优劣，如果你看过别的语言的 mvc 框架，也能看到这样的实现，只是你自己不可接受而已，随便你怎么想，我来这里不是和人吵架的，而是和人交流，我不排斥任何处理方式，只要他能更好的解决问题就行。

@alamaya
问题是你到底是怎么考虑代码复用的？

哦，看到一段操作数据库的代码，就不能放在 Controller 里？就得写个 service 装起来，搞不好这个 service 还得先是一个接口，然后做出一个 Impl 实现类来？是这个意思吗？

考虑复用难道不是先考虑一下有没有复用的可能性吗？当根本就没有复用的可能性时，就像我前面说的，业务代码几轮拆分后都是高内聚的，哪有让你复用的机会？也要“复用”吗？

如果你一开始就已经想到了这段代码在业务上就是需要复用的，甚至这个需求就在眼前，那我万分支持你把立刻把这段代码抽出来变成一个 service，给人复用。如果你一开始根本想不出来要在哪里复用，那为什么要复用？这不是过度设计又是什么呢？就像很多项目写一堆直到项目死掉都不会改成实现的接口，美其名曰 [规范] 。。。

退一万步讲，你到了遇到有需要复用的那一天，再把 Controller 里的代码抽出来变成一个复用的 service，这很费事吗？

我见了太多的人，都是嘴上空谈说 [复用] ，我直接问他们关于眼前项目，你觉得这个位置的代码在哪里可能会复用？鲜有答上来的，他们大部分也估不到项目在发展中会遇到什么。只不过是看别人是这么干的，或者说按所谓的规范应该这么干的。。。

除非你已经想到需要的地方，那么再动手，不要过早动手，优先完成业务。这是我的法则。就目前的实践经验看，和我配合的人都挺喜欢的，没觉得我的代码就是屎山。当然有人不认同我能理解，毕竟张口闭口设计规范的人非常之多，谢欢在项目里写一堆到死也不会发生变化的接口的人更不少

@ebony0319 ORM 的方向如果是对的，它就不会遇到复杂场景必须回到 SQL 这种尴尬的问题。本质是对象模型并不能如当初的人们估算的那样取代关系模型，只要关系模型自身不倒，ORM 就始终处于尴尬的位置

@hutoer 为什么要在初期就考虑代码复用？为啥不能遇到能复用的时候，再去把代码抽成 service ？为啥一定在初期搞这种过度设计？

@ipwx Java 的线程模型是 1 比 1 换成内核线程的模型。这个东西在经典时代是足够的，但是在现在就未必了，其实 Java 一直在折腾新的携程模型。

另外，我的本意是，部署一个 Java 项目(线程)，哪怕是比较小的项目，拖着一个巨大的虚拟机和基本函数库，也造成其启动内存占用偏大，和启动速度太慢