程序员写出烂代码

A. 你们是怎么看待那些动不动就说别人代码很乱的程序员

可以把这个作为互相交流的契机，既然他觉得乱，你就跟了解清楚为什么觉得乱，怎么才能不乱，说不定他说的有道理，你就能学到东西了，如果他说的不对，就用疑问的方式委婉地提醒他一下，如果他还是那样，就随他去了，他的观点不重要，又不会影响到什么的话，听听就好。

B. 有哪些新手程序员该知道的工作小技巧

1.积极大胆的谷歌。你得知道如何有效的组织搜索关键字，查阅别人写的代码，然后合理地用在代码里，从而解决问题。

2.拥抱变化，坚持不懈。老手程序员在接触新技术时，能欣然接受像个初学者一样处处受挫，并总能在完成工作的同时自学成才。

3.承认细节的重要性。例如变量和函数的命名、CSS属性的命名、该用哈希还是数组，以及其他看起来微不足道，但可能对项目有深远影响的事情。

4.承认大多数的“重要决定”其实并没有那么重要。一般的开发者经济常在技术选型等“重大问题”上陷入唇枪舌战，而程序员老鸟们会避免浪费时间在骂战中。这一点上，它们就像禅宗大师一样。

5.选择合适的工具解决问题。网上有无数的开源库、工具和框架，让人眼花缭乱。而老手们清楚地知道针对怎样的问题，应该用怎么样的工具。

6.明白代码“不值钱”（该删就删）。你必须习惯于删掉几百行代码来重写程序的某一部分，毫不留情。

7.在评估技术的时候要全面。例如，我一直在鼓吹Elixir。它语法优美，社区完善，有很大的潜力。但Elixir诞生的时间太短，所以如果要构建复杂的功能，可能会难以找到能帮你提高效率的开源工具。因此，在评估要不要选择使用一项技术时，你得把所有这些因素都考虑在内。

23.知道什么时候开始回馈。到了某个时候你需要将你的技能和经验传授给年轻的开发人员，就像你的导师当时教授你一样。

24. 能写烂代码。有时候可以当一当“胶带式程序员”。关键是随着时间推移，你需要弄清楚什么时候可以走捷径，什么时候必须走捷径。这其实是最难掌握的技能之一。

25. 礼貌地告诉别人你工作到很晚。如果你是办公室里最后一个，可以发一封简短的汇报邮件。别人一般会注意到邮件上的时间戳的。

26. 像一个领导者(Leader)一样做事，而不是老板(Boss)。老板是让别人为他工作的人，领导者是人们追随的人。做个领导者。

27. 去打打桌上足球。从长期来看，同其他开发者（或不同岗位上的同事）建立联系比在紧巴巴的期限里交付一个功能更有价值。

28. 在压力下学习。你需要知道如何应对像系统宕机而你要负责将它复原的情况，即使一开始你完全没有头绪。

C. 如何看待程序员日均写7行代码被开除，大家对此事件有什么想说的呢

不是我不明白，这世界变化快。俺当年入职时，一些公司的确会问代码量。当时的标准大约是每周40到400行代码，可以少，但不能多——换句话说，平均来说，每周多于400行代码的可能得不到工作机会。因为你的代码质量和工作态度让人家心里发毛。当然，也没人太较真。功能点完成了、代码质量可以（bug少、代码逻辑清晰、文档齐全），多点少点无所谓。

先后在多家公司担任技术专家；平均来说，每周代码量也就200行上下。当然，也搞过一次一天写了2000行代码的壮举，结果是之后一个多月脑袋嗡嗡响，眼花，恶心。这个东西我事先花了一周多做设计、写文档，然后第二周的某天一气呵成，写完bug；然后累伤了，一个多月没法工作。换句话说，相当于还是花了6周；平均下来，仍然是每周300来行代码。

公司在与李某某签订劳动合同时并没有约定一定要进行深度学习识别算法代码编写，3D点云算法和多摄像头联合算法代码编写的具体工作内容，所以没有指明非要编写这些代码；拿什么同级别同行业的平均每日编写代码的统计数据来作为考核的依据，没有法律根据，任务不同，编写难度不同，不能以编写条数作为考核的依据；

