作为一个跟你犯过同样错误的人。我十分理解你的心情。
我以前有一个回复里面，写过我跟你犯的错差不多。花了两个星期的时间，把核心函数给改了，结果没有得到表扬，还被训了一通。
到了今天，当我也有了要对项目负责的经历之后，再回过头来，讨论对错，我觉得我可以更客观一点。
先说我的结论吧：
这件事儿，你所占的错误很大。大到 90%，你老板只有 10%的错误。

我知道这么说可能会被人喷，但是我希望喷之前，能看完下面的分析。
现在我分析下为什么我会说你的错误很大。
首先，为什么你会提出优化？是真的从业务角度来看的么，还是你本身有一种优越感，认为现存的代码，现存的流程不够优秀，要是你来的话会怎么怎么做。。。
然后，最重要的一点，你提出的方案，具体到收益是多少，风险是哪些，在你给老板的提案中，这些有明确体现么？

我也是程序员，我当然明白，看着一堆烂代码，一些个傻 B 流程，是一种什么心情。当你明明有更好的方法去解决问题，甚至是你自认为非常优雅，有效的解决问题的时候，整个公司，没人支持你这么干的时候，你自然而然的就会觉着其他人都是傻 B 。只有我自己最优秀。

但是如果换一个假设，你是一个初学者，什么都不会，完全不知道什么代码是好的，什么代码是烂的，哪些流程是必要的，哪些流程就是摆设，你只是来学习的。这个时候，某一天，你突然发现某些代码好像你写的比较好，有些流程你制定的更加流畅，你会贸然的找老大去说，那个谁谁谁写的代码好垃圾，那个什么什么流程就是废物，这样的话么。你会不会有一点忐忑，甚至一些不自信？会不会等一等，看一看再说？

[有一个北大毕业的学生，入职华为，他刚到华为时，觉得华为的经营战略有问题，自己作为新员工，有必要提出来。于是洋洋洒洒写了一封“万言书”给了任正非，历数了华为的弊病和改进方法。写完之后自己很满意，原本以为自己的独到见解能够打动领导。但是令他没想到的是，任正非给他的批复却是：“此人如果有精神病，建议送医院治疗，如果没病，建议辞退。”] --任正非传

为什么会是这个结果？不是号召要革新精神，要鼓励创新么？
是的，没错，当然要鼓励，但是很少有 HR 会直白的告诉你，老板们要的是那种，小改动，小风险，小投入，大收益的创新。其他的创新他们都不要！！！

所以第一点，我看不到你的这个创新能为同时带来多大的收益，充其量就是简化了某些人的工作量而已。

任何创新都伴随着风险，你能预见到其中的一部分，很不容易了，但是你要明白，每一次的创新，最后的风险承担者不是你，是老板。公司黄了，你见过几个打工仔跳楼的，老板跳楼的是不是常听说。所以任何一个不是由老板提出来的改变，老板的第一反应不是这个创新有多好，而是这个创新有什么风险，我能不能承受。如果你给老板的提案中不把这一部分明示出来，再加上不能描述出有多大的收益，那么这个提案给老板的第一反应就是，这个人是来给我添乱的。

你要明白一个道理，甲方爸爸提出再脑残的需求，只要他给钱，我们就要实现，哪怕这些需求最终会让甲方自己赔死。反正死的不是自己公司。
相反，公司内部再简单的一个需求，哪怕收益大，风险小，可是如果处理不好，就可能导致公司黄掉。这种情况下，老板天生就倾向于反对创新。

能看到这里，最少证明你是个有耐性的人，那再说点题外话吧。
我是一个比较倔的人，写了两个星期的东西，被人喷成垃圾，心里自然非常不爽。但是没办法。
后来我头头给我支招，不要上来就搞风险这么高的东西，搞一些风险也低，收益也低的东西。我就做了一个自动日报完成系统，把组内所有人的 commit 提交格式化成日报内容，后期还追加了跟式样书联动，bug 号追踪等一系列的功能。
最终逼的经理不再要求我们写日报。开始改由 jira 管理项目。然后慢慢开始掌握话语权，等到了 2 年后的某一次功能追加的时候，这个时候又开始牵扯到那个核心代码的时候，我又开始宣传我的新代码。 这一次我学乖了，不再强调我的代码多么优秀。我强调我的新代码可维护性高，耦合度低，对于开发新手友好，修改的时候，不容易产生次生 bug 。尤其是最后一点，因为当时已经有 3 组人因为改 bug 。导致了其他 bug 的产生，其中一个还就是跟这个函数能扯上关系。

最后，当然是我胜利。但是为了这个胜利，我相当于在两年时间里一点点的积累我的名望，才有了最后的胜利。
如果你真的觉得你的提案很必要，而且很重要，不要放弃。但是也不要鲁莽的去硬钢，从小地方做起，一个是体现你的技术，另外一个增加你的话语权，当你的技术被认可，你的话语权大到你说的风险，其他人都要考虑的时候，你再提创新，相信就会是另外一个结果了。

visual studio 2015-2019，beyond compare 4，toad，windows，office，box 。

