分类：知乎

http://www.zhihu.com/question/20333552/answer/14812164

评论的文章是：http://meditic.com/degrading-for-success/

穿越文也分高低，高的是大神文，低的是小白文。本文作者写的这篇，最多算是小白爽文，而且有很浓的广告味道。

首先说，为什么这是一篇穿越文。

常见的穿越文，都是从现代穿回古代。主人公带着现代人的历史知识、现代技术、创新思维，总归是有种种好处的。《降级论》的核心论点，也和这个类似。似乎搞IT的，天然就是高智商、高眼光、高品位的三高人群。一旦杀到那些落后的行业，就像是穿越回去一样。

其次说，为什么这最多算是小白爽文。

小白文，通常弱智。作者的见识，往往浅薄。当然，小白爽文，是很好看的。男主人公回到古代，人挡杀人，佛挡杀佛。奇招妙计迭出，对手全是白痴。在他的指导下，科技大跃进，社会大发展，一切就风驰电掣一般的，走向了民族与国家的繁荣富强。

唯一的要求是：读者不要深究。

再其次说，为什么这里面有很浓的广告味道。

因为作者在夸耀自己的成功，用种种不令人反感的方式，在努力的夸耀着。引用一段：

^{作为一个脑残的果粉，我按照iPhone的做工和品质去要求每一张作品，必须达到我们能力可以做到的最好水准，不计成本的最好水准，才允许送给客户。正式接客不到两个月时间，虽然还远未达到成功，但目前已做到每天都有客户订单，财务上已实现盈利，未来相信一定会比大部分app开发者更光明。}

如果真的是不计成本，怎么又说财务上已实现盈利？自相矛盾嘛。

最后说说我的批评：

1. 虽然觉得有些伤人，但是，我的确联想到了另一个寓言故事：井底之蛙。当然，一个看过海的广大的青蛙，回到了井底，并享受着小小的成功和幸福。我们没有任何理由去指责他。但是，当他以自己为榜样时，就显得可笑了。
2. 虽然我也是一个程序员，也认为自己的智商在平均水平之上（也就是超过100的意思）。但是，我没有任何理由相信，自己到了另一个行业，就会比人家更为成功。这种自豪感，固然是合理的。如果上升为“必胜的信念”，就显得可笑了。
3. 虽然IT行业是发展最为快速，理念最为先进的行业。但是，其他行业也有其传承与发展，有其文化与底蕴。冲过来一个热血青年，说：我要改造你们行业。就显得有些可笑了。

太太喜欢和我玩模拟肌肉注射（打屁股针）游戏，每次被“注射”的部位真的会胀痛。这是为什么？
答：这么高的敏感度，可以玩些更刺激的了。。。

喜欢村上春树的《挪威的森林》的读者可能有哪些共同特点？
答：识字

「100%的男人都会出轨」这个说法有道理吗？为什么？
答：如果一个男人还活着，他无法证明自己不会出轨。
如果一个男人死了，别人无法保证他没有出轨过。
所以，楼主你赢定了！

马化腾为什么要来知乎问问题？
答：PR

女朋友经常很厌烦的对我说 我大脑有病，我认为这个词汇很贬义，但她认为就是一句无所谓的口头禅罢了，我们两个孰是孰非？
答：世界观不一致，赶紧分手吧。

得了看知乎强迫症怎么办？
答：你才回答了60个问题，等回答到1000，症状就会逐渐消失了。

每天都打飞机，如何控制自己的欲望不打飞机？
答：不要自己打，找个女朋友帮你打。

如何看待粉丝为艺人张杰募资事件？
答：如果爱，请深爱。
如果粉，请脑残粉。

理性粉丝神马的，实在太违背逻辑了。

有人认为「豆瓣变成了一个约炮平台」，老豆瓣人怎么是怎么看的呢？
答：根源还是在TCP/IP协议上。另外，浏览器也不是什么好东西。

问题的地址在：http://www.zhihu.com/question/20147509

我的回答是：

还是从1949到2009吧，正好一个甲子。

