如果你找不出理由证明这个经验的意义,说明你的经验不一定是对的.
很多常见的"经验"在工程角度来看,都是错的
比如保持代码的"优雅",追求代码量少
比如做 web( http)开发的第一步是选一个 web 框架
比如要把两段看起来差不多的代码抽象成一个函数(实际上可能这两段代码表达的过程是不同时,只是恰好大部分代码相同)

golang 本身就不是利好开发者(coder)的语言,是利好工程师的语言
简单说就是,搬砖的要搬更多砖,但是能建造出稳定性和性能更好建筑

看下来真实存在的问题就只有一个: 工作进度是龟速
但是这是你的问题还是你领导的问题?

你就是个纯杠精，看见大家都在骂你我就放心了。
你的想法：我觉得不合理所以需要改
对方的想法：虽然不合理但是没必要改
你如果不是给项目提建议，就是想知道对方的想法，何必在这个项目里提 issue ？
所以你并不是只是单纯的想知道对方是否觉得合理
你先搞清楚你在干什么，再搞清楚你在说什么，最重要的是搞清楚你想要的是什么

不相信的根本前提：确信时间是有方向的，是线性的，是不可逆不可修改的。所以一定是先有因再有果一定是过去的事件决定未来的事件。
但是我现在不确定这个前提是对的，所以不对这种“预测未来”的行为做完全的否决。

可以考虑下开源方案： https://zoneminder.com/

这就是标准的韭菜吗

虽然我两百多斤，但是我提醒一下各位，人类对于自身的了解实在是太少太少了，通过这种“欺骗人体机制”的方式来减肥，还是小心隐性副作用，很多理论都是要过很多年才会被推翻的。至少我是不愿意做小白鼠

是博士毕设吗?居然要求能打赢大厂几百人维护十几年的东西?

不管是哪行哪业,都只是有极少数人才有所谓的"未来"
按你这种心态的话,把"写代码"换成任何岗位这个命题都成立,同时也不成立
说到底还是看人的价值(广义的)

你是顾问，既不是开发也不是测试，所以如果是软件 bug ，不该是你背锅。
不过依我猜测你所谓的 bug 可能不是 bug ，而是需求提出的时候场景就没考虑完善，给出了不完整的或者模糊的需求，所以再产品逻辑上有 bug 而不是代码逻辑上有 bug 。如果是这样就并不是开发和测试的锅
这种情况你作为顾问本来就是你的锅（ SAP 里的顾问其实就是理解收集用户需求并且给开发提需求的角色吧）
如果我猜错了就当我没说。

装了它的 CA 根证书就跟裸奔一样，各位看着办吧..

自荐一下: https://pho.tools/
通过 smb,webdav,nfs 备份和浏览照片,配合 photoprism 很好用.

容易忽略专业运营推广的重要性。

啥意思，这是我家，我开门关门你还管得着吗？
我在自己家里裸奔你也管不着啊