经历过不少对日项目.正好算是总结吧.
我把对日项目分为三种.
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 个月。
可惜，结果不是你想的那样，那个公司本身也不是什么大公司，我这个同事虽然得到了赞扬，但是也没被人家看中，人家也没多给钱。甚至因为是同行冤家的关系，连再介绍个活都没有。
改变发生在第二年，当我先跳槽了，然后公司内推的时候，我推荐了我这个同事，结果等他进公司的时候，职位比我高一级。面试他的人正好是我的上司，他还感谢我说，给他推荐了一个好员工。
按照我上司的话说，我那个同事，稍微培养一下，就是一个好的项目经理。

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

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

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

从顶层一直看到最后一篇评论，感觉没有一个人说到一个问题。那就是，这个培训班出来的人到底给项目带来了多大的风险。如果你真觉得这样的一个人对于项目带来了特别大的风险，那么我觉得你有必要跟老板说，但是如果只是你自己个人的不舒服，那么我只能说要么忍，要么。。。
99%的人都只是在做一份职业，1%的人在做事业。做事业的人，绝对不能容忍别人破坏他的事业，如果你是这样的人，那么如果判断你的同事真的在影响你的事业，那么就去说。如果你只是职业的话，那么我建议你，从职业的角度来看看说出去之后，对你的职业的利弊。

不客观的说，这是我在 v2 上看过的最好的一片文章。因为它给我的共鸣比其他任何文章都强。
老实说我曾经也有一段时间是楼主这样的经历，甚至更严重一点，我连遗书的电子版都写好了，预设了一周以后，随时可以发出去的状态。
那个时候觉得世界真的没啥意思，觉得死亡反倒是探索未知的一个非常好的方向。那个时候还不知道这个叫抑郁症，只是觉得自己跟这个世界没啥太大关系。
我走出来这个状态也是因为读书，我读的大多是一些名人传记，不是现在这种还活着的就开始写回忆录的家伙，是那些死了好长时间，还能被人记住，愿意出他的书的那些人。
从这些书里面，我慢慢体会到了人生的意义，活着的乐趣。这些值得被记住的人，虽然书里面从来没有说过他们有什么苦恼，但是看看他们遇到的困难，生活上的，事业上的，甚至是肉体上的。可以预想他们的痛苦。但是最终，他们依然做出了伟大的事情，做出了值得被人记住的事情。
现在，我学会了一个词，叫做 向死而生。我所有的选择，所有的思考路径，都是从这四个字出发，做任何的选择，首先问的是，当你临终前躺在病床上，是否会为这个选择而后悔。
我现在慢慢有点体会一句老话，一命二运三风水，四积阴德五读书。读书，真的是提升生活层次的一种很好的方式。

哥们，简单想象一下，一个普通人距离你三米的情况下，框住这个人需要多大的显示器？所以推销说多少多少合适，真是瞎扯。我近距离（ 1 米）看过 100 寸的电视，肉眼也没觉得难受。但是有一点，在 1 米的距离内，你的电视资源一定要是高清的，最低也得是 1080 的。不然画面真的有点晕。
至于 3 米的话，我家还不到 3 米，但是现在我用的是 65 寸的，完全没有感觉到大。刚开始的感觉到了大。但是最多一个多月之后，你就发现没啥感觉了。

6 楼的思路不错啊。学到了。replace 竟然有第三个参数。以前一直不知道

其实不是指针难，主要是楼主你学的 C# java 这种高级编程语言，把本来很复杂的编程语言给抽象的符合人类直观感觉了。所以当你学 C 的时候，指针会让你觉得很难。
从人类可以理解的代码，到 cpu 真正执行的指令，中间隔了很多东西。每一层都是一种新的语言。而相对于来说，C 语言本身更加关注内存，所以他有指针，还有垃圾回收。而 C#还有 java 本身的环境（ freamwork，jvm ）他们自身已经将内存操作以及垃圾回收都已经包含了，所以指针的概念就消失了。
这也就是为什么楼主你学习指针困难的原因。
至于要怎么学好指针，我个人推荐的方式是去理解编译原理，不要求你真的对于编译原理有多么高深的理解，只是希望你能在头脑中真的有一个关于内存的概念。

int a = 1
a = 2

以上两句 java 代码是不包含指针的，但是在内存中他们开始是什么样的，赋值之后又有了什么变化。如果你能很容易的回答出这几个问题，我觉得指针对你来说，应该就不会再觉得很难了。

菜根谭

呵呵。我也来证明下楼主不是在玩单机，等下去 start 下。