现在的新工作是这样，本来公司用的系统是买别人的服务，现在想自己做自己的系统。
老牌公司新事业体，该开发团队包含主管不到5个人（应该不会更多了），依我观察大部
分都主管在写，目前是说只写后端商业逻辑，前段、硬件都是外包。
目前自己的感觉跟想法是
1.准时上下班 部门人少不太用社交 。压力的话就我观察同事好像也还好，基本上都是弄
自己的东西，不太会管你在干嘛。
2.因为现在是想弄自己的系统，所以感觉是可以从比较一开始开发整个系统，感触可以比
较了解实际上开发的过程。（之前的工作都是根据既有系统来维护新增功能）
3.因为人少所以感觉学到的东西更多了？
比如说刚来就被叫去研究CI/CD，本来以为这都是devops工程师在做的，或是架设团队使
用服务的人弄的，怎么会叫一个没接触过来弄，但后来觉得多学这个也有好没坏。
（之前的工作是都会有一个专门弄网络管虚拟机弄CI/CD的人）
目前感受大概是这样 在这种小团队各位前辈会觉得是一个学习的好地方吗？
还是会认为说这其实算屎缺呢？

很正常吧 古早年代没devops的时候都是后端在弄阿

DevOps就是水管工 没底子只能找solution接起来而已

看薪资决定是不是屎缺吧

领薪水就老板要你产就产啥 你知道好不好也没什么意义你没更好的 offer 能跳也只能待了 老板也知道这薪水只能找菜鸟来自干 你也知道目前没更多钱的地方能去

单纯设定cicd没啥用，但如果能制定公司ut到prod的开发规范与流程那就有用

看你怎么做阿，光CICD就可以搞的很复杂了

这种改革旧系统,自己重做,应该是用过旧系统的人来做会比较有效率,他们才知道痛点, 不过找一批不同的人做也有其优点啦

能重头开始参与开发的经验觉得蛮有价值的 如果上下班正常同事正常 工作项目时间规划正常 就没什么问题啦 剩下就薪水和你自己期望获得什么 小团队本来就很容易遇到有新东西要开发没人搞要你去处理 除非你不想学这东西 觉得没价值 不然没什么好不好 如果还年轻没待过小团队 不雷的话可以看看小团队的作法和问题 主动一点去想想自己可以多做什么让开发更顺利 顺便写写文件自己纪录 这种经验才对你有更多价值 但你如果只想到大公司安稳工作 分工明确 照着公司制度 既有功能稳定接续开发 也没什么好不好 两个方向不同 但团队分工和做事流程在不同人数都有各自问题不代表人多一定比较好 人多工作流程时程烂的也是有 要看遇到什么人

通常用过旧系统的老员工 没能力学新的事物也没有诱因 人家说不定要退休了

多学点没什么不好，你所学的都会成为下一份工作叙薪的筹码，除非你想养老了

Jenkins没有多难，小单位不可能找专人弄

devops学起来其实对发展是有益的

团队小 每个人分摊的杂事多 很难针对每件事情都做最好的工程决定 这样的模式比较适合有经验的工程师 因为你明确知道 你不做工程决定 是由于时间考量 如果没经验想软件工程 建议去大公司

你觉得是不是屎缺需要问别人吗？如果你可以找到好的你就去

当然是大公司比较好 如果你没遇到一堆机歪人是这样不会有白目的人整天叫你做一些不是你应该付责的职务内容 至于筹码那不一定 因为还是要看卡位的人怎么看你这行一堆靠小手段和心机上位的 不要把所有事情想的太美好 凡事藏一手这世界终究好人少 这才是真到不能再真的事实

小团队比较好吧，希望尽可能控制在十人内，横向沟通会轻松很多而且什么都碰的到可以互相备援

人数不是问题，人的经验才是问题。不要求软件品质与经验，硬套CI/CD纯粹是浪费时间而已。是不是也屎缺，不是看人数啊。是看人的素质。

事情 钱 人 屎缺与否看这三样目前看起来你这份只有＄可能有问题但是这种环境有个缺点是你业界人脉累积会不够快