另外，想换节点可以趁早换，或者 at livid 处理，换节点重发一样的帖子不好

你要和 redux vuex 抢饭碗，或者是想整合一起用，凭啥，建议在 readme 第一屏内显著写明白

另外点进去看了看，出 promise 不 return 造成 uncaught reject 的 sample code 不敢恭维

暂时先不 star 了

我现在基本形成了本能反应：看到这种开头一张图，内容里面大量副标题和加粗的公众号文笔 就自动判定成垃圾水文，速读垂直扫几眼直接拉到底，看到一排链接，嗯，枪毙，再见

SAP?

想去互联网公司趁早，等你简历上有了两家三家非互联网的公司，再跳阻力就大了，可以再找找

不想去互联网公司的话，autodesk 风险小，另一家你得自己去调研确认是有核心竞争力而不是风口上的裸泳公司

对于高端 /稀缺的职位来说，一家公司在招聘换句话说有职位空缺这件事本身就是某种意义上的商业秘密，猎头的一个作用就是保护客户公司的商业秘密，尽量避免无谓的信息泄露

当然也有的是虚张声势，类比中国有 5 所 top3 大学，10 所 top5

嗯嗯，算力分布好做，数据分布难做，事务分布 (还要自动地，业务无关地) 那是地狱难度了

window tidy / mosaic

@RoyGo "以上"

想到哪写到哪儿

1. “时间预估” 对于外包和公司自有项目的意义和含义是不一样的。前者是真的雷打不动的 deadline，而且基本不能以客户需求变更或其他意外为借口来打破，但后者相反，有合理的问题发生 delay 是正常的，但代价是绝对不能用乘法（至少我认为这属于不负责任） 个人没做过外包所以对外包的描述是瞎猜的，下面所有的看法都是基于公司自有项目

2. 时间预估之所以叫预估就是因为不准。实际上每个任务的完成时间都不是一个数字，而是一个概率模型（ 30% 半天做完 40% 一天做完 25%两天做完 5% 需要更长时间）而你给出的那个实际的数字，一般应当是 80%左右能做完，10%左右稍微超一些时间 or 加班 能做完的一个预期时间

3. 一份好的时间预估中，任何一天以上的任务都是不被接受，需要进一步拆分的

4. 以月为单位的项目当中，用几天的时间来做技术文档，并最终给出详细的时间预估是合理且必要的，这样的项目中表结构都没有定，技术文档都没有，你就给我时间预估我是不信的

5. 如果你有技术 leader，可以和他直接沟通你的困难，包括技术的选型和时间预估的困难，另外你的时间预估必须和你的搭档核对，并且写清楚你们所有的配合的时间点，什么时候定公共的数据结构、你们内部的接口形式和字段，什么时候你们两部分可以联调等

6. 题外话，要不是看到下面的数字列表还算整齐，我看到第一行其实就有关窗口的冲动。重复 3 遍想表达什么？你用什么语言和项目时间预估也关系不大。 包括你后面 7 里面写的一堆，你以为会呛你一句风凉话让你离职的人会仔细看你写的那么多东西？或者是看了以后他们就会认真给建议了？ 论坛里面的一些信息噪音当作没看到就好（ V2EX 甚至有 block 功能），不要和他们战斗，更不要这样因为他们影响其他人的阅读体验，要不是有数字列表方便我扫一眼就跳过，我可能就跑了

没去过大厂选大厂，更何况是营收部门

去过大厂还问出这样的问题的话…那还是蹲在大厂混日子吧

建立自己的知识体系

“建立自己的” - 不是去搜一下看一个脑图完事儿，也不是死记硬背，而是真正自己理解的，即使忘了也能从头在白板上稀里哗啦画出差不多的知识体系
“体系” - 不是线性的清单，而是有组织的，从上级概念慢慢具体到知识点的体系

别人叫你看源码你就去看源码是没有用的，也大概率看不懂，就算看懂了你还是想问“我看懂了 vue 的代码，迷茫了，不知道该学什么”，不如说你可能都无法判断自己是否看懂了

技术水平还是其次，最要命的是心智根本不成熟

比较合理的是要么赔偿立刻走，要么带薪假+到时走（让你在职找工作），可以谈的就是钱多少或时间长短了，HR 的任务也是稳妥地送你走，所以合理沟通提出自己的诉求就行了

注意就算公司 /HR 乱搞也不要意气用事搞旷工啊，闹事啊什么的，只会给对方辞退的合理借口，不放心的话注意收集自己按照公司要求完成工作的证据，真出问题了咨询律师

4.2.2.2
1.0.0.1
208.67.222.222
84.200.69.80
8.26.56.26
149.112.112.112

存活海外 dns 列表，来源： https://www.lifewire.com/free-and-public-dns-servers-2626062 随便试了其中的一部分

Clear Sans

https://imgs.fontbrain.com/custom_imgs/79/e0/c29cff90ef22bd513f10253b1b32/[email protected]

https://imgs4.fontbrain.com/custom_imgs/b9/bd/ac589c0d3aac828fd3a15108b61a/[email protected]

没待过大厂的话无条件选大厂

另外，城市安防做区块链？团队没人是有核心你是第一个去干活的还是你是核心？还是核心都没有就先找干活的？ 反正从你的只言片语中我只感觉特别不靠谱，这家公司对你的吸引就是地点和宿舍三餐？

哦，女朋友对你如果比事业更重要的话可以另谈……

@newtype0092

我觉得你说的除了对产品经理的某种偏见之外大都挺对的，开发当然有权甚至应当质疑产品并要求产品解释他需求背后的思考和决策的依据，当然应当参与甚至承担业务模型和系统结构的设计和规划

如果你没看完整我的回复，我这里再贴一次，产品不靠谱和开发可以做得更好没有任何关系

@zhenghuiy 能跨过“通过预测需求预留扩展”这个层次上升到“通过分析业务模式指导系统设计从而无需预留扩展”的程度就舒服了，确实不容易，但至少我还是曾经做到过的。我也只是说大多数，更没有甩锅，产品不靠谱和开发可以做得更好没有任何关系

1. 产品需求变更快也是典型的研发需要面对的问题啊，凭什么高并发大数据就是真香，需求变更就是产品奇葩？需求变更就要推翻结构很多时候说明设计的不够合理
2. 研发难度和时间当然是你说了算，但你自己质疑产品变更，就没权利 diss 产品来质疑研发成本了，这就是所谓的互相伤害，真的以为产品是为变而变？质疑动机这件事就连陌生人交流都不可取，更别谈团队成员了
3. 与其等产品懂技术，不如你自己去懂产品和业务。好的开发在团队中，产品都是低着头来请教需求出的哪里可以改进的，因为他就能提前帮产品需求修正到实现成本和业务目标合理平衡的，团队中所有人的目标应该是一致的，抱怨周围黑不如自己发光发亮
4. 有的人碰到障碍了能冷静思考自己的角色和做事方法，想做的更好，有的人就会开始累积负能量，甚至向外散发负能量，建议冷静一下想想