至于工作内容，作为程序员并一定非要整天的在编写代码，也有可能在设计新的方案，或是对数据进行统计分析和总结等，不能以什么编码工作没有做，就认为李某某没有做出“成绩”；作为刚来才两个多月的程序员，前期的准备和熟悉是需要一个过程的，随着对公司的熟悉和项目的了解，编写代码的速度必然会提高，而不能在刚来两个月就以其他老员工的标准来进行考核；在发出解聘通知书后，马上将其办公电脑进行收回，这是严重的不尊重人，这属于单方面强制辞退，没有给李某某一点申辩的余地。以上，公司理应对李某某进行赔偿。

D. 你的代码出bug了，程序员听到这个时的表现太真实了

这个大撒比写出这么个烂代码，幸亏有哥这样神一样的存在才发现，哥真是救世主。

这个程序运行很久了是不是真有bug啊，是不是你弄错了啊，可以重现么，什么？可以重现，有尼玛问题也不大，要不用户早投诉了，瞧你那惊慌失措的样子，真想吐你一脸狗屎。

这个bug隐藏的很深啊，还好哥犀利犀利，没有被领导发现，今晚加个菜。

这个程序刚上线还处于调试阶段，有bug很正常，谁的程序没bug，连操作系统都有bug。

哥就是犀利，自己开发自己测试，看测试那帮撒比什么也不会干，这么明显的bug都测不出来，真是一群废物。

1、“是删除它还是修改它呢？好纠结 ！”

2、网上一定有解决办法。

3、是谁动了我的代码？

4、完全不知道这些代码是神马东东。

5、哦，为什么我都没写注释呢？

6、算了，废了他，我还是从头开始吧！

程序员自身可以在程序生成的每个阶段做这些工作： 仔细的设计、编写代码时、单元测试(重要)、功能测试。

E. 作为一个程序员，面对别人写的稀烂的代码，怎么办

在查阅代码时，经常会发现一些写的不合理的代码。
面对这些代码，首先需要确认修正这些代码的影响范围。

最理想的处置是对代码进行重构，从根本解决代码的混乱问题。
但是大多数情况，我们没有时间进行重构，或者无法确保重构之后的代码不会出现问题。
建议先解决最棘手的问题，然后慢慢对代码进行分析，重构。

F. 历史上有哪些因为程序员写出的bug而造成的事故

1. 火箭爆炸，原因：类型强转（64b浮点->16b整数）导致异常
2. 火箭爆炸，原因：Fortran代码笔误（少一个减号）
3. 火星车故障，原因：vxWorks优先级逆转 -
4. 火星探测器坠毁，原因：用错计量单位（磅与牛）
程序员导致的事故挺多，这些是严重点的。还有游戏更新把用户电脑上文件删光的...

G. 编程老手的哪些特点，是值得新手程序员学习

