小白虚心求教为什么一个公司内部用的软件要那么认真的做

楼主所在的组是一个给公司内部的财务部门做一个软件的，用户大概50人吧。加入组里一年以来发现，组里面对这个app的质量把关很严，除了business logic这样的东西必须要保证正确以外，不知道为什么组里做任何的事情都必须得把代码写到极致漂亮或者优化到最佳。具体如下：1. 永远不能写一行多余的代码；2. 永远得把代码逻辑写到最清楚，比如，if else语句只能用一次，如果里面还嵌套了别的东西，那一定得修改的代码逻辑。 3. 前端的文字措辞一定要无比准确，前端的components风格一定要绝对保持一致性。4. 虽然用户很少，但每个feature必须要绝对的测试和追踪user activity。
即便是现在组里特别缺人，这些要求从来没有被降低过。组里不仅缺人，还缺钱，现在活儿太多，时间也紧张。请问，大家做的产品都是这样吗？楼主感觉有些累：既然没有那么多人，前端能用不就行了吗? 为啥一定要花那么大力气去维护UI呢，毕竟只有那么几个用户。

楼主对于组里的做法现在的理解是，组里的代码就像是一座楼，必须得把前面的夯实了，后面才能不出现重构代码过于困难的情况。不知道大家是怎么看的？

楼主在没加入工业界之前曾经听说过有的公司代码库是屎山。请问，什么样的代码库不是屎山呢？如果代码量很大，写到最后是不是代码必然质量会降低呢？怎么去控制代码质量呢？作为小白，怎么做才能够符合公司的要求呢？是不是要一直这样严把质量关才是正确的呢？谢谢。


补充内容 (2022-01-12 09:22 +8:00):
看了几个朋友的回复，原来这样做是一个比较规范的软件开发流程呀，小白白打算后面多认真干活，多学点东西。谢谢各位！

对 eng 来说, 这事很好的事情吧. 越是 high quality code, 变成屎所需要的时间越久.

但是很多人都是 "别人/前人 写的这代码啥啊, 就是一坨屎" 但是却 "我写的代码才不是屎, 我才不用 follow 什么好的 high quality code practice". 但是恰恰就是这种人造出来了屎. 甚至自己 2 年后改这部分代码的时候自己骂自己的代码, 看看 blame 发现是自己.

如果 tech lead 能足够的 push 其他方面的压力, 主要是 deadline. 那这就是很好的环境. 比如同一个 feature, 瞎 jb 写 2 个星期就够了, 但是 TL 能争取到 4 周的时间让大家写好的代码. 而不是逼大家 2 星期写出来好的代码.

1,2 是为了保证代码可维护性，防止有人离职了代码就没人能维护了
3,4 都说是财务用的内部软件了，功能/描述当然是越精确越好 不然有歧义造成损失了怎么办

非常欣赏这种风格啊，不管用户多少，万一日后用户变多了呢，或者万一日后团队人员减少了呢，如果能把代码写好，日后的维护成本就会大幅度降低，从长远考虑总是利大于弊的。很多初创公司代码图快写的跟屎一样，短期可能是快，但长线看，如果要scale的话，新人入门就慢，老人走了可能这个代码就再也没人懂了。

没什么必要 你还是跳槽吧

既然做了就做的好。感觉这种文化是比较好的。要么就完全不做，做一半然后够用就可是最狗屎的。。。

这个听起来像是你manager或者tech lead的管理风格，和软件规模没啥关系。有些管理者就是抠细节，有些就是想deliver result。各有好处吧。

精工出细活，很不错。如果给你充足的时间完成这些要求，那是很好的锻炼机会，但如果要求短时间内还要实现很多feature，就耍流氓了。

在国内的话估计能遇到这样style要求的leader不多。珍惜吧

从小养成良好的习惯。。。

面试的时候很容易看出来有人之前就是没有被这么抠过代码，写出来的东西没那么漂亮（不是production level code），那即使是题目做过了也要在级别上考虑一下