lz，不要把工龄当回事。很多人是把 1 年的事重复做 N 年。如果你不想这样。按自己的想法走

为啥要下车 idea …生活不够美好？

idea 算是良心了，个人全家桶可以在公司环境使用… cto 特意确认过这点…

楼上说到能给前端做的别给后端做的人一只手都能数过来

有些是后端做的。比如去重。但 lz 这些可以前端可以后端的。肯定都让前端做。假设你 a 客户端要现实客户。b 客户端要显示爸爸。c 客户端要显示甲方。一个接口肯定干不了。

另一方面，平均数的问题。服务器资源不是钱啊…

看过一些分析。觉得有一条比较有道理。最终相互宝里面剩下的都是没病的。。这个逻辑是说得通的。不说黑暗面，就说正常的经济行为。如果是你知道生病了。但知道有这么个渠道可以不做审核就加入。付出几块钱，弄出几十万治病，自己屁事没有。然后你还留在里面帮助其他人？全世界的人都是圣人是么。。。拿钱就跑啊。。。

用手摁着

其实从某种角度而言，java 也是解释性的。
动态和静态只有语法区别。不是开发语言的区别。一切都是编译器决定的…

lz 不必纠结…这类人，下次裁员，各种 curl 的事，费力不讨好的事，不用动脑子的事。一个公司总有这些没什么搞头的事，总要有人来干。你这现成的人力储备。干这些事滑水最好了的，不用背锅，所有事也是在走流程。你也不用纠结… 2-3 年干毁了又不是你的意愿，要尊重每个人的选择…技术领域拿一年事干 5-6 年的多的是，自己都毁了还不自知

楼上都说听产品的不背锅。你们一定没经历过产品提出奇怪需求。研发实现了。但是性能跟不上，产品反过来怪研发你们行不行啊…但实际这个需求压根就没人用也没必要做这么复杂。就因为产品说什么研发做什么，全被带沟里去了。要花费十倍的精力和资源去纠过来。这类事情在我从业生涯里比比皆是…千万要记住…产品说的事，除非大老板很懂技术。就算他说错了，你只要做了。锅就在你头上。背锅侠常在

另外有另一个思路供参考。研发思考产品体现出来的不仅仅是去和产品争需求。天天在代码设计领域说的扩展性好怎么到这没人说了？
窃以为扩展性好不是需求变的时候扩展性好。而是在开发阶段根据产品特性和自己的理解。预留了很多口子，一旦发现不合适或者需求变化可以快速修改。
我也神 tm 反感有研发说这不好改那不好改。大哥，我们是研发。你说不好改，请问你自己的代码设计跑哪去了？
没有不好改的，只有不想改的

楼上在都揪着流程问题在声讨 lz。但实际楼主要讨论的是这一代新生研发要不要做 code 以外的事。
诚然面向工资编程是对的。但，工程师不是能是只 code 啊…这样的人抱怨青春饭我觉得就是自己作。眼铮铮看着产品被带沟里然后跳槽去下一家。最后时间长了手上一点核心竞争力都没有。君不见每个公司的靠谱程序员都是要和产品怼天怼地怼空气的。整个大环境和谐的团队真没见几个能成功的。lz 并没指明需求定了就研发私自改这一件事是正确的
我想 lz 想表达的是，需求定了，这事做的时候发现不对劲是要提出来去怼产品的。怼不过就升级怼。要坚持总是在做正确的事。这个思想一旦在团队内建成。大部分情况就会提升到需求确认的时候，就完美的符合前面各位说的所谓流程问题。但是
如果研发只是 coding …不做思考。这事就得 leader 一个人来干。真的会累死的。
所以我觉得 lz 不应该要求所有研发都如此。但最少小组长是这个特性的。人员分层是社会分工的必然进程。

像 lz 这种情况我会评估产品会不会发现。如果不会，则直接顺手改了。如过会发现就先讨论一下。 所以因此气哭了很多产品和测试…

这个史前时代的问题…你居然把 redis 扔公网上。佩服佩服…

@Livid 什么都不做。做了才是 sb …

es 干嘛的。。。

简单…不要问概念。问开放式的问题。就算是概念也要用开放式的方式问出来

不在 dev 分支开发是可以理解的。但不会用 git 没法洗。所有这种都是半年-1 年开发 7 年管理这种了

感觉楼上说的对。。你破解后然后被病毒感染了。。你想想会发生什么吧。。

@pifuant k8s 的文档加起来可以是一本小说了吧。所以才说是经验坑啊。谁看手册全背下来？

这种经验坑产品。我是不建议学。但是可以了解一下概念。比如给我干了几次 helm upgrade 项目。很简单对不对？楼上不是说只是工具么。这里是有经验坑的…

如果真想学。了解完概念，要么推动你老大公司层级使用。要么，跳到一个正在使用的