作为程序员，坚持不懈的学习，难道不累吗？程序员面试真的是“面试造火箭，工作拧螺丝”吗

本文目录

• 作为程序员，坚持不懈的学习，难道不累吗
• 程序员面试真的是“面试造火箭，工作拧螺丝”吗
• 程序员是如何看待“祖传代码”的
• 为什么程序员会有代码能跑就不要动的观点
• 在软件外包公司干了一年，离职的时候发现自己的代码有漏洞，怎么办
• 哪段代码最能代表程序员的暴力美学
• 成功重构了代码是种怎样的体验
• 游戏程序员是如何看待“祖传代码”这一说法的

作为程序员，坚持不懈的学习，难道不累吗

作为一名IT行业的从业人员，主要在从事产品研发及项目管理工作。所以我来探讨一下这个问题。

借用一句戏言“十年生死两茫茫，写程序、到天亮，千行代码BUG何处藏，纵使上线又怎样、朝令改、夕断肠”。作为一个程序员，真的要这么辛苦吗？他们日复一日这样工作真的不会觉得累吗？

互联网时代背景下，学习思维和学习方式需要改变了！

在传统的教育背景下，我们的知识来源只有学校、课本等等极少的方面。但是在互联网时代背景下，我们获取知识的途径在不断的增加，同时获取知识的范围也是在不断地扩大。没有学不会或者学不到的知识，只是你自己不去努力学习或者方法途径不对。所以，并不是程序员要坚持不懈的学习，而是想要获取更多的价值都要去学习。

互联网时代背景下，IT技术日新月异

技术革新的步伐正在疾速加快，软件行业的技术更新换代比较快，从事软件相关工作的人要时刻关注新技术的诞生和发展，以求紧跟技术潮流。

遇到新技术我会去了解，但不会把很大的精力放在这些技术上。有人说技术更新换代很快，我不觉得是这样想。虽然有不成熟的技术不断地涌出，但是成熟的技术，比如Unix、C、C++、TCP/IP、JAVA……，如果你着眼成熟的技术，其实并不多。

兴趣很重要

总之一句话——如果你没有兴趣，什么都是借口，如果你有兴趣了，什么都是好玩的。

如果我能长期地坚持去做一件事，一定是这件事带给我满足感，一定是这件事唤起了我内心深处最强烈的兴趣。

程序员面试真的是“面试造火箭，工作拧螺丝”吗

这是门槛问题。

比如头条，面试必考算法，不刷300道算法题，你进不去。

至于BAT，面试同样严格。

根本原因1，是因为雇佣关系，程序员太多了，公司太少了，僧多肉少，没办法。

根本原因2，会得越多，哪怕进去写增删改查的代码，也会考虑很多意外情况，保证代码的高可用性和性能。

应届生也可以写增删改查的代码，如果没人审核，可能在特定情况下，bug会更多。

如果你是面试官，你肯定会招人特别严格的，不严格，就容易留坑。

程序员是如何看待“祖传代码”的

如果外行人听到“祖传代码”这四个字，会不会以为是前辈们留下来的珍贵财富；其实这是程序员最怕遇到的代码，不敢动，一动改半年。

这种代码通常的几个特点：

1. 没有注释，没有文档，没有测试用例；

2. 逻辑堆在一起，并且已经没人知道作者的想法；

3. 功能比较关键，也挺好用的，运行比较稳定，就算有点儿问题，影响也不是很大；

4. 很关键的一点，不能轻易修改，可能会产生不可预料的问题。

• 单位另外一个项目正在做老系统的升级，准备新做一套系统把功能实现；在翻老代码的时候，有一个方法各种if-else的判断，并且10个产品，有6个已经停售了，正常情况应该把相关的逻辑都摘出来扔掉，但是...没人改动，不知道对现有产品的逻辑产生影响；只能把原逻辑搬过来，未来新产品上线写新的逻辑，等待当前产品逐渐下线，完成代码的替换。

• 有网友曾发现了微软的祖传代码，在看一段内核内存管理的代码，发现循环多调用了一次，然后给当时Windows内存管理的大牛写信询问此事，很快得到回复：“It is a bug since day 1.”

• 在一些单位，祖传代码是保住饭碗的工具。一网友刚进单位的时候，发现一些代码的逻辑写的很绕，把代码写的极为复杂，后来发现负责的模块比较稳定的人都被fire掉了，于是才了解前辈们的用心良苦。

