我是如何写作一本软件+哲学式的书籍的（上）
摘要：近来，陆陆续续写了快十年的书《完美软件开发：方法与逻辑》终于上市了，这书非常另类，更像是软件+哲学的作品，很可能卖不好，也很多人不喜欢，但一路写来实在是比较坎坷，因此把大致的过程写下来，供想写书的各位参考。另一个自己很想说下的话题是，每个程序员都应该给自己写本书，虽然不太赚钱，下一篇写这个。非要给IT书分个类的话，我感觉可以分两大类：一类是解决具体问题的书，比如：《C#高级编程》，《Hadoop实战》等等。一类则是修炼内功的书籍，比如：《人月神话》，《程序员修炼之道》，等等。当然也有一些融合的比较好的，比如《代码大全》。自从从事软件开发之后一直想写一本后一类的书，主要原因是自己除了软件之外也比
阅读全文
posted @
2013-07-05 06:42
理想流
阅读(1878)
推荐(4) 编辑
出了本练内功的书：《完美软件开发：方法与逻辑》
摘要：首先说下什么叫“完美软件开发”，想象一下，完美的圆在现实中是不存在的，现实中的圆只能是对完美的圆的回归，但完美的圆描述了圆的构成规则，完美软件开发意义与此相同，它试图描述软件开发的规则和铁律。但既然现实中不存在，探讨完美状态又有神马意思？好，那我们再来看一个完美状态：牛顿第一定律说：任何一个物体在不受任何外力或受到的力平衡时，总保持匀速直线运动或静止状态，直到有作用在它上面的外力迫使它改变这种状态为止。这显然也是一个完美状态或者说理想状态，现实中也是不存在的，那这东西又有神马意义？个人感觉探讨软件开发的完美状态，就和探讨软件中的牛顿定律一样，虽然它现实中不存在，但对现实却有着极大的指导意义。单
阅读全文
posted @
2013-07-03 06:23
理想流
阅读(4204)
推荐(4) 编辑
思维的力度
摘要：当一个人看到这么一段话时，他会怎么想：尺度的进程并不仅是无穷进展的坏的无限无止境地采取由质过渡到量，由量过渡到质的形式，而是同时又在其对方里与自身结合的真的无限。质与量在尺度里最初是作为某物与别物而处于互相对立的地位。但质潜在地就是量，反之，量潜在地也即是质。所以当两者在尺度的发展过程里互相过渡到对方时，这两个规定的每一个都只是回复到它已经潜在地是那样的东西。于是我们现在便得到其规定被否定了的、一般地被扬弃了的存在，这就是本质。在尺度中潜在地已经包含本质；尺度的发展过程只在于将它所包含的潜在的东西实现出来。我想可能的反应大概有两类：一类是这人胡说八道，故弄玄虚；一类是是说这个说的抽象，表达力不
阅读全文
posted @
2013-07-01 07:43
理想流
阅读(1801)
推荐(5) 编辑
关于如何读代码？
摘要：读代码这事，先要分是精读还是泛读。从学习的目的来看，一定要精读一定量的经典代码。而精读是指每行都读懂，不看代码脑子里就能勾画出程序的基本结构。这里有个很形象的状态，精读代码时会满脑子都是代码，放不下，甚至睡觉前脑子里也是代码。但这一篇里主要不是关注如何精读代码的，而是关于如何在工作中掌握既有代码的，等价于泛读。现存的很多系统往往很大，几十万行的可能也只算普通。这时候一旦加入了这样一个项目，那么如何去读代码？下面说点个人体会。读这类代码前，先得把规格大致弄清楚，而不能上来就读，比如：对于应用型程序，你要先大致整清楚它的使用方法。如果其中有涉及到领域知识，比如：流程、财会等，那也最好预先有些认识。
阅读全文
posted @
2013-01-07 07:26
理想流
阅读(2917)
推荐(7) 编辑
程序员在大学里究竟应该学习什么？
摘要：近来在CSDN结识了贺利坚老师，并仔细的读了一下贺老师的博客，感觉贺老师是非常负责的一个大学老师，在他的博客中看到了很多他和大学生的交流。这就促使我开始思考，如果大学再来一遍，我也还是想做软件，那我应该在大学里学点什么？最终我决定把想到的东西写下来，希望能对在校的人有点帮助。首先我们得知道这问题的答案是个变量，他依赖于你的目标和天资能力，绝不唯一。当然大学的课程设置往往是唯一的，所以会有点矛盾。这里最关键的东西是目标，大学学习只是达成最终目标高度的一个环节，他应该为最终目标服务。当然大学生很难清楚的知道自己的目标究竟在那里，但要总归要大致知道自己的方向。这个之所以关键是因为，这直接决定你应不应
阅读全文
posted @
2012-12-24 00:16
理想流
阅读(4846)
推荐(10) 编辑
团队里A和B吵架了，经理M该干啥？
摘要：有时候正工作呢，突然就会听到两个兄弟声音放大，言辞也开始变的激烈。这事儿实在太常见，以至于不需要具体案例大多数人就能想象到是怎么个场景。现在的关键问题是这个时候经理M应该干点什么？我个人感觉，有两种极端的处理方法一定不太行。一是完全置之不理，就是假装没看见，你们吵成什么样算什么样。一是什么事都管，一有争吵就开始调解，消除所有不“和谐”声音。前者比较失职，工作中，人员间矛盾大多与工作有关，完全不处理必然影响到工作，所以即使单纯从对工作负责的角度看，这也是种失职。后者会显的过于婆婆妈妈，大家都是成年人，不是小学生，你什么事情都管，讨人嫌不说，也不利于当事人成长---有些能力是要在这种环境中才能练出
阅读全文
posted @
2012-12-10 01:03
理想流
阅读(4834)
推荐(1) 编辑
现代软件工程里的困惑
摘要：在众多软件相关的知识中，软件工程绝对是很特别的一个。很多人很鄙视软件工程，说：我一看到软件工程的书就直接略过；与之相对应，很多人很推崇软件工程，会花很大的心思去研究敏捷、CMMI等。刚入职场的程序员大致上是讨厌软件工程的，因为这东西离自己的实践有点远，并且主要是添加束缚。但既然更加复杂纷繁的历史都可以总结出规律，软件开发没道理就总结不出可以遵循的规律。也许真的事实是：并不是软件工程没有用，而实在是很多软件工程的书籍理论飘的太高，落地上有困难。软件工程一个很大的困境在于，它总是试图以软件整体为研究对象，但软件的内部分野过多，不同种类的软件间所适用的方法又充满矛盾。这最终就导致很多软件工程理论往那
阅读全文
posted @
2012-12-03 00:04
理想流
阅读(933)
推荐(0) 编辑
从代码里你可以看到什么？
摘要：经常有小同事和我说，这程序的代码写的太垃圾了，什么水平。确实如此，大部分持续存在一段时间的程序代码质量都不怎么样。从圈复杂度的角度看，超过15的代码就很看了会头疼了，但可怕的是圈复杂度到70,、80的也不是没有。谁要摊上改这种代码，估计上吊的心都有：不改不行，改了谁知道出什么问题？从这种代码里能看出来什么，很说明的人的心境。说看到技术水平较差的大多是刚毕业的兄弟。说看到利益纠葛，人心世道的大概就是成年老鸟了。我持后一种观点。为什么世界上会有这么多垃圾代码，这绝对不只是因为技术不行。如果世界只由技术因素主宰，那么按理说只要一个软件存在的时间足够长，投入的人力足够多，代码一定会变的足够好。但事实恰
阅读全文
posted @
2012-11-26 07:24
理想流
阅读(3089)
推荐(9) 编辑
组织行为学对项目管理的意义：动机理论
摘要：要想做好管理先要理解相应群体的动机，所以管理者要大致知道一点动机理论，要不然就只能呼唤狼性了。《组织行为学》这本书很有意思，说动机理论前，先攻击金胖子。说尊敬的领导（即刚去世不久的金胖子）通常被认为有点疯狂，比如他会绑架韩国电影导演或者日本人，可这是为什么呢？作者认为首先是享乐主义。金胖子喜欢所有最新的玩具和小玩意，让厨师去东京学习世界上最好吃的寿司的做法，到伊朗学习鱼子酱的做法，到新加坡学习番木瓜的做法，到哥本哈根学习熏肉的做法，吃米饭前，大米要一粒粒被检查并去除残渣等等。其次是恐惧以及对安全的渴望是另一个动机，不停的在各个住所间迁移，谋求大规模杀伤性武器都是为了这个。作者观点的真实对错姑且
阅读全文
posted @
2012-11-12 01:37
理想流
阅读(2045)
推荐(0) 编辑
组织行为学对项目管理的意义（2）：人格的大五模型
摘要：人格可以理解为情绪，思维方式，习惯的复合体，具体左右一个人对周围人事所作出的反应。在组织行为学里有好多对人格特质进行描述的模型，其中比较有名的一个是大五模型（五维度人格模型）。在大五模型里用五个因素来考察人格特质：外倾性（extroversion):外倾者者倾向于喜欢群居，善于社交和自我决断。内倾者则比较内向，胆小害羞，安静少语。随和性（agreeableness）:高随和性的人是合作的，热情的和信赖他人的，低随和性的人是冷淡的，敌对的和不受欢迎的。责任心(conscientiousness):高责任心的人是负责的，有条不紊的，值得信赖的，持之以恒的。低责任心的人则容易精力分散，缺乏规划性，且
阅读全文
posted @
2012-10-15 00:06
理想流
阅读(5674)
推荐(1) 编辑
组织行为学对项目管理的意义（1）
摘要：在MBA的课程中有一门是组织行为学，就我个人感觉项目管理者别的科目不看也罢，组织行为学这门还是看看比较好。组织行为学被定义为这样一种研究领域：探讨个体、群体以及结构对组织内部行为的影响。通俗的讲就是研究一个人的行为规则，比如人的需求层次会如何影响动机，又会如何影响人的行为。饿的要死的人，是不适合总谈理想的。研究一个群体的行为规则，比如从众心理如何产生以及如何预防。研究组织结构对个人行为的影响，比如官僚的体系结构下和矩阵体系结构下，人的行为会不同。上面这些东西无疑的是对项目管理有意义的。对项目管理而言，难的往往不是体现在PMBOK各个章节中的东西，而是如何协调与各种人员间的关系。客户，老板，团队
阅读全文
posted @
2012-10-10 02:01
理想流
阅读(2889)
推荐(1) 编辑
技术还是管理？
摘要：我们必须承认技术和管理所面临的问题、所需要的性格和能力皆是不同。虽然有的时候管理也被认为是一种技术，但我们更愿意把直接贡献于软件产品的工作称之为技术，而把通过协调沟通等手段间接贡献于软件产品的工作称之为管理。从先天性格来看，有的人天生适合做管理多一点，有的人天生适合做技术多一点。比如说：有的程序员天生有点被动，不喜欢主动学习很多东西，不喜欢与人沟通，但对工作所直接关联的领域研究较深，做事情兢兢业业，一丝不苟。有的程序员生活的比较被动，安排的事还能努力去做，但很难主动去做什么。有的程序员非常聪明，理解东西很快，但不愿意搭理别人，总感觉别人水平比较差，脾气也比较暴躁。有的程序员精力充沛，对技术狂热
阅读全文
posted @
2012-09-19 00:02
理想流
阅读(4917)
推荐(3) 编辑
常飘在天上的代码评审
摘要：虽然CodeReview经常被提及，但就我个人感觉（一半从别人的博客，一半个人经历），CodeReview的实际境况大多时候还是比较难看的。更多时候，CodeReview很像被存起来的酒，用的时候拿出来看看，证明有这东西，但大多时候是不用来喝的。细究成因可能是来源于两个方面：一是时间压力太大。软件开发里可以安全打折扣的地方其实不多，文档不写很容易被看出来，代码不写程序就动都不动了。没办法下，很多时候就只好拿CodeReview开刀。毕竟CodeReview里少看两眼，多看两眼，用多少心思看，其实是个良心账，外人看不出来的。同时，CodeReview本身也确实是个费时间的活。另一种成因是看不见成
阅读全文
posted @
2012-09-03 06:58
理想流
阅读(2208)
推荐(3) 编辑
软件开发究竟是“难”还是“复杂”？
摘要：我一直的观点是要对“难”做一点分解。好比说航空母舰的弹射器，我们造不出来，很“难”与一台机器有一千个螺丝要拧，保证3年中所有螺丝都拧对了，很“难”，这两种场景下“难”的含义是不同的。软件开发的难度更多的类似于后者，表现为繁杂，而不是类似于前者表现为“搞不定”或“做不出来”。总是有人喜欢把问题绝对化，所以这里补充一句，软件涵盖的范畴可以很广，因此确实有很难搞定的，类似于弹射器的领域，但应该不是主流。以前的很多提法，在这样一种大前提下就变的没有什么意义了，比如说：国产操作系统。当很多公司或组织标榜这类事情的时候，似乎自己更愿意认为这是一种技术突破。但实际上在开源如此发达的今天，这类东西的开发更需要
阅读全文
posted @
2012-08-20 06:36
理想流
阅读(2979)
推荐(1) 编辑
对架构师而言，什么最重要？
摘要：软件架构师的定义乃至所需要的特质历来众说纷纭。下面从一些另类的角度来做点分析。从产生根源来看，程序规模越大，参与人员越多，越需要架构师；程序越小，参与人员越精英化，架构师存在价值越小。这不难理解，大军团作战，总不好一窝蜂就上去了，总要有些规则，总要有人把我全局。架构师就是在比较高的层面上把握全局的这个人。从这个角度来看，对架构师而言选择最重要，因为站的高，所以选择具有非常大的价值。注意不是UML，也不是对业务的理解，不是编码能力而是做出正确选择的能力。当下的开发环境下，考虑解决方案时，所面临的选择不是太少，而是太多。举个最简单的例子，我们要开发一个基于Web的项目管理程序，那么你面临的选择是：
阅读全文
posted @
2012-08-13 07:15
理想流
阅读(5330)
推荐(6) 编辑
管理中第一可怕之事（3）
摘要：假设说一个人是个项目经理或部门经理，并一下子扎到了一个执行力不好的环境中，那么这个人能干点什么或者说应该干点什么？大多时候中层的人并不能左右高层的性格乃至种种选择，所以如果真有让人绝望的事情，又没有忍耐的的能力那就只能换个地方。这很简单，并不值得多谈，我们主要要关注的是事情积极的一面，即如何扭转这种局面。为了有所改善，第一关键的事情是要足够真诚。工程师组成的团队中其实并不需要很多政治，大多时候，大多事情是可以谈，并谈出以逻辑和事实为根据的最佳答案的。中层和工程师间的隔阂大多时候起于一些很简单的原因，如：工程师更贴近现场，如果中层总是把自己的位置摆的很高，喜欢居高临下，那么工程师会觉的这个中层很
阅读全文
posted @
2012-07-30 07:27
理想流
阅读(2381)
推荐(4) 编辑
管理中第一可怕之事（2）
摘要：在考虑如何解决执行力问题之前，很有必要考察一下执行力为什么会败坏。现实中很本质的东西往往会被繁杂的细节所掩盖，因此我们来抽象出一个虚拟的公司，来看看执行力出问题的各种可能性。我们假设有一个小公司刚刚建立，其中高层2人，中层3人，一般员工30人。我们假设在公司营业的第一天，执行力是没有问题的。那么如果执行力最终出了问题，变成说了不做的状态，那么要么主要是高层问题，要么主要是中层问题，要么主要是一般员工问题。每个角色均摊责任这种事过于巧合，不太可能存在。假设一般员工应该负主要责任，那么假设成立的前提就是：招募的员工大部分是“***民”并且能够进行比较一致的行动来败坏公司制度以及中层的安排。缺乏这两点，
阅读全文
posted @
2012-07-23 07:02
理想流
阅读(1948)
推荐(2) 编辑
管理中第一可怕之事（1）
摘要：如果让每个人选一个管理（包括项目管理和部门管理）中最可怕的事，答案想必不尽相同。有的人会老生常谈的选沟通不畅，有的人会选文化冲突，有的人会选资源不足等等。但就我个人感受，第一可怕的事是说了不做，流行点的词可能叫执行力。典型的场景是规则流程定义了一大堆，一到做的时候这些东西就都放在一边了。每个人都按自己的习惯来，各行其是。这很可怕，会导致无政府状态，做的人因为看不到改善而抱怨，管理者会因为看不到未来而绝望。比如说我们周围路总修不好，对此大概没人认为是个技术问题---偷工减料怎么也不是技术问题。总结之后可能发现，“啊，这和层层转包有关系。应该禁止。”接下来制作各种规则，禁止转包。但不去执行，或者说
阅读全文
posted @
2012-07-09 06:55
理想流
阅读(2419)
推荐(5) 编辑
开发语言的选择
摘要：在软件这个行业里，怕是没有任何一个其话题域像开发语言这样引起争议了。对开发语言是非的争论，不单旷日持久，且深度亦是与时俱进。实现要强调下的是，在这里我们要专注的是开发语言的选择而非开发语言的优劣。从不同的视角对开发语言进行选择，其结论可能大相径庭。从项目的角度看，语言自身特性的多少，强弱往往并不成为一个关键选择因素。好比说某语言支持多重继承，而某语言不支持多重继承，但对大多项目而言多重继承这一语言特性并不成为选择的决定性因素。从项目角度看，某些通常被考虑(或不得不考虑)的因素有：历史的原因。维护升级类项目这类没有选择的选择自不必提，这里说的历史的原因是指这样一类情形：完成某个项目需要某一图形算
阅读全文
posted @
2012-06-11 00:29
理想流
阅读(5347)
推荐(3) 编辑