@missdeer 看你头像，再看你说话，我就猜到了是杨旭。他的视频确实很好，go 开发 web 也很有用。

说一下个人经历，接手一个小项目，不到 7 千的代码，最核心的代码超过 1 千行，写在一个文件的一个函数里面，光参数就 20+，还很多都是结构体。
这样的一个结构，领导给的时间只有一周，如果按照式样书做，就是结构体追加两个变量，然后在参数的 600 多行的位置，再追加两个判断，就能完事儿。测试也很简单，只要测试这一个结构体相关的内容就可以了。
当时年轻，总觉着自己能改变现状，于是业余时间花了快两个月的时间，自己重构这个函数，把他拆成六个相对独立的函数，同时还做了两个接口，用于外部调用。然后拿着这个解决方案给领导，本以为会受到表扬，结果被训了一顿。
领导的意思：首先，我做的拆分没有实际的根据，完全是根据现有代码逻辑来的，对于以后的业务完全没有扩展。其次，这样的拆分对于客户来说，风险远远大于收益，核心函数这样大的变化，客户的 sku 超过 2 千个，每个都要测试，但是收益只是维护的便利性增加了一点点。最后，函数级别的解耦，通常只能解决部分问题，如果要做，那么应该从整体结构就开始做解耦，单做一点，费力不说，而且效果很小。
通常历史悠久的公司，往往烂代码更多。一方面是因为当时的编程者的只是结构就是老的，一方面也是因为当时的设计根本不可能完全适合未来的变化。但是业务有时候会剧烈的变化，可是代码受限于当时的结构，就不可能剧烈的变化，于是开始有了补丁。也是技术债的产生根源。
作为程序员，在我们眼中，程序的质量高于一切。但是在商业社会，商业活动最终是利润说话的。假设一个 60 分的代码，可以提前 3 个月面世，并且每月能获得 100 万的收益，并且每月他的维护费用为 10 万，一个 90 分的代码，要晚 3 个月面世，同样收益为 100 万，每月维护费用为 1 万。你觉得你是老板会选哪个。

楼主你的思想非常的先进，而且很对。类似的就好像 Google 的员工发现他们的项目被美国军方用于驱逐移民上，然后员工就开始抗议一样，最终 Google 终止了与美国军方的合作。如果福报厂的员工，发现钉钉被老板用来压榨员工，他们也抗议，那么结果是什么呢，就是所有的老板都不会再用钉钉，然后钉钉就黄了，最后福报厂也黄了，员工都失业了。而那些个老板呢，还另外一个“钉钉”，继续压榨员工。
所以你看到了，钉钉本身不管怎么做，最终的结果都不会有利于自身。这也是钉钉不作为的原因。
如果我们假设现在的环境是这样的
只有钉钉一家是助纣为略型的，而老板也很喜欢钉钉的功能，但是由于员工的抗议，最后钉钉不得不也随波逐流，把哪些违背劳动法的功能都给去掉，结果就是，钉钉依然活着，而老板也没办法压榨员工。
这么看来，钉钉本身的并不能改变什么，关键是要改变大环境。那么怎么改变大环境呢，就像很多人说的，要严格执行劳动法。积极举报违法企业。
虽然我们一直说美国的工会制度多么多么的阻碍效率，但是不要忘记，正是有了工会这一强大的组织，才能让绝大多数的美国企业遵守劳动法，让他们的员工可以真正的做到生活工作平衡。

来个不一样的推荐吧 https://www.163.com/dy/article/FQ6VCV1U05119NPR.html 自适应高度的枕头，我买了一个给我老丈人，据说效果不错。

既然你是程序员，那么我感觉你可以用用语雀。或者直接用 coding 的 wiki 也行，不管怎么样，先做起来再慢慢迭代都好。就怕你这热情一过，就没动力去做了

要是我的话，我会花时间先写一个劣化版的，算是一个原型，给老板看，说这是我以前学习 XX 的时候做的一个 demo 。好像跟这次的需求能匹配上。看老板啥态度，要是点头。那就开始摸鱼。但是大概率是老板吭吭叽叽的又来一堆需求，捡你做好的那部分答应需求，没做的需求开始哭穷，要么是有难度，要么是需要花大把时间调查，总之，核心思想就两点
1.哥们以前有积累，才会让你今天捡漏。你要看到我以前的用功。
2.一周时间要是没我以前积累，是不合理的，做不完的。哪怕是现在，也是要加班，勉强才能做完的。

姜云升 成名

经历过不少对日项目.正好算是总结吧.
我把对日项目分为三种.
1.社内
2.社外
3.外包

1.社内.
日本不少大公司电子化很早,所以他们有不少很老的电子系统,从进销存的,到最新的网页的,云的.
这类的公司,通常都有严谨的文档,开发严格遵循瀑布模式,开发一个功能,从外设,内设的改修开始,外带各个联合部门的评审,加上后期的 UT,IT,SIT 测试.一个功能从立项到最终结束,搞半年都正常.
通常这样的公司,最强调文档,外设,内设会一直同代码同步,包括测试用例.所以这样的公司真正的开发人员很难成长,
最容易出彩的是同各个联合部门沟通,熟悉自己的业务,同时还能兼顾上下游部门的业务人员才是最重要的.但是这样的
人一旦离开公司,就什么都不是.因为是社内的项目,质量要求其实是最低的,时间给的也是最多的.