• 面对祖传代码，每个接手的程序员都会选择绕开，没有谁会鼓起勇气去解决，毕竟谁也不想自己掉到坑里。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

为什么程序员会有代码能跑就不要动的观点

干这一行的老兵都知道，稍微上一点规模的代码库，都是很复杂的，多年积累下来的各种奇奇怪怪的需求，导致了各种代码补丁和Hack，这些复杂度是外行难以真正体会的，在这种复杂度下，看起来人畜无害的一个修改，很可能导致连锁反应，然后代码屎山会爆炸的！

但不全是坏消息，好消息是——软件这玩意没有磨损！

换句话说，只要软件现在能运行，在外界环境不干扰的情况下，软件会持续运行下去！

就拿网上这张著名的图来说，大家很可能觉得这真是凑合，因为这个红绿灯已经坏了，不去修的话，风吹雨打，最后红绿灯肯定会彻底坏掉的。

但是，在软件的世界里，和硬件不一样，软件是没有磨损的，管他风吹雨打，软件还是一样的0-1序列，硬件坏了，换一个同样规格的硬件就是了，软件继续运行。

所以，真的，只要代码能跑的起来，能不动就不要动了，此乃经验之谈！

来自：程墨Morgan

在软件外包公司干了一年，离职的时候发现自己的代码有漏洞，怎么办

从职业道德来讲，可以把这些漏洞信息说给你的交接人或者上司，有句话叫好聚好散，可能很多人都会觉得已经离职了，干嘛还要多此一举，离开已经和你没有任何关系了。混职场其实和做人一样的道理，人都会走背字的时候，不要时时刻刻把自己的路给堵死了，留下一个良好的印象对于别人和自己都是一件很愉快的事情，这个世界上虽然看上去很大但凑巧的事情的确很多，算是给自己做个积德的事情。

从代码的角度来讲，自己认识到出现问题了，及时的去修正也是作为一个程序员的基本素质，一般的老程序员都有这种感受，之前写的代码重新拿过来再去研究发现又会有新的知识点，每隔一段时间去审视下代码几乎每次都有一定的感受，其实这就是编程水平不停提高的一种表现，如果自己本身发现了代码的漏洞，证明了自己的理解又上了一个台阶，是一件很不错的事情，如果这个漏洞告诉了交接人，也算是给自己的代码一个圆满的归宿。

在实际写代码过程中如何减少代码漏洞的出现，作为一个写了十几年代码的老程序员总结出以下

四种解决方案：

1.在模块设计之初，就要把里面的来龙去脉搞清楚，数据结构的设计上一定要留出足够的时间

2.在写代码之前就要把可能会出现的漏洞在自己的大脑中过滤一遍，避免低级的错误出现。

3.写过的代码模块一定要加上单元测试，来测试代码的稳定性

4.写过的代码最好找个水平相当的帮你审核下，看看有没有明显的漏洞

基于以上四点能很好的避免出现代码的漏洞，要想写的代码一点漏洞也么有不是一件现实的事情，所以代码漏洞主要影响因素，一个是基本功，一个是框架思想，设计的模块就容易暴露漏洞，所以相对来讲有经验的老程序员代码的质量会高很多，熟能生巧，多看多练才是关键。

希望能帮到你。

哪段代码最能代表程序员的暴力美学

猴子排序算法

在计算机科学中，猴子排序（Bogo 排序，bogo-sort）是个既不实用又原始的排序算法，其原理等同将一堆卡片抛起，落在桌上后检查卡片是否已整齐排列好，若非就再抛一次。其名字源自Quantum bogodynamics，又称bozo sort、blort sort，与无限猴子定理有共通之处。

无限猴子定理：让一只猴子在打字机上随机地按键，当按键时间达到无穷时，几乎必然能够打出任何给定的文字，比如莎士比亚的全套著作。

猴子排序的Python实现如下：

from itertools import izip, tee

from random import shuffle

def in_order(my_list):

it1, it2 = tee(my_list)

it2.next()

return all(a 《= b for a, b in izip(it1, it2))

def bogo_sort(array):

while not in_order(array):

shuffle(array)

