如果你不能找到更高层次的公司，先待着伺机积累。火坑跳火坑，伤的是自己。

人力踢皮球就跟人力的上级部门谈。再不行直接找老板。

@kuyuzhiqi 小老弟，别冲动。不妨跟你那个同事还有领导沟通一下，实在沟通不了再走也不迟。

@petelin
不冲突。事实上这不是一件事情。我的观点是，在填坑的过程中你发现 bug，可以上报跟修复。但是对于一些正常运行的功能，如果仅仅是“我认为 /觉得”这样做不好而产生了修改的想法，这是不恰当的，缺乏谨慎的。当想去验证的时候，常常发现验证与测试成本是远超过所谓的提升成本...

这个东西其实没有什么管理上面的意义，纯属个人的经验，我做过很多年的协作开发，也做过很多年的独立开发，偶尔也做做甲方的外包，对于技术上的一些小执拗（是不是要坚持去修改别人的代码）我不认为是“对”或者“错”，但我更倾向于符合生活智慧的选择。

@petelin 每一条都是血与泪的教训，只想说，人的精力是有限的，根本没必要花在别人的错误上面。

1、考虑自己的时间成本与改动后收益。一堆垃圾只改其中一点还是垃圾，你永远不知道你的正确代码会不会被他人的 BUG 所影响。除了重构。

2、按流程说，填坑跟 codereview 是完全错开的。填坑是修改别人的遗留代码，锅也是之前的 review 跟 dev 背。你说的完全是开发期的事情，而不是二次开发或者运维的事情。

3、看到垃圾代码就想改...我想说除了技术层面的因素，这是谁写的代码 /服务于谁 /新技术、架构验证 /测试成本都同样重要，所以...

穿多点衣服。

完全理解你的想法，你担心的是如果有太多的电联，容易分散准备时期的精力。

建议：
1、有梯度地选择公司面。有保底也要有冲刺，跟高考一样。
2、准备一些借口拖住其他公司，尽量保留面试机会。

对于 2...见仁见智。

关于填坑，我觉得是个学问，有几点跟 LZ 分享一下，与君共勉。

0、不花心思去理解别人的业务代码。

1、除非重构，永远不去修改能正常运行的代码。

2、除非我已经跟他平级了，永远不主动修改上级 /前辈的代码。

3、永远不要在旧系统的需求上想当然。

4、即使重构，新的技术也需要试验了再上。

5、如果你今天不能说服他，就尝试去理解他，关系缓和后再说服他。

6、老板在技术上是傻 x，但是他能看到的东西绝对比自己多。

对 LZ 说声抱歉，之前一个贴子是回给你的。但是这个回贴是借你的楼回给那些没理解我意思的人。

很多人说我的观点代表员工一定得加班，加班一定就是好员工。那非我原意。

我的大体意思是，在一般人进入一个公司实习，肯定是希望受到这个公司的赏识跟 Offer 的，尽管你最终未必会留下来。
站在自身的角度来想，按时完成任务、准点上下班绝对政治正确。但那不是我们最优的选择，因为招聘市场本质上就是聘方市场，应聘的过程就是一轮选拔测试，择优而取再正常不过。那也是为什么我们希望在实习期能尽可能表现自己的原因。

站在公司的角度，招人是一个难题。
招来五个年轻人，每个人的任务都顺利完成。聘方如何决断最终人选？还不是回到了看学历、看颜值的普世标准上来，这时又会有人跳出来说“是不是学历就决定了能力？”为此，主动的聘方往往会对实习期的员工设置一些更有区分度的任务。比如设置难度更高的项目课题、更紧的销售期限、强度更高的工作时长...对于一个公司来说永远是优先最合适的人选，比如经常有大促的，必然希望员工能承受加班，无可厚非。（如何设置加班费 /调休 /年奖什么的是另一个话题）

----------------------------------------------以下是写给程序员的----------------------------------------

我看了之前那个“因辞退在公司程序留后门”那个贴。觉得 IT 发展那么多年以来，很多的程序员都是比较偏执地看待问题的，包括我自己也是。

我为公司出过力，所以裁我不地道，所以我要留后门。

我认为准点下班是天赋人权，所以所有有加班想法的老板都是黑心老板，有他没我。

我认为我能力比他强，所以学历比较高的他加薪肯定是评优的人食古不化。

肯定不是我的错，是这个大环境的错！

没错，可是那样能改变什么？认清现实运行规则，提升个人的眼界与能力，尝试改变运行规则才是我们该做的。经济没有大变动的情况下，招聘永远是聘方市场，给钱的永远都是大爷，走到哪都一样。大家也没必要为加不加班打嘴炮。少坐电脑旁，多锻炼身体，撑过难熬的打工时期，等你做老板的时候再来开展良好的 IT 日常作息可好？

老大难的问题。

一般来说，比较优的技术评优分两部分，技术内部评分跟行政评分。

技术内部评分由 CTO 制定规范，由 CTO、直属上级、技术评审、自述（以 PPT 或者是其他形式呈现）四个角度综合评价。

行政评分由人力部门制定规范，一般都是硬指标，比如日常考勤、与会考勤、参与活动 /竞赛获奖、对公司重大贡献等等。

但是考虑到一些评优成本，最常见的是无合适的高级技术人才参与技术评审 /大部分人员对于专业技术了解不充分。很多中小型公司都会调高行政评分的比重。

问题不够具体。很难准确地回答。

至少要知道业务类型、消息模型跟消息队列中的消息类型。

针对第一个问题，如果你的业务是 B2C，消息是订单，那你所说的修改集群缓存引起错误就类似于销库存引发的异步问题。那解决方案就可以做得像秒杀系统那样表层响应+批处理+慢反馈。

