shengxiaweizhi的专栏

每次我发布软件工程师的岗位工作要求，各种求职申请就会纷至沓来，接踵而至。但每每让我困惑的是，似乎总有那么几位应聘者完全不明白所谓“编程”的意思。　　当然，他们另有想法。　　而我认为，如果你应聘的是“Web前端开发”岗位，那么你只懂jQuery也可以胜任，那么，“软件工程师”是不是就意味着会HTML、JavaScript和CSS这些必备技能就行了呢？　

你有个任务，需要用到某个开源项目;或者老大交代你一个事情，让你去了解某个东西。怎么下手呢？如何开始呢？我的习惯是这样：    1.首先，查找和阅读该项目的博客和资料，通过google你能找到某个项目大体介绍的博客，快速阅读一下就能对项目的目的、功能、基本使用有个大概的了解。    2.阅读项目的文档，重点关注类似Getting started、Example之类的文档，从中学习如何下载、安

通常工程里不推荐自己写内存分配器，因为你费力写一个出来99%可能性没有内置的好，且内存出bug难调试不过看书之余，你也可以动手自己试试，当个玩具写写玩玩：1. 实现教科书上的内存分配器：做一个链表指向空闲内存，分配就是取出一块来，改写链表，返回，释放就是放回到链表里面，并做好归并。注意做好标记和保护，避免二次释放，还可以花点力气在如何查找最适合大小的内存快的搜索上，减少内存碎片，有空你

我有些尴尬地拿着水杯，正对面坐着来访的王总，他是在别处打拼的人，这几年据说收获颇丰，见移动互联网如火如荼，自然也想着要进来干一场，尽管王总从事的行当也算跟IT沾边，但毕竟太长时间不接触技术，有些东西不太熟，总要咨询下我这个在一线开发混了十几年的老程序员，十几年的开发，有好几种可能性，不过这不是重点，所以暂时忽略掉这个细节吧。我之所以尴尬，是对王总的需求有些不知如何回答，仿佛陷入了某种习惯性的沉

过去十年间我一直在参加各种编程比赛。我参加了很多比赛，更重要的是，我参加了很多不同类型的比赛。我的冒险起始于经典算法，之后我转到了优化问题。目前我主要参加机器学习竞赛（作为兼职），我也参加一些只是为了好玩的比赛。考虑到有像我这样广泛经历的人并不多，我想我应该写一个编程（算法?）竞赛流行类型的（相对）简短的总结。这不是一个完整的列表，我只关注了那些最流行的，并且在我看来最有用的竞赛。这篇文章

有一个健康的自我批评对于专业和个人成长是很重要的。对于编程而言，自我批评的意义就是需要能查明设计中、代码中、开发中和行为中的无效或反效果的模式。这就是为什么反面模式对任何程序员都很有用的原因。基于我遇到它们的频率和解决它们花费的时间，本文讨论了我发现的反复出现的、粗略组织的反模式。某些反模式讨论到了它们被普遍认知偏误的地方，也有的错误是直接由它们引起的。这提供了一些关于认知偏误的文章。维基百科

不少程序员会说“代码写的太烂了”，说很容易，然后您能告诉别人什么地方需要改进么？其实我也有这样的毛病，单个人代码写的好时偶然的，写的烂是必然的，所以需要借助团队的力量来告诉成员需要改进的地方。由于业务编码工作接近尾声，业务开发人员和我主要从测试代码开始入手来改善代码质量，优化业务流程。       流程：由我通过mock的方式写service层的测试代码(仅仅测试复杂的业务流程，仅仅简单调用D

昨晚翻了翻《松本行弘的程序世界》这本书，看到他对异常设计原则的讲述，觉得颇为赞同。近期的面试，我有时也问类似的问题，但应聘者的回答大都不能令人满意。有必要理一理，说说我是怎么理解的，以及在编程实践中如何做出合适的选择。当然这只是一家之言，未必就是完全正确的。首先，要明确一点的是，错误码和异常，这两者在程序的表达能力上是等价的。它们都可以向调用者传达“与常规情况不一样的状态”。考虑使用哪一种，更

原文链接：http://lucida.me/blog/developer-reading-list/本文把程序员所需掌握的关键知识总结为三大类19个关键概念，然后给出了掌握每个关键概念所需的入门书籍，必读书籍，以及延伸阅读。旨在成为最好最全面的程序员必读书单。前言Reading makes a full man; conference a ready man; and writin

前几天写的盒饭的问题 有很大争议。我并不认为我的结论一定正确，但我想讨论这个问题的人忽略了许多现实的复杂性。    我想说，这是个真实事件，并不是因为我想说明什么问题编的故事。我依然相信，我最后如果做一个交换，会更好一些。不过不想为这个事情争论下去 :)    我觉得这个问题和蒙特霍尔问题有相似之处，但并不相同。我也没想仔细去计算概率，直想快速判断，换或不换哪种得到正确结果的可能性更大。

生命会逝去，但一个好的软件不会。要想写出一个“永垂不朽”的软件，关键是你能否遵循以下规则：1.模块化规则1：模块化。在一个模块中找bug总比在整个代码库里找简单得多。人脑是极其复杂的生物，可以设计出能处理复杂问题的CPU，但自我本身却处理不来这些问题。想要证明吗？那么告诉我，在不使用任何计算器，纯心算的条件下，你能算出13*35是多少么。我敢打赌，你不能。至

Jacob Kaplan-Moss 是著名 Python 框架 Django 的 Co-Creater 和核心开发者，在 Heroku 担任安全部门的 Director, 他常年参加 Python 社区的年度聚会 PyCon ，并经常上台演讲。在这次 PyCon 2015 上，他声称自己顶多只是一个平庸的程序员，幻灯片上也写着："Hi, I'm Jacob, and I'm a medio

回想起这个bug，仍然让我有些痛苦。作为一个程序员，在发现bug时，你学会了首先在自己代码中找问题，或许在测试一万次之后，你会把问题归咎于编译器。只有在这所有的都不起作用之后，你才会把问题归咎于硬件。这是我遭遇一个硬件bug的故事。抛开别的不说，我曾为《Crash Bandicoot》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了，

以下是我作为一名程序员经过10几年时间总结出的一些有关于软件开发的经验规则：开发1.从小事做起，然后再扩展无论是创建一个新的系统，还是添加功能到现有的系统中，我总是从一个简单到几乎没有任何所需功能的版本启动，然后再一步一步地解决问题，直到满意为止。我从来没有妄想过能够一步登天。相反，我一边开发一边学习，同时新掌握的信息还可以用于解决方案中。我很喜欢John Gall的这

从入职京东到现在，做读服务已经一年多的时间了，经历了各种亿级到百亿级的读服务；这段时间也进行了一些新的读服务架构尝试，从架构到代码的编写，各个环节都进行了反复尝试，压测并进行调优，希望得到一个自己满意的读服务架构。 一些设计原则无状态数据闭环缓存银弹并发化降级开关限流切流量其他无状态如果设计的应用是无状态的，那么应用就可以水平扩展，当然实际生