轮堡垒机，跳板机，行为监控的重要性。

技术路线选择，首位要考虑的就是项目时间。
2 ～ 3 个月，考虑到设计、架构、测试、填坑、微服务发布，乱七八糟的一堆事情。
建议选 1 ；
上线跑起来了，趁着用不量不大，而且大家确实“技痒”，也对未来一段时间的挖坑、填坑有心里准备，也互相信任不会甩的锅满天飞，以：“因对未来可遇见的大并发”以及“业务需求可遇见的增加与变化”，需要“引入”“ DDD ”设计模式，通过“微服务”逐步实现“中台战略”，所以要“重构”为 SpringBoot，最终实现 K8S 的分布式架构。

切记：
技术选型千万不能为了技术而技术。

#62 @kooritea 我觉得目前为止，你的回答最靠谱。

@6167 如果甲方有私有代码库，给你个账号，你去 clone 下，留个记录也行。

@6167 这样“源代码”可以证明是甲方提供的，而“无法”证明是你之前单位的，你拿过去用了。

接啊，干嘛不接。
甲方既然愿意问你，那么说明还是信得过你的，但是，考虑到法律风险，尤其是源代码这些归属的问题，不要等你干完了，老东家倒打一耙说你盗窃公司源代码 balbalbal 的，那就得不偿失。
建议，和甲方商量，签一个协议，大致要做：
1、你进场后，现场抹盘做系统；
2、甲方提供项目开发所需源代码、开发环境及文档；
3、项目结束，抹盘离场。

起码，多一道保险吧。

高质量思考，点赞留名再走。

这个事情本质就是一个 KPI 导向的问题。

不用换公司，也许过几年 CTO/COO 这些大佬换人了，有可能就回变成晋升答辩要你说出几个技术在业务上的贡献。

一朝天子一朝臣，技术不关乎生死，不关乎对错，仅仅在于自己的修炼。

@version 公司实际支出，如果在把工位、设备、水电这些乱七八糟的成本核算进来，公司支出是账面发出去工资的 1.5 倍都不止，而且稍微想做点事情，准备融资的，合规都要考虑也不敢避税了，五险一金也不能乱来了。
JD 放出去么，简历上的快的前三岗位：设计、前端、产品，一天不看吓死人的节奏。
微服务说说也没啥难得，但是我见过一个苏宁干过的 30 岁的 Java，这是吓人的技术储备：
别人 boot 建的项目，他接手维护迭代后，升级要打 jar 包去生产环境替换。我以为还是传统的 SSH，就说你要看看 boot 啊，你们这种业务最适合微服务场景啊，要往 boot 上迁，然后 cloud，docker 用起来多省心啊。
人家说，就是 boot 建的工程啊，我说那你干嘛还 jar 包部署啊，不知道 docker 啊。
答：不知道 docker，没看过 cloud。
他的垂直拆表的办法，我估计你能猜出来。

@CF3B5 你可能掉入技术理想化的陷阱了，慈不带兵，该出手就要出手，否则无法立威。 你可以看看我之前的一波骚操作： https://zhuanlan.zhihu.com/p/30551539
实际上 V2 里面也有，懒得去翻了。

真没法理解一边提问一边还要反手给人抬杠的人，大家散了把。

@dafengchui Downie

下好说，办法多。
提醒下：如果商用，注意版权问题。

@version 说实话，我就看了楼主的帖子，回复就扫了一眼，基本算是没看，但是能猜到有喷流程主义的，有喷谁背锅的。
楼主的有关产品经理的认识我是绝对赞成的，真正好的产品经理凤毛麟角，大多数产品经理其实就是“原型工具使用者”，干的活根本算不上“产品”。

产品迭代下来，后期都是在代码屎山里爬，这个是无法避免的问题，无非就是前人干活设计靠谱、代码工整、文档能和代码对上绝大多数，爬屎山轻松点而已。最后就是写代码的不敢接需求，提需求的给严严实实怼回去，让大家形成了“重视开会套路、需求评审”这些扯皮的事情，而且，把扯皮当成了正事和正义。

小企业理智的 Boss 是怕大企业出来的人做 CTO，一方面有可能无脑直接照搬大而全的 state of the art，HC 和工资包袱就能把小企业玩死；另一方面也有可能如你说的终于有话语权了，拿没经过时间验证的新东西来练手、跳坑；也有可能大企业是制度完备和管理完备的，技术可能就没参与过管理，然后要做管理了，定制度，带团队了，无招了，最后团队散事情搞不定，没有一个人开心。
但是呢，小企业又蜜汁相信大厂经验，认为只有大厂背景才是“最佳人选”。

所以我以为 @CF3B5 可以忽视这个帖子了，既然到了这个位置，架在火上烤了，还是看看管理类的书籍，快速入门管理。

@version 所以楼主根本没必要和这种 CRUD 工程师计较什么，既然人家要废自己，那就目送好了，而且为了业务安全 D 这种活都不给他。

这么多楼，不想一一看了，这是属于老生常谈的问题了，直接放我的结论。

说难听点：任何人，做任何工作，不愿意去突破“自己给自己的边界”，无法成长，难成大器；

说鸡汤点：我们需要更多的去理解别人的工作，这样我们才有可能站在对方的角度理解别人工作的难处与不易，我们才能更好的在自己的工作职责范围内，尽可能的去帮助别人一起进步；

说正常点：
写代码的目的是为了实现某个特定的功能，一些特定的功能组合起来，我们称之为“产品”；只有站在产品的角度去理解需求，审视代码逻辑与设计，才有可能“避坑”和“改来改去”；
当你是更高的段位的程序员，能理解产品方向之后，面对 PM 的需求，你可能就会主动和对方沟通，“未来这里会不会有这样的变化，哪里会不会增加新的功能……”，你会“理智”的在设计阶段就留出应对未来变化的结构和抽象方法；
当你段位更高之后，你关心的是架构与产品层面之上的问题，而不是写几行代码或者改什么功能；

所以，对于楼主而言，这样的程序员，吵大可不必。
安排一次不听，我给你讲一次道理，听进去，配合则好；
安排一次不听，我给你讲道理，还不配合，这次就这样，我相信这也不是不改地球就要爆炸的功能；
再安排一次，还不听不配合，那就最多再给一次机会；
三次之后，恭喜你裁员的时候有了第一个候选人；如果没有裁员机会，那么总有增删改查的维护，这些不需要那么复杂，给他干呗，干两年干废了再说。

关键词：网桥
了解一下先。

谈价钱的时候说清楚没有发票，让他们自己去代开呗。

散热不好呗，我的老 MBA，飙到 90 度都是常事，无奈下清灰、换硅胶，就回到正常 50 左右了。
所以建议：清灰，换硅胶。

现在正常过夜就能通过，2 天都属于极端情况了。
看看邮件，不清楚历史状态，可以内部问问之前提交是不是出过状况。

TCP/IP 详解，三册摞起来，看看都吓人，不知兄台有没有耐心看完。