也就是把一个列表不断随机重新排列，然后判断是否已经排好顺序了。如果不是，继续循环，重新打乱顺序。

猴子排序算法极为暴力，通过对所有可能排列进行随机抽样来达到排序的效果。同时其思想简洁而富有哲学意义，具有独特的美学。

成功重构了代码是种怎样的体验

结果很愉悦，过程很痛苦。

小编有过几次成功代码重构经历，借此分享给大家希望能给大家一些启发。

重构之前有几个问题必须要考虑清楚。一是为什么要重构，二是重构后能达到什么效果，三是重构能否被团队支持。

为什么重构？

大多数软件项目初期是先实现功能满足客户需求。随着功能的累加，系统的扩展性变的越来越差，直至看似很简单的功能都无法实现。这个现象估计朋友们都遇到过类似经历，心里也会默默念叨“这是什么破玩意，这么简单的功能都不具备”。上述情况是典型的缺乏设计经典案例。

缺乏设计在程序员层面的体现是架构不明显、逻辑不明了、代码不清晰。随着时间的推移，人员的更替，造成这些代码无人能懂，出现问题不知从何处下手改动。处理过这类祖传代码的小伙伴，常常感慨找出如何修改，比自己写一遍的时间都长。

缺乏设计在用户层面的体现是用户体验差，增加功能难。常表现为反人类思维的操作步骤，简单的功能迟迟无法实现。进而觉得程序员业务不懂，技术也不咋滴。程序员也不是不想接受需求，而是不知道如何应对需求。老虎吃天无从下口的感觉，让人非常煎熬。

到了这个程度，就像堆积木一样，基础没打牢，任你多大能耐也很难继续下去。怎么办，唯有重构可以解忧。

重构后能达到什么效果？

重构是需要魄力，无论是人力还是物力的投入都涉及到白花花的银子。重构之后能达到什么效果，也就是愿景是重重之重。

确定好项目的架构及技术路线，然后在此基础上构建适合自己的开发框架，最后制定严格的开发规范。

优秀的架构、技术路线能增加用户体验，提高程序的可扩展性。架构和技术的原则是选熟不选新，同时既要确保先进性也要具备前瞻性。

构建适合自己的开发框架，最大的好处可以提高开发效率。软件项目响应客户需求的速度，有时比功能的完备更重要。很多时候功能是有毛不算秃。写到此处情不自禁摸了摸自己的脑门那几根稀疏的头发。

严格的开发规范，无疑是增加代码的可读性重要的法宝。减少项目成为祖传代码的几率，是利在当今，功在今后的好事。

构思好之后，把自己的想法写下来，并能给大家讲明白。能付诸行动才是成功的前奏。在实施过程中，不断修正瑕疵之处逐步迈向成功。

能否被团队支持非常重要。

前面说过重构耗费人力物力，征得老板支持是实施的准入证。

重构是不产生直接生产的，还要额外学习新的技术，会影响个人KPI。有人提反对意见，也有情可原。

与人打交道，沟通协调最重要。程序员最怵头的事情没有之一，这也是为什么单独列出这一条。

结语

世上无难事，只怕有心人。做好规划，认真执行，胜利就在前方向你招手。

游戏程序员是如何看待“祖传代码”这一说法的

亚马逊的工程师形容说他们的代码:“一座很大的屎山，你见过的最大的山，每次你想修正一个bug，你的工作就是爬到屎山的正中心去”。

刚入职的时候，熟悉项目代码，经常碰到各种奇形怪状的代码，有且不限于：各种进不去的分支，各种奇葩逻辑，各种风格不统一的编码风格，各种我也形容不上来但是看着很蛋疼的代码。。。每当问起老员工这里为什么这样实现时，他都会漏出一副深邃的表情：别问我，我来时就这样了，历史遗留问题。。。

至于如何对待，我举个例子。我们代码中有一行代码，在一个奇奇怪怪的地方设了个奇奇怪怪的标志量，然后后面一个注释：

// 位置不能动，不然时序就都乱了。

作为一个萌新我当然乖乖滴没去动它，直到有一期新需求，这个标志量的位置出现了点小问题，然后我就尝试性地把这句话往后挪了一小下，然后程序从头错到脚指甲。在体会到前辈的用心良苦后，我又在那个注释下面加了一句：经验证，真的不能动。。。

希望对你有帮助