第二种提取出来的是 “<div>你好</div>” ，并不是要求的 “你好”，这种行为对应一个典型的名词：跑题。

第一，就算是单一用户的需求也不一定能成为最终产品需求，多数用户而非单一用户的需求就更不一定成为最终产品需求，你这个“豆瓣女文青多豆瓣就该照顾女用户”的逻辑，在名眼人眼里属于神逻辑。

第二，请参考电信诈骗，谁都知道通过电信公司是最容易阻断电信诈骗的，但谁也都知道电信公司是不会自断财路的。

对人冲和对事冲是不一样的，看楼主这描述是对事冲，那么恭喜楼主：良药苦口、忠言逆耳。当然楼主也要对事不对人，抱着学习的态度做好事，事后两不相见。

实际上，对新员工笑口常开的人，不是对你有想法就是笑里藏着刀。

@zqx 前段是面向 UI 的，后端是面向服务的，这俩在面向用户上就有天大的差别，在设计和代码层面自然而然就是两种东西。以前让一个人搞那是没得选，现在能选了再坚持一个人前后端通吃，那就说不过去了。

压缩合并是会丢失历史记录的，你这个 branchNew 压缩合并一次，就丢失它背后 master 上的 PR 记录，经过这么多次压缩合并，已经跟 master 没有任何关系了。

时间太长，完全没救了。你只能删除了 branchNew 分支然后通过本地文件比较再建一个新的分支来折中修补，这会丢失之前 branchNew 分支自身的所有历史记录。

压缩合并跟 SVN 提交是一样的，是单分支新提交而不是对分支合并，压根不存在冲突问题（请注意 SVN 的冲突发生在更新时而不是提交时），自然会产生代码覆盖问题。

压缩合并是处于兼容原因才留下的合并方式，非兼容原因应当禁止使用。要保持线性提交历史，可以采用变基合并。

从常理上来说，CTO 要比底层技术换得勤，当前的框架并不一定是当前的 CTO 选型的。从 Java 开发经验上来说，Java 干到 5 年还不会多语言开发的，一定是混子。

学艺不精就少说点，更不要只看了标题不看细节就去说

实例的生成又实现类决定；哪怕是自动注入，使用哪种实例的权利和责任，仍然归使用方； IOC 容器只是负责管理注入，屁权利没有，更像个擦屁股的。

就像张三、李四吃饭一样，看起来是类似的但却是实在在是两码事。

绝对的不复制粘贴代码，是过度模式，楼主贴的代码就是最合适的 2 处理方式。

并不是所有类似代码都能提取成公共处理。从 A 表中提取 5 个字段生成 A2 对象、从 B 表中提取 5 个字段生成 B2 对象，这两个操作

想多了，这是工信部牵头的，前几个工信部牵头的东西，之一是统一推送。

你首先的区分应用编程还是数据库编程。国内不管哪种语言、用不用 ORM 、用全 ORM 还是用半 ORM，都是应用编程，主编程语言是高级编码语言而不是 SQL，这种情况下物理外键是负担（但逻辑外键仍然存在）。而国外，既有应用编程，也有数据库编程，你用外键作为关键字搜索，结果自然倾向于数据库编程。

@Kakarrot OneNote 、OneDrive 同步都不需要梯子，微软国内有服务器速度也有保证。但是 PC 版同步机制本身有问题经常容易卡住

这种结构不稳定的数据格式，是符合 JSON 规范和接口数据规范的，但不符合面向对象数据格式，建议不要做反序列化，直接当成 JSON 读取，用 jsonpath 的形式

你这个不管对应到类还是对应到关系数据，都是两种数据类型，这就不要再想反序列化成一个类了。

然后，PC 非 UWP 版本的客户端，独有一个定时同步功能，需要自己修改同步配置。无论是否设置定时同步，PC 端都有“立即同步”功能。


最后，同步工作方式下的 OneNote，是个 SaaS，即云软件，它的服务器是云（但是由 OneDrive 提供存储配额），客户端就是各平台的程序或 APP 。历史上 OneNote 是 Office 套件的一部分，是可以像 Word 那样纯本地工作的，目前 PC 端还可以这样干，后面不好说，微软已经将好多原来既能本地又能云的软件搞成纯云了。

根据我的使用经验，从本地向服务器的向上同步，是有修改就同步，从服务器到本地的同步，不太确定，有可能是推送拉取同步，也有可能是定时拉取同步。

啥是开飞机？

我只知道 win32 应用的开发语言和框架很多，剩下的不清楚。当然 win32 应用的主流编程语言还是 C ＋＋和.NET 系。