针对第二个问题，也就是我们所谓的消息积压，更多的是取决于消息的类型（订单之于 B2C 跟状态之于智能硬件，完全是不同的处理方案）。暂时性的资源扩容是必要的，消息超时机制也是必要的，一般都是避开高峰期批处理。不重要的消息甚至可以直接丢弃...

介质前提：
1、存储介质为物质。（先不讨论能量形式）
2、在作为介质的物质上面作的存储为不易失存储。
3、作为介质的物质在几百年内的自然物理衰变所带来的数据影响在存储的容错范围内。

技术前提：
1、存储介质中的数据可任意存取。
2、存储介质中的数据不会被其他以非物质形式存在的外在因素（如电磁）所干扰。

环境前提：
1、人类确保有良好的物理环境 /条件用以保存存储介质。

上面楼提到的石碑在“环境前提”满足的条件下是可以做到的，是比较优的一个方案。

看到这问题，我觉得你并不是很会换位思考。

公司真的需要你去做什么事情吗？它需要你的成果吗？

其实很多工作其实是幌子，我给人安排工作是希望看到这个人的一些可培养的特质。
比如具有独立钻研精神、比如完美融入团队氛围（这个可能是加班）...
如果只是我给你任务就做，下班就走，你能给我什么闪光点？我招一个学历更低、工资更低的人也一样能做到。

实习，本身就是一个推销自己的一个好机会，可能只是你做得太平庸。（不排除公司恶意对待实习生，不过可能性也比较小）

作为一个曾经的科研人员，我不介意有这么一项研究，但是作为立论的人，你得把你的立足点以数据的形式给大家阐述清楚。

20L 提出的：

1、中文的母语地位决定了任何第二语言都很难达到中文水平. 中文命名对代码的可读性提高是可以立竿见影的, 为何不在现在开始呢?
“任何第二语言都难达到中文的水平”这个具体指的是什么，怎么评定一个人的母语与第二语言水平？
“中文命名对代码的可读性提高是可以立竿见影”中的“可以”的前提条件是什么，可行性怎么样。代码的可读性到底怎么衡量？

2、无论有多大, 中文命名可以极大降低这个群体参与开源项目的门槛。
不要以身边的特例来说明，必须有一个足够大的样本支撑这一点，到底“是不是中文”跟“群体参与开源项目的活跃度”的关系是怎样的？

3、随着中文命名的推广, 会有越来越多纯中文接口的框架和工具, 以及使用中文命名的编程教程, 英文在编程学习中的作用会随之下降。
这点仅仅是个人推测。

4、与商业项目类似, 开源项目需要各个方面人才。比如文档 /测试 /追加相似功能等等对开发经验要求相对低于一开始的架构搭建。中文命名可以极大挖掘国内人力资源优势, 与顶楼实例类似, 鼓励更多原本的纯用户加入项目维护的队伍中。
“极大挖掘”这一点同样是臆测。

5、面对面的交流效率永远高于其他形式
“你为什么会觉得集中在一个国家是一项优势”跟“面对面的交流效率永远高于其他形式”这两个说法的因果关系并不明显，请详细描述。

29L 提出的：

1、参考"不利于非中文编程者贡献"一节。
太多的“个人认为”，并无数据支撑。

2、小学生会玩游戏, 就会测试
请举例说明。请说明例子的泛用性。

3、绝大多数国人的母语都是中文. 什么叫"非中文人口"?
文字游戏，答非所问。

31L 提出的：
中文命名应该比能够更恰当更快, 综合各种因素哪种方式写代码更快还待实践证实。
“应当”、“待证实”之类的说明没有必要在此出现。通篇讲可读性的提升，参见 20L 提出的问题。

111L 提出的：
1、中文命名对代码可读性的提高对所有母语是中文的开发者都适用。
请摒除“想当然”，用数据支持你这个观点。

2、成熟的方案现在就有。绝大多数编程语言都支持中文命名. 但很大一部分人没意识到。
“没有意识到”恰恰是方案不成熟的佐证。

3、母语命名的可读性优势与使用何种编程语言没有关系
请说明原因，范围为：“使用何种编程语言”

129L 提出的
个人觉得国内学术界在软件工程应用方面并未对工业界有明显引领作用. 最近看到关注的学生和专业程序员越来越多, 是个好趋势。
我的天，你能去了解一下吗？


在讨论中文命名对于中国开源届的意义的时候，抛开人在使用语言中的一些量化结果是一件很没有营养的事。

几个点：

1、前段的技术合伙人跟后段的放后门的人是不是同一个人，是否有人员重叠？这很模糊。
我去翻了原题主的其他回答，他说合伙人早领股份退出了。文中说的是完完全全不相关的两件事。

2、技术合伙人的合同是怎样子的。非合伙人的程序员合同是怎样子的？事关裁员事件的定性。
原题主说进行了相应的赔偿，那这个应该是正常裁员。

3、程序员留了后门并经过沟通后仍不愿意修复。
这也是原题主提出来的论点：“那个程序员这样做到底有什么意义”。在他的观点里该程序员就是在给他挠痒痒，起不到任何实质作用，反而会惹祸上身。不得不说他是对的。

如何让你的目标受众（小白）知道你的网课的存在？
如何让你的目标受众（小白）知道你的网课确确实实能提供给他们想要的？
如何让你的目标受众（小白）为你的网课付费？

这三点的知识费用可比“ Go 后端编程”知识费用高得多。

F 开头的真言送给他，该硬的时候不要给情面

答案很明显了。

我感叹，现在的资本风气真的很差。真的，你跟人吹情怀吹理想都比吹期权 /股权来得实在。