中国人民共和国，是这个国家的正式名称，但是在官方的宣传口径中，常常被称为新中国。在这个 政权最初的六十年中，发生了太多的历史事件，如果将这六十年，放入“1848～2048”这200年中来观察，可以称之为大地震后的余震期。也许到了 2048年，我们才可以小心的判断，余震已经基本结束了。这六十年又可以分为1949～1979，以及1979～2009两个阶段，“新中国”前三十年的 各种怪象，是三百年后的我们完全无法想象的。后三十年间这个国家的各种变化，则几乎都是在人性可以理解的范围，无论是进步还倒退，无论是善良还是邪恶，无 论是无私还是贪婪，都是我们惯常能够体会的人性的一面。虽然在这三十年间，不断有事件的亲历者惊呼：天哪！

http://www.zhihu.com/question/20063807/answer/13871757

我的观点如下：

不明白怎么会邀请我，明显我的资格不够啊～～

随便从一个中国食客的角度来说说吧：

1. 我们去餐馆，是去吃饭，之所以去不同的餐馆，自然是想体会各种不同的口味。打开菜单，挑挑选选，是第一步。

2. 现在的菜单，纯文字的已经极少。图片（最好是彩图），中文菜名，英文菜名，标识主要食材，辣度提示，等等等等，才构成一个菜的完整介绍。

3. 点菜的选择，取决于几个因素：口味（酸、辣、甜）；主食材（牛肉、猪肉、蔬菜）；照片（是不是好看）；菜名（有趣、口彩）；那种无法帮助选择的菜名，或者无法引起联想的菜名，就是失败的菜名。

4. 菜名的另一个好处是，下次再来吃时再点一个。因为上次留下了美好的回味，这回想着再点。那么，菜名是不是方便记忆，就很有讲究。所以我不同意@冷景旭 的观点，那种直接音译的菜名，是不方便外国人记忆的，哪怕有几个特别出名的，可以记住，大多数记不住。难道每次都让人家点“ma po dou fu”？

5. 说个笑话，虽然“fuck goods”绝对是错误的翻译，但是很有可能增加菜的销量。说到底，菜名翻译成什么将有助于销售，对饭店来说才是有意义的问题。文化什么的，真的不用多考虑。

附言：

@冷景旭 说：对菜的介绍部分附加一些中国文化的内容，那么这个菜单会显得更有深度，更加出彩，起码在外国人等菜的时候有个东西可以读一下。

我觉得也是想当然了，人家是来吃饭的，不是来上课的。

后来， @冷景旭 又回复了我的回答：

谢谢你的建议。无法帮助选择的菜名就是失败的菜名，那么，对于外国人的话，菜单上的中文是否也算无法帮助选择的内容呢？

我的这个想法也不是完全为了文化，而是作为一种营销手段，就像在国内一些法餐菜馆一样，很多菜单菜名是中法双语的。法语部分其实不是为了方便客人，而是为了菜单的点缀。
而且像菲力牛排，西冷牛排这样的菜名，他们都是按发音来写的。似乎中国人接受能力挺强的。

2年前，在比利时的一家高档的中餐厅，我遇到了一份异常精美的菜单，像一本书一样。他开头一页是对中国的介绍，后面则是每页一道菜，附上中文菜名，图片，发音，以及对菜的介绍。
我觉得这样一份制作异常精美的菜单实在让我惊艳万分。点完菜后，我还请求把菜单留下，让我多读一下。
这是我为什么会说「对菜的介绍部分附加一些中国文化的内容，那么这个菜单会显得更有深度，更加出彩，起码在外国人等菜的时候有个东西可以读一下。 」

我的回答是：

说实话，你的想法并不错，只是不能推广。有一两家这样的饭店，当然好，要是都这样，也不现实啊。

你举的例子，都是个案，比如寿司，比如西冷牛排，比如麻婆豆腐。但是，中国菜那么多，都这样音译，哪个老外吃得消？

解释一下饭店里菜名的中文，那是为了在国外上中餐馆的中国人看的吧。难道老外都认识中文？

再说说你的惊艳万分，很有可能因为你是个中国人，才那么惊艳。也因为那是个高档餐厅，他们才玩得起。

参考 @冷景旭 的完整观点：

http://www.zhihu.com/question/20063807/answer/13852580

 

 

在知乎上的回答：http://www.zhihu.com/question/20039541/answer/13773509

代码易于维护，分为两个方面：容易阅读理解；容易修改扩展。

一、如何写出容易被阅读和理解的代码

