@micean 如果数据结构本身设计没问题，那清理屎山的最好方法就是重写，但是往往屎山是屎到数据结构都被污染了，这就很难恢复了

我从来没听说过劳动仲裁官司需要老板手机号的，请务必弄清楚仲裁是仲裁你和公司之间的问题而不是你和老板之间的问题。楼主不妨先解释一下为啥会需要老板手机号

到目前为止，swagger 这种代码和文档直接关联的做法还是最佳实践，单独写文档的最大问题，就是你一定要分出人力监督写代码的人务必更新文档，尤其在协作开发时这个问题非常突出

数据结构在编程中从来都是放在第一位的，Fred Brooks 在《人月神话》中说：

向我展示你的流程图,而隐藏你的表结构，我依然会非常迷惑；如果给我展示你的表结构，通常我就不需要你的流程图了，因为它们显而易见

你这么理解就明白了，这个类 User 仅仅是你的 A 服务为了映射请求结果而本地自定义的一个映射数据结构，这个映射数据结构和 B 服务可以说是没关系的。所以你当然应该放在 A 这里

你很纠结无非是你觉得这个东西似乎是可以复用的，所以纠结放 A 还是放 B，以及是不是要抽出来做个公共依赖。

我很久以前也很纠结这个东西，但是踩了太多坑以后我的想法就变了，高内聚低耦合本质的意义，就是把和一个服务（组件，应用，包，等等等等）相关的代码全部包在一起，不要和外界有牵扯，你有牵扯就会引发修改时的依赖地狱。


Java 这个语言在诞生的时候不管是发明者，业界，都很非常强调设计模式，设计模式中的一个需求来源就是代码复用，但是这是历史；历史上 Java 被开发出来，是希望写基础设施，来取代 C++的位置，基础设施离业务比较远，需求相对稳定，因此比较容易抽象和复用。但是 Java 发展到今天，形势已经变了，就像 Go 为了满足社区里大量写业务的人的需求，不得不加泛型一样，Java 现在和业务靠的非常近，和基础设施相对距离远，而业务又是复杂多变，这就导致抽象和复用变的困难而价值降低，能适应修改变成了硬需求，这种情况下。IOS 那种把一个程序的依赖全部聚合在包的内部的做法，才是最适宜的。

诚然，不抽象和复用，代价就是代码会膨胀，以及相似代码到处 copy 的问题。但是什么事情没有代价，无非是你选哪头而已。以 Java 目前这种更靠近业务的使用环境，项目初期我是完全不赞成去考虑抽象和复用的，至少要等到业务成型并稳定后，再去抽象和考虑复用进行重构

@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++。目前还是处于早期试用阶段，所以你比较难发现一些大型案例

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

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