2.社外
日本公司只跟信任的公司做生意的传统.所以有很多公司之间生意做了十几年.同样,系统也是做了十几年.这样的项目软件公司里面一定会有几个队业务非常熟悉,资历老到可以培训甲方的几个老人.这样的公司一般来说工作量也不大,最多的还是文档,但是因为隔着一层公司,有时候文档会滞后,外带会有公司政治的原因,有时候会有东西做一半,开始各种加机能的情况.这种情况下就看两家公司之间的熟悉程度了,很熟悉的情况下可能会怼回去.不然的话,就会接.这样的公司历史悠久,基本上也还算人性化.但是已经开始要谈性价比了.

3.外包
这是最常见,同时也是各种各样坑开始频发的场面了.一层外包还算好的,有时候会有三包的,四包的我也见过,但是极少极少.外包的时候,基本上式样就是个概要,外设有也是没啥用的.加上没时间熟悉业务,客户给的时间通常是不够的,而且非常容易出问题,因为沟通问题,或者业务不熟悉,做出来的东西很少有不需要返工的.这种公司唯一的好处就是,由于业务不熟悉,对真正有技术的人比较友好,会尊重他的意见.

其实这种事情太常见了.XX 公司,去年刚从 TFS 转到 GIT,最大的一个工程包,里面 180+工程,外带编译好的 exe,dll,放在一个 git 路径下.全包 22G.我每次切分支都是要 vs 假死,外带一杯咖啡的时间才够.(exe,dll 发布用的,不是 bin 文件夹下那种)

就这,公司一大票人不敢切分支,楞是 master 分支开发了大半年.6 月开始多项目并行开发,实在没办法了,才开始用多分支开发.然后往 master merge 没人干,我干了,又不相信 git 能自动 merge 好,非要做代码差分比较.我现在正在研究怎么自动化截图代码,然后保存成 excel,如果成功了,我到年末就可以天天摸鱼了.

等着看吧,用不了几年,腾讯云就会被华为赶超,这样的事故腾讯都已经不是第一次出了,结果就是因为他有免责条款,然后就一直这么拖着不想解决厂商的实际问题.就这样的作风,还一天到晚吵吵自己有 2B 的基因,做梦那!

beyond compare 就算了.不用试了.那是个文件比较工具,对于这种迁移小文件的动作,支持的不是很好.而且也很慢.

@ah597568204 你这个更不靠谱了.默认都是英文输入法,来回切更麻烦

@wzzzx code review 是一项精进的工作,那么如何保证精进,而不是在原地踏步呢,只有靠文档.当我们 code review 过程中,发现以前遇到同样的错误的时候,这个时候,如果有整理的文档,那么马上就可以说,看,这个错误是之前我们总结的错误的第几条. 只有这样慢慢积累,code review 才是一个质量提升的过程,而不是一个浪费大家时间,只有投入,没产出的环节.

我总结了 code review 的两个凡是
凡是能坚持半年以上的,项目通常都进行的不错.
凡是能总结出文档的,通常项目都有牛人.
反之则是
凡是坚持不到半年的,项目通常都已经开始有臭味了
凡是 code review 之后啥都没留下来的,最后就都不了了之了.

code review 这个东西,有点像内功一样,平时你看不出来效果,还贼费时费力,当你真的遇到一个大坑的时候,才会觉得,code review 是多么的必要.但是呢,真到那个时候了,能坚持 code review 的人很多时候要么是愤而离开,要么就是开始随波逐流了.

@cherishxyn 你可以最后回帖的时候 @一圈人,感谢一下就行了.另外,如果可能的话,最好把你最后修改之后的结果也贴上来,这样很多人还会帮你看看哪里还有不足.

有一点我看大家没有说到,我补充一下.测试给你疯狂的发 bug,你不能对应完了就完了.要把这些 bug 都找出来,总结一下,有哪些是因为你的考虑不足出的错误,有哪些是你的知识不到位,出的错误.哪些是因为文档没有写,你也不知道出的错误.
这么总结一圈下来,你最少能在一个项目上,看到自己的不足之处,然后针对性的去学一些东西.
个人认为,软件工程分两大部分.
1.技术积累.简单来说,如果你对这个项目所用到的语言特性非常了解,对应优缺点都心里有数,项目有什么需求,你都可以有现成的提案.那么对于一个项目来说,能在技术上学到的就是这些了.
2.业务积累.简单来说,你不在是一个开发者,而是一个使用者.为什么要做这个功能,是什么痛点让客户提出了这个功能,这个功能是不是最好的解决客户痛点的方式,客户可能还有哪些痛点,能不能有更好的方式解决客户的痛点.随着你提的问题越多,你能从业务上学到的东西就越多.所以业务层面的积累相对来说会慢一些,通常我们得闲到一点程度,才能有时间体会这些.
至于你说的没有 bug,或者被人疯狂提 bug,这种挫败感是完全没有办法避免的.