1. 最根本的一条，要向写文章学习，有目录，有大纲，有标题，有段落，有适当的提示。

1.1. 首先是目录结构，这个在一些比较好的实践中，有约定俗成，比如Rails应用，app目录下一定分controllers、models、views、helpers四个目录。再加上config、lib、vender，大致的代码在哪个位置，不用猜都知道。

越是常见的项目类型，越是应该按照约定俗成来构建项目的目录结构，不要别出新裁。

对于没有业内参考的项目，目录结构也尽可能采用简单、易懂、含义固定明确的单词，比如：core、config、test这样的命名。

1.2. 包名与文件名，在这方面，java语言的规范非常值得其他语言参考和借鉴，分层组织，合理命名。是最重要的。

1.3.一个源代码文件里，要不要有注释？我认为，尽可能不要，还是要像写文章一样，让人阅读起来，有感觉。比如：文件名，类名，方法/函数名。如果将所有的实际代码全部折叠起来，顺序的阅读这些名字，能不能让阅读者，对于这一个源文件的内容和目的，有大概的了解？

再强调一次顺序阅读，一个 源程序文件内有很多个函数/方法，这些方法的排列次序，是有意义的。仅仅依靠调整次序，比如：构造函数，扩展构造函数，简单的读写函数，业务相关的函数。以这样的次序来排列，会更加便于阅读。

在必须写注释的地方，也不要写得太多，言简意赅，把要点用1.2.3.讲清楚。

1.4. 变量名，常数名，我们必须一再一再的强调命名的重要性，可以说，命名是软件开发中，头等重要的大事。要简洁、清晰、全英文（决定不要汉语拼音、任意缩写）、尽可能不要夹杂数字，比如var1、var2这样的变量名，就是最糟糕的。

2. readme

在项目开发的过程中，定期整理一份readme，放在项目的根目录，主要包含两部分内容：我们的代码做了些什么？如何查找我们写的代码。

3. wiki

团队开发，尽可能维护一份wiki，自己架一个mediawiki或者其他wiki，都是很简单的。或者自己架一个redmine这样的集成项目管理工具，该有的就都有了。

wiki的管理维护是一个很大的话题，这里就不再展开了。

4. 单元测试

@李楠 和@KevinWei 已经提到了。 这个办法，既方便阅读理解代码，也方便修改代码。非常重要。

5. Code Review

@KevinWei 也已经提到了。

二、如何写出容易被改写和扩展的代码

1. 单元测试，最好全过程采用TDD（测试驱动开发） 

这样才能让人有信心修改你的代码。

2. 参考业内成熟实践与设计模式

这个事情，要多讲一句，千万不能过头。为了追求可扩展性，可重用性，甚至仅仅是为了玩弄设计模式，会让一个项目成为过度设计的牺牲品，千万不能过头。

3. 定期重构

一上来就向设计模式靠拢是很危险的，重构时以设计模式为参考会好一些。但是，大多时候，我们没时间重构。。。

所以，还是TDD最实在，按照TDD的工作模式，你的项目几乎每天都有大大小小的重构。

4. 结对编程

这个@李楠 已经提到了。让知识在团队中不只是一个人掌握，很重要。

大概就是这些吧。。。

 

这个问题是我提出的，其实也有想要总结一下自己思路的意思。我的初步的思考如下：

 

1、后端开发，最重要的挑战，来自于规模

 

规模的扩大，比如访问量扩大，文件存储量扩大，数据量扩大，服务器数量扩大，等等等等。

 

一个前端看起来一模一样的网站，某一种指标如果扩大十倍，几乎都会面临一大堆的问题和挑战。之前@徐湘涛 有一条微博，但是我现在搜不到了，大意是，一个系统，从小到大，仅仅在数据库方面，就要经历多次的拆分，横切、竖切，种种演进。总之是一路荆棘的过来的。

 

另 一方面，在规模扩大以后，后端系统架构，一定会复杂化。原来只有一台Server，LAMP都装在一起。然后数据库分出来，反向代理，负载均衡，分库分 表，Memcache，Message Queue，事务处理，CDN，NOSQL，种种架构，Server，就逐渐的演化出来了。

 

架构的复杂化，自然会带来更多的问题和更多的挑战。

 

2、第二大挑战，来自于安全

