说一下个人经历，接手一个小项目，不到 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,这种挫败感是完全没有办法避免的.

python 实际上是可以免安装使用的.步骤麻烦了一点,但是还是可以用的.
另外,还是 vba 比较实际一点.

我也是码农一枚，到现在为止也没有开过公司。但是作为一个曾经有机会在眼前而没有抓住的人。我给你讲个故事吧。
我跟我同事当时两个人基本水平差不多，实事求是的讲我水平应该还比他高一点。你是前领导来拉活，我们是以前的同事来拉活。
我们两个当时谈了钱，价格不是很高，就当时外快了。但是我跟我同事的差异在于，我不是很积极，还是当一个简单的编码任务在完成，但是我同事不一样，他当成是一个项目在做。
从确认需求，定义开发方式，后期的上线，维护，包括收款方式，他一直都在跟，参与的很紧密。
到最后的结果是，开发完成之后，我拿钱走人。他几乎是免费的帮人培训，外加超期维护了 3 个月。
可惜，结果不是你想的那样，那个公司本身也不是什么大公司，我这个同事虽然得到了赞扬，但是也没被人家看中，人家也没多给钱。甚至因为是同行冤家的关系，连再介绍个活都没有。
改变发生在第二年，当我先跳槽了，然后公司内推的时候，我推荐了我这个同事，结果等他进公司的时候，职位比我高一级。面试他的人正好是我的上司，他还感谢我说，给他推荐了一个好员工。
按照我上司的话说，我那个同事，稍微培养一下，就是一个好的项目经理。

我不知道你对开发怎么看，但是我想说的是，如果这是你第一次做外包的开发项目，把他当成一种经历也挺好。尤其是有人帮你兜底，给你培训的情况下，你主动的参与进去，不仅仅是作为一个开发者，最好能作为一个项目参与者，不要在乎什么这是不是你的责任，而是去考虑这么做对项目有没有好处，这样的经历不是每个开发者都能有的。

但是如果你已经是老油条了，甚至你现在手里还有其他的项目需要你业余时间做的话，那么请当上面的话都是废话。

照这个理论，何止是电脑，房子呢，车子呢，最关键的是，老婆呢。