1. 活跃斗胆地谷歌。你得知道怎样有用地安排查找要害字，查阅他人写的代码，然后合理地用在代码里，然后处理疑问。
2. 拥抱改动，持之以恒。内行程序员在触摸新技能时，能欣然承受像个初专家相同处处受挫，并总能在完结作业的一起自学成才。
3. 供认细节的首要性。例如变量和函数的命名、CSS 特点的命名、该用哈希仍是用数组，以及别的看起来微缺乏道，但也许对项目有深远影响的作业。
4. 供认大大都的 “首要抉择” 本来并没有那么首要。通常的开发者经常在技能选型等 “严峻疑问” 上堕入唇枪舌战，而程序员老鸟们会防止糟蹋时刻在骂战中。这一点上，他们就像禅宗大师相同（zen-like）。
5. 挑选适宜的东西处理疑问。网上有很多的开源库、东西和结构，让人目不暇接。而内行们了解地知道关于怎样的疑问，应当用啥样的东西。
6. 了解代码“不值钱”（该删就删）。你有必要习气于删掉几百行代码来重写程序的某一有些，毫不留情。
7. 在评价技能的时分要悉数。例如，我一向在宣传 Elixir。它语法美丽，社区完善，有很大的潜力。但 Elixir 诞生的时刻太短，所以假如要构建杂乱的功用，也许会难以找到能帮你行进功率的开源东西。因而，在评价要不要挑选运用一项技能时，你得把一切这些要素都考虑在内。
8. 学会说 “我不知道”。没有比回绝供认自个不知道更能糟蹋一个开发者的时刻了。
9. 细心剖析过错信息里的条理。传统教育通知咱们：失利是坏事。报错信息这种东西也经常被跟失利联络起来，但是优异程序员了解，这些过错音讯里本来隐藏着能将你指向终究准确处理计划的条理。
10. 了解过早优化和必要的 “炫技式” 优化的区别。内行们了解在啥时分需求写一些看上去没那么好懂，但会让程序运转更快的代码。
11. 每自个都会犯错，为自个的过错担任。而格外在团队里，把职责推来推去没有任何含义，由于过错的发作通常不只仅一方的要素构成的。
12. 变成你所用的开发东西的重度用户。假如长时刻在某个开发环境下有恰当份额的开发作业，那你应当去把握运用它的细节。
13. 学会用 Vim（最少会一点）。 你最少应当在这个修改器里学会牵强地移动和翻页。
14. 不要接生疏技能范畴的私活。自个做自在作业项目，其间很大一有些应战即是评价项目时刻。不要计划自个未知范畴的作业，那会让你处于想当为难的地步。
15. 不要数你干活花了几个小时。技能大牛会把时刻花在有深度的作业上，并且他们了解花了多少时刻彻底不首要。
16. 学会安然承受批评。当你的代码由于各种要素支离破碎时，你需求培育用理性和逻辑的办法来应对（而不是心境化处理）。
17. 同有更多阅历的人结对编程。没有比这个更高效的编程学习办法了。
18.必定要先自个做一遍代码检查。当你在 GitHub 上建议一个 pull request 之前，先把代码当成他人写的，自个先检查一遍。
19. 认识到做自在作业的难点不是写代码，而是别的的一切作业。出售、推行、客户支撑，质量确保以及产品处理，一切这些都会花费很多时刻。
20. 发现并处理更大的疑问。优异的程序员不拘泥于眼前的疑问，而是了解怎样用更久远的办法彻底的处理这一类疑问。
21. 深化了解一些大型开源项意图基地能让你开发时如虎添翼。假如你知道怎样给你的项目打山公补丁 (Monkey Patch), 那么你将无所不能。
22. 越过大都的会议。你的公司雇你是来写代码的，而不是谈代码的。当会议多到失控的时分，不去参与也没有任何疑问。并且一旦你开端这么做，他人会更爱惜你的时刻。
23. 知道啥时分开端回馈。 到了某个时分你需求将你的技能和阅历传授给年青的开发人员，就像你的导师其时教授你相同。
24. 能写烂代码。有时分可以当一当 “胶带式程序员”。要害是跟着时刻推移，你需求弄了解啥时分可以走捷径，啥时分有必要走捷径。这本来是最难把握的技能之一。
25. 礼貌地通知他人你作业到很晚。假如你是作业室里终究一个，可以发一封简略的报告邮件。他人通常会留心到邮件上的时刻戳的。
26. 像一个领导者 (Leader) 相同干事，而不是老板 (Boss)。老板是让他人为他作业的人，领导者是我们跟随的人。做个领导者。
27. 去打打桌上足球。从长时刻来看，同别的开发者（或不相同岗位上的搭档）树立联络会比在紧巴巴的期限里交给一个功用更有价值。
28. 在压力下学习。你需求知道怎样应对像体系宕机而你要担任将它恢复的状况，即便一开端你彻底没有条理。
29. “Move fast and break things” 别让完美主义阻挠你干事。过错通常是最好的学习时机。所以别把犯错当作失利，而应当把它们当作值得学习的阅历，并意识到：恰是不断战胜和打破这些过错，作为一个程序员，你才干不断生长起来。

H. 为什么有的程序员的代码结构混乱

程序员都有一颗工程师的心，所以当他们到一片新的场地想做的第一件事就是，将旧的一切推倒重来。是的，他们决不会满足于简单的增量劳动。

或许这种微妙的心理定位可以解释：为什么程序员进入新项目组后宁愿丢掉旧代码重新写，也不愿意修修补补。他们认为旧代码简直一团糟。

但是，事实上真是这样吗？你之所以认为旧代码一团糟，其实是由编程的一个基本定律决定的，那就是：写代码容易，读代码难。

为什么你觉得旧代码异常混乱？因为读代码更难。