安全问题层出不穷，防不胜防。需要技术手段，也需要管理制度。这方面我也不甚了了，期待更加资深的人来解答。甚至单独开一个问题：“网络安全方面主要的挑战有哪些？”都是一个很大的问题。

 

3、第三大挑战，来自于效率

能否提供足够的处理速度，能否提供足够的带宽，能否保证响应能力。这些是对外的效率。

能否使用更少的服务器，能否使用更加便宜的服务器，能否使用更加节省能源的服务器。这些是对内的效率。

 

4、第四大挑战，来自于需求变更

当然，无论前端后端，都会面临需求变更，只要是软件开发，这都是大挑战。但是当一个系统已经 稳定的，高效的运行着的时候，需求变更来了，在满足需求之后，原来的本来没有问题的部分，会不会突然崩溃，一旦崩溃，就是后端工程师的噩梦。

 

从 这个角度来说，后端工程师，会更加抵触变更。一个系统只要是好好的运行着的，最好就不要去动他。CSDN密码泄漏之后，@Tinyfool 写了一段话，我认为非常有道理：“技术界有一种哲学叫做，系统如果还可以运行就不要修改它。这种哲学我一直反对，但是没有可靠的证据。CSDN这次是一个 非常好的证明，如果前年有人在CSDN内部说，咱们的数据库密码是明文，改了吧，也许有人会反驳都多少年没出事儿了。所幸现在出事儿了。”

 

但是，我真的非常理解那些不想变化的心态。虽然他们是错的。

 

5、第五大挑战，来自于教条

这个世界上有无数IT大公司，他们都很开放，都愿意分享自己的架构与技术。于是，对于“眼界开阔”的后端工程师而言，困难不在于如何解决，而在于如何从众多的解决方案中做出挑选。框架、实践不断涌现，成功案例也不断涌现。人家都用得好好的，你敢用吗？

 

到底是勇于尝鲜，还是保守要紧呢？这个很难。

有一个被折叠起来的匿名用户的答案，很有代表性。典型的：振振有词，却不能反思的人。

1、从个人经历来说，任何人都可能会经历：看上去毫无前途的工作。

2、从成功失败的分水岭来说：所有的loser，都是只会抱怨，却不会在逆境中成长的家伙。

3、 从公司来说，付出一份工资，换取一份劳动。如果能够招到成长快速的员工，能够有能力承担越来越多的份外的工作，所有的公司都会感到幸运。厚道的公司，会给 他升职加薪，不厚道的公司，至少会分给他更多的工作。如果楼主在很长的一段时间没有感到自己的工作变得越来越多，越来越重要，那么，抱歉，你就是个 loser。

4、跳槽我当然不反对，人往高处走是天然合理的。但是，如果你现在的公司，都不能越混越好，很大的一种可能性是，loser走到哪都还是loser。所以，在跳槽之前，先混到升职加薪，至少先混到升职，再以更高一级的身份跳走。这样也光彩一些。

5、仅仅说楼主目前的这份工作，其实很有意义。发贴回复，一点都不简单，有很多值得深入学习的地方。如果你觉得学不到东西，那么抱歉，你是个loser。

说说我的开源学习经历：
1、下载源代码之后，首先要跑起来。编译通过、正常运行。
2、在你觉得最有可能的运行到的地方，设置断点或者抛出异常，这样，就能够找到一个项目在正常运行时的入口点。
3、从入口点所在的那个源文件开始阅读，逐步把握整个项目是如何启动起来的。
4、随便改点代码，看看会不会报错，如果报错，会从哪里报错。
5、试着把报错屏蔽、修复、或者绕开。
6、尝试理解一个系统的内部结构，多少组成部分，主线模块是哪些？辅助模块是哪些？
7、从实际需要出发，修改这个项目，满足自己的某一个小的需求。

在此之前，尽量不要在网络上找答案。

8、看看相关的讨论与心得，看看是否与自己的理解相一致。
9、提交bug fix或者某个新的功能代码。

在学习开源的过程中，有几个方面，会获得大量的收获：
1、架构与模式
2、开源社区常见的一些惯用法
3、相关领域的结构与算法

总结一点是：学习开源，就尽可能在代码里找答案，而不是在代码之外找答案，那些都是二手的，而且很可能是不准确的。