这大概就是代码Reuse难以实现的原因。 这就是你组里的每个人都喜欢用不同的功能将分割的字符串转换成一个数组。比起猜测旧的功能是怎样实现的，重新写一个自己的功能要简单和有趣多了。

作为这个公理的推论，你可以问问身边的程序员他们正在奋战的代码怎么样？“简直是一塌糊涂！”他们肯定会这样说。“我简直想推倒重来！”

为什么认为代码这么糟糕呢？“额，看看这个功能，竟然有两页长！完全不知道这些东西为什么在这里！完全不知道这些API是干什么的。”他们会这样回答你。

漫画：读别人代码是一种怎样的体验？

曾经，Borland的创始人 Philippe Kahn当初就是向记者们吹嘘：Quattro Pro会比Microsoft Excel要好用得多，因为它是从头开始编写的，全部都是新的源代码！

但是，认为新代码比旧代码好简直就是荒谬。旧代码是已经运行过的，测试过的。无数的bug在被发现前都上线运行过，发现之后程序员们可能在花了好些日子才修复了这些bug。这种修复可能是一行代码，也可能是几个字符，无数的时间和精力都花在了这些bug修复上。

当你决定抛弃这些旧代码从零开始的时候，你也丢掉全部前任努力的结果。

新代码一定比旧代买好？NO，重写可能会带来更大的风险。

对技术领导者来说，重写项目的代码也是一个异常艰难的决定。因为从公司层面说，重现代码甚至会威胁产品的市场竞争力。一旦决定重写代码，那么与竞品相比，你可能落后了2~3年——在软件行业，这时间可够长的。

你理想中的新代码会带来产品功能的提升▼

但事实上，即便重写的新代码可以实现旧代码的所有功能和需求，但是为产品带来的市场竞争力只有边际提升。因为重写用的新技术、新语言、新框架并没有给产品带来质的飞跃。

更不用说在重写的漫长过程中可能会遇到一些意外情况，比如：

1、缺钱：资金链的断裂▼

2、缺人：核心程序员离职

最终导致效果不佳：达不到原产品应有的所有功能和需求，白白浪费了时间和金钱，也丢掉了市场竞争力。▼

所以重写代码意味着，你在把自己置身于非常危险的境地，可能几年后你也写不出比以前更好的代码。你只是花了一大笔钱把已经存在的代码又写了一遍。

当你觉得眼前的旧代码很烂时，该怎么办？

你觉得旧代码写的很烂，那又怎样呢？它们已经上线，已经在实际运行中经受住了考验。所以当你发现前任留下的代码乱七八糟的时候，不妨冷静下来，从以下三个方面入手理解代码、改善代码：

1、代码的结构有问题

如果一段网络代码突然弹出了自己的对话框，应该是UI代码需要被处理。这些问题可以被解决掉，你要一次次小心地移动代码，重构，改变接口。还需要一位细心的工程师立马仔细地检查这些改变是否有问题，从而不打扰到其他人。事实上，甚至比较大的结构变化也可以不扔掉代码来完成。

大牛程序员Joel Spolsky回忆说，曾经在某个项目中，他和他的团队花了好几个月重新架构在一点上：把代码动来动去、清理、创建有意义的基类，并创建了模块之间的完美接口。但是他们始终非常小心翼翼，并没有产生新的bug、也没有丢掉任何旧代码。

2、代码的效率不高

曾经，Netscape的渲染代码被传非常缓慢。但事实上，这只会影响该项目的一小部分，这部分是你可以优化甚至重写的。你完全不必重写全部代码。优化速度的1％工作量，会让你获得99％的爆炸性提高。

3、代码写得很丑

有些代码真的写的很丑，比如Joel曾参与一个项目，开始用下划线做开始的成员变量约定，但后来改用更标准的“M_”。所以一半的功能用“_”开始，一半用“M”开始，这看起来真的很丑陋。但这个问题5分钟就能解决，而不用从头开始写全部的代码。

最后，你要记住，从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建，所以你其实根本就不算有经验。一旦你准备推倒重写，你可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。

一个总结：

面对糟糕的旧代码，Keep Calm & Carry On !

在大型商业项目中，推倒重来是非常危险的行为。当然，如果你是在做实验，想到新算法可以随时重写。