《股市进阶之道》— 投资理财系列读书笔记【一】

最近迷上了看投资理财的书籍,有点被“财务自由”的伟大梦想洗脑的感觉。其实,所谓财务自由,最根本的点是:时间的自由,自己同时掌控金钱和时间的自由。我们已经被现实的忙碌束缚了太久,来不及充电,也来不及思考。如果能通过努力学习,掌握一些些投资理财之道,窥探一下财富的本质,让自己和热爱的家人,在我们的生活小天地内,不再为金钱所累,能有更多的时间陪伴家人和孩子,锻炼身体,更多的时间去读书和旅行,感悟生活的美好,那就幸甚至哉!


豆瓣评分:8.8  链接:https://book.douban.com/subject/25829645/

笔记摘要:
好生意:
一、 DCF三要素
1. 经验存续期评估
2. 现金创造力评估:刚性资本支出、销售现金含量、上下游的资金结构
3. 经营周期定位

二、 增长的衡量
1. ROIC
2. ROE

三、 市场竞争格局格局:市场的本质供需,商业的本质竞争,投资的本质前瞻
1. 供需关系
2. 竞争烈度
3. 护城河不是目的而是手段,目的是经验的超额收益。护城河按壁垒从低到高:领先关键一步、成本优势、客户黏性、行政准入壁垒、复合型壁垒。
4. 印钞机特征:低边际扩张成本、高客户黏性

好企业:
一、 优良的生意特性:见“好生意”

二、 处于价值扩张(还是回升阶段、回归阶段)阶段:以ROE为指标,既能实现净资产的扩张,又能保持长期较高水平的ROE水平
1. ROE能达到的高度:ROE三要素(销售净利率、总资产周转率和资产负债率)演变趋势如何?最重要的潜力来自于哪里?
2. 高ROE的持久度
3. 净资产的增长能力

三、 高重置成本及定价权:不有上述特征的企业未必不是好企业
1. 无形资产P144:对个人消费者、对企业用户、对内
2. 定价权层次:没有定价权、定价权看对手、成本、附加值、供应缺口。

四、 优秀可信赖管理层:先选好生意,兼顾好管理
1. 企业家精神
2. 战略视野及规划
3. 坚强有力的组织
4. 值得信赖的商业道德

五、 建立逻辑支点P161,每笔投资必问的三个问题
1. 投资这个企业的战略理由是什么?
2. 投资这个企业的战术安排是什么?短期业绩波动是降低持仓成本的良机。
3. 影响企业发展成功和失败的关键要素是什么?

六、 三种经营特性:利用杜邦分析法,不断向下分解,同时结合业务特征,确定提升ROE的关键矛盾
1. 高利润率低周转
2. 低利润率高周转
3. 杠杆型

七、 成长的来源
1. 内部驱动:开拓新市场、深耕老市场;外部驱动:并购重组
2. 深耕老市场:提价、降低成本。用收入与利润增速相比较衡量是否匹配。
3. 预估企业成长的量级

八、 为股票建立系统性的认知卡片(P196)
1. 市场前景
2. 竞争格局
3. 经营特征
4. 财务特征
5. 企业素质

九、 投资策略
1. 建立分级股票池:A类理解不了,直接放弃;B类空间广阔,但有很多问题,等待观察;C类研究透的基础上,制定投资策略。
2. 策略包括对象、时机、力度三部分
3. 对象的辨别:向上(低谷拐点型、未来优势型),向下(高峰拐点型),平稳(当前优势型、持续低迷型),无法判断型。从外部来说,是供需环境的演变;从内部来说,是竞争优势的变迁;从动态角度来说,是企业处于价值扩张、回升、回归还是无法判断。值得特别指出的是,向上的情况是否依靠特定的时代红利。
4. 买入的时机:最好的买卖时机一言以蔽之“通常让人不那么舒服”。最佳的卖出时机都是企业最景气、市场反馈最热烈和情绪最高涨的时刻,而最佳的买入时机则往往是企业景气度低迷、前景看不清楚、遭遇突然的重大打击、市场评价也最糟糕的时候。
5. 力度和仓位:用对象、时机两个象限的好坏程度决定力度。二者皆好大力度(40-60%),一个好一个一般中等力度(20-40%),不买手痒买了又不放心的,建立试探性仓位(10%以内),其余放弃。
6. 大力度必问的三个问题:A短期的预期收益率:现价买入,未来1年以中性条件预估,是否有获得40%收益的机会?靠业绩增长还是估值修复?B持续的预期收益率:如果短期预期收益率未能实现,内在价值是否依然在积累?C再跌20%后的策略:如果买入后继续下跌20%,我是否会欣喜若狂?是否还有足够的后手面对?
7. 资金量也会影响到风格:百万以内以寻找未来优势型为主,百万以上就需要兼顾到低谷拐点型(逆向投资)

好投资:
十、 市场定价的逻辑
1. 市场是有效还是无效:市场最终是有效的,但不是始终是有效的。有效是相对的,无效是绝对的,不完全有效即是无效,如果非得要给个结论的话,还是无效的。
2. 有效的两个假设:投资者皆理性,所有信息都被有效传播。
3. 70%的时间不具备操作意义,25%的时间可能出现有意义的操作机会,只有5%的时间是具备重大操作价值的。不要无谓的瞎折腾,要么安心的持有,要么耐心的等待。
4. 估值取决于预期。包括企业和行业的生命周期、生意模式和盈利的确定性程度。

十一、 股票与企业的和而不同
1. 企业的内在价值或基本面的改善通常是缓慢的,而证券市场却在每个交易日进行着频繁的定价工作。企业的经营周期又未必与证券市场的情绪周期完全一致,时间拉得越长股价就越从属于企业业绩的状况,时间越短股价越取决于市场预期和情绪的变化。所以一笔投资到底是基于业绩具有极大发展潜力的长期持有,还是短期的估值回升,二者之间不可模棱两可。
2. 市场具有自我强化的特征,在牛市或个股强势确立阶段,不要仅在价格合理时就一次性抛出,相反在熊市或个股弱势确立的阶段也不要仅在合理价位就着急买入。不要用原来的事实去解释已经的泡沫或者低估,关键是看股价在事实之上的继续自我发挥程度。
3. 高度一致的预期意味着不再有更多的钱转化进入这个阵营,也就没有了更大的力量推动其继续前进,这一价位的崩溃和共识同盟的瓦解只是时间的问题。
4. 长期来看,更关键的是寻找到一个正确的对象,正确或者错误的时机则可以放大这个对象所带来的结果。但仅理解内在价值还远远不够,学会利用市场定价与内在价值的偏离,认识到真正的投资价值来自于这种偏离,进而对这种偏离度所带来的风险和机会有敏锐的直觉,才是投资工作的核心。投资者最可贵又不可或缺的能力,其实就是对价值与价格的偏离敏感性,它必不可少的建立在对市场预期的本质意义、威力、特点和规律的深刻理解。我们由此将理解投资与实业的最大区别在于,前者很大程度上不仅仅是经营结果的积累更受到复杂心理因素的影响。这就注定了一个优秀的投资者既要是商业分析的佼佼者,更必须是对人性具有深刻洞悉的人,永远要警惕自己已经沦为市场主流共识中的一员。

十二、 低风险、高不确定性
1. 现价买入低风险,高不确定性相当于白送。核心思路是利用不确定性与市场预期之间的时间差,项目从虚无缥缈到逐渐落地,直至“最终判决”这个空档期足够市场先生表演好几回了。
2. 不确定的是好事能不能成,而不是坏事会不会来。
3. 典型如2000年FDA3期之前的天士力

十三、 周期轮回
1. 股市周期产生的原因:实体业绩、资本环境、市场情绪,三大因素互动。
2. 资本环境中通胀与利率对股市无明确影响。
3. 供求关系有利于证券市场未来发展:(1)理财产品和房地产的高歌猛进的分流是过去两年缺乏行情的外部原因,未来有望改善;(2)IPO和全流通对市场的负面影响并没有想象的那么大;(3)社保基金、养老基金的大规模入市可期。
4. 市场情绪:在一切的开始,任何市场的共同预期总是建立在某种事实的基础上。但市场情绪的不断膨胀和疯狂生长最终总是让一切事实相形见绌。市场情绪具有巨大的能量,预期的大合唱,定会推动它创造出远远脱离实业基础和资本环境的不可思议的景象。
5. 系统性低潮期:每一次的下跌,都是搜集优秀企业筹码的机会。特点:大部分股票进入历史估值区间底部;分红收益率超过存款利率;大股东回购增持。
6. 系统性模糊期:战略继续持有,忽略波动,与优秀企业共同成长。
7. 系统性高潮期:分批撤离,涨幅最大估值最高仓位最重的先撤离,设定好每涨多少就撤退多少,可留5%的仓位观察。特点:大市值企业也获得极高的溢价;开户数屡创新高;新估值方法被发明。
8. 对以长期持有为主的投资者而言,判断股市整体处于何种环境,不是为了更好的作为,而是为了更好的不作为。
9. 格雷厄姆捡烟蒂式投资,不仅仅在于强大的抗压能力,也在于仓位的控制(买入后价格大幅下跌后仍然有加仓的能力)在投资低估值的困境企业时,一定要分散投资的意义所在。邓普顿亦是如此,低于1美元的股票买了100多支,而不是几支。

十四、 估值的困惑
1. PE、PB、PS、PCF
2. PB、PE的四种组合
3. 多维视角下的称重:组合估值法、历史区间法、风险机会配比法、重要案例法、终值评估法。(P356-P362)
4. 先构勒出一个大致的最终市值量级,再打个折扣。比如某股市值就算未来再翻十倍,相对于其可能的市场地位和盈利规模而言依然不离谱,就是一个很好的市值冗余。

十五、 总结
1. 一句话总结投资:好生意、好企业、好投资。
2. 好生意就像是寻找一个商业上的富矿。好企业就是一个优秀的矿工,再好的生意也经不住不作为和胡作非为。好投资除了好价格外,还有“看得准,敢下手,拿得住”,同家庭资产结构也有关系。
3. 投资者和经营者的区别:经营者局面是既定的,他需要动用一切智慧在现有局面下尽量做到最好;而投资者面对的是一个开放的选择,最大价值就是找到局面最好的对象,找到大概率和高赔率的机会。

《高效程序员的45个习惯》读书笔记【思维导图】

《高效程序员的45个习惯》这是一本好书,书中的观点直白、朴素,极富实践性!当然最重要的,还是要在实际项目中身体力行!

下面摘取书中要点,花了大半天时间做成思维导图,以方便随时查阅。

高效程序员的45个习惯

1 宣言

1.1 个体和交互胜过过程和工具

1.2 可工作的软件胜过面面俱到的文档

1.3 客户协作胜过合同谈判

1.4 响应变化胜过遵循计划

2 原则

2.1 (一)态度决定一切

2.1.1  做事

1)指责不会修复Bug,把矛头对准问题的解决办法,而不是人

2)一个重大的错误应该被当作是一次学习而不是指责他人的机会

2.1.2  欲速则不达

1)不要坠入快速的简单修复之中,要投入时间和精力保持代码的整洁

2)不要让开发人员孤立的编写代码

3)阅读代码的频率越高越好

4)代码复审不仅助于代码更好理解,也是发现Bug最有效的方法之一

5)防止代码难懂的重要技术就是单元测试

6)所有大型系统都非常复杂,没有一个人能完全明白所有代码,除了深入 了解所负责的那部分代码,需要从更高层面来了解大部分代码,理解系统 各个功能块之间是如何交互的

7)实际工作中,可以先快速修复问题,即为了应对紧急情况,但事后一定好细致分析

2.1.3  对事不对人

1)询问你的队友,并提出你的顾虑

2)礼貌待人,负面的评论和态度会扼杀创新

3)必须把重点放在解决问题上,而不是极力证明谁的主意更好

4)能容纳自己并不接受的想法,表明你的头脑足够有学识

5)设计充满了妥协,工作中不感情用事是需要克制力,展现成熟大度来

6)团队能公正地讨论一些方案的优点和缺点

2.1.4  排队万难,奋勇向前

1)动手去做比光抱怨好得多

2)当发现问题时,不要试图掩盖问题,要诚实、勇敢说出实情,并与团队一起寻求好的解决办法

2.2 (二)学无止境

2.2.1  跟踪变化

1)迭代增量式的学习:每天计划用一段时间来学习新技术

2)了解最新行情:阅读博客、maillist等

3)参加线下技术活动

4)参加研讨会议

5)阅读好书

6)不需要精通所有技术,但要清楚知道行业的动向

7)明白为什么需要这项新技术,它试图解决什么样的问题?它可以被用在什么地方?

2.2.2  对团队投资

1)一个学习型的团队才是好的团队

2)每周要求团队中的一个人主持讲座,介绍新技术、工具或者书籍

3)坚持有计划有规律地举行讲座:持续、小步前进才是敏捷

2.2.3  懂得丢弃

1)学习新技术时,多问问自己,是否还在沿用旧的态度和方法

2)新技术会让人感到一点恐惧,但你的确需要学习它

2.2.4  打破砂锅问到底

1)为了解决问题,你需要知道许多可能的影响因素

2)当找人询问任何相关的问题时,让他们耐心地回答你的问题

3)不能只满足于别人告诉你的表面现象,要不停地提问直到你明白问题的根源

2.2.5  把握开发节奏

1)许多不成功的项目中,基本上都是随意安排工作计划,没有任何的规律

2)敏捷项目会有一个节奏和循环,让开发更加轻松

3)最大的节拍就是迭代时间,一般是1-4周,确保每个迭代周期的时间相同很重要

4)项目开发需要有一致和稳定的节奏

5)在每天结束的时候,测试代码,提交代码,没有残留代码

6)不要搞得经常加班

2.3 (三)交付用户想要的软件

2.3.1  让客户做决定

1)开发者需要知道哪些是自己决定不了的

2)具体到游戏行业,客户分两类,一类是项目策划,他们是需求的提出者 故在设计开发前,需要与之作深入的沟通,明确他们的意图;一类是玩家, 他们是最终使用者,开发者可以站在玩家角度去分析策划案的价值和作用

2.3.2  让设计指导而不是操纵开发

1)时刻谨记,此阶段提出的设计只是基于你目前对需求的理解 而已,一旦开始了编码,一切都会改变

2)敏捷开发中,少用文字,多用图表来表达设计意图,常用序列图和类图

3)设计满足实现即可,不要过于详细

4)好的设计就是能适应变化的需要

5)先设计类的职责,再设计其方法和数据类型

1.类名

2.职责:应该做什么

3.协作者:要完成工作它要与其他们什么对象工作

6)白板、草图、便利贴都是好的设计工具,复杂的建模工具只会让你分散精力

2.3.3  合理的使用技术

1)这个技术框架真能解决问题吗

2)你将会被它拴住吗

3)维护成本是多少

4)不要开发你能下载到 东西

5)首先决定什么是你需要的,接着为这些具体的问题评估使用技术

2.3.4  保持可以发布

1)提交代码流程

1.确保自己编写的代码通过单元测试

2.检出最新代码,并再次运行测试

3.提交代码至版本管理服务器

2)持续集成系统就是在后台不停地检出、构建和测试代码的应用

3)保证你的系统随时可以编译、运行、测试并立即部署

4)如果不得不让系统长期不可以发布,则需要做一个分支版本

2.3.5  提早集成,频繁集成

1)决不要做大爆炸式的集成

2)代码集成是主要的风险来源,提早集成,持续面有规律地进行集成则可避免

3)集成和独立不是互相矛盾的,可以边进行集成,边进行独立开发

2.3.6  提早实现自动化部署

1)一开始就实现自动化部署应用

2)在不同的机器上用不同的配置文件测试依赖的问题

2.3.7  使用演示获得频繁反馈

1)每隔一周或两周,邀请所有客户,给他们演示最新完成的功能,积极获得他们的反馈

2)用Bug系统记录跟踪所有系统Bug

3)在游戏项目里,每完成一个迭代版本,尽早给策划同事及制作人演示,甚至在整个项目组测试演示 ,并收集大家反馈的Bug和建议

2.3.8  使用短迭代,增量发布

1)迭代开发是在小且重复的周期里,完成各种开发任务:分析、设计、实现、测试和获得反馈

2)游戏项目中,迭代时间最好是以一周为单位

2.3.9  固定的价格就意味着背叛承诺

1)需要根据业务复杂度、团队成员的能力水平、市场环境就诸多因素来评估项目的开发周期 这是一件很考验管理者(包括开发者)的经验与技术水平

2.4 (四)敏捷反馈

2.4.1  守护天使

1)敏捷就是管理变化的,而代码则是变化最频繁的东西

2)所谓守护天使即自动化的单元测试+后台自动构建

2.4.2  先用它再实现它

1)编程之前,先写测试

2)先写测试可以站在用户的角度来思考,并有利于消除过度复杂的设计

3)使用TDD作为设计工具

2.4.3  不同环境,就不同问题

1)在各种支持的平台和环境中运行测试用例

2.4.4  自动验收测试

1)为核心业务创建验收测试用例,这不同于单元测试

2)在游戏项目中,要分别为客户端和服务器创建验收用例,客户端侧重于表现效果验收, 服务器侧重于业务逻辑验收

2.4.5  度量真实的进度

1)每个工作日,团队成员要重新评估完成一个任务还需要多少小时

2)我的做法是每天在上班的路上想好当天要做的事情,在正式开工前,用google日历列出一天的任务列表, 列表的条目是具体可操作的工作,粒度的划分需要一定的经验,评估完工时间的单位是小时

2.4.6  倾听用户的声音

1)没有愚蠢的用户,只有自大的开发人员

2)每一个抱怨的背后都隐藏一个事实:找出真相,修复真正的问题

2.5 (五)敏捷编码

2.5.1  代码要清晰地表达意图

1)代码清晰程度的优先级应排在执行效率之前

2)编写清晰的而不是讨巧的代码

2.5.2  用代码沟通

1)不要用注释包裹你的代码

2)注释包含的信息:目的、输入、输出、异常,使用RDoc、javadoc、ndoc工具规范化注释

3)注释要说明为什么写代码,而不是解释代码做了什么

2.5.3  动态评估取舍

1)考虑性能、便利性、生产力、成本和上市时间,如果性能足够,则将注意力放在其他因素上

2)过早的优化是万恶之源

2.5.4  增量式编程

1)如果不对自己编写的代码进行测试,保证没问题,就不要连续几小时编程

2)写了几行代码之后,可以进行一次构建/测试循环,在没有得到反馈前,不要走太远

2.5.5  保持简单

1)除非有不可辩驳的原因,否则不使用模式、原则和高难度技术之类的东西

2)简单的解决方案必须要满足功能需求,不要过分简单

2.5.6  编写内聚的代码

1)要避免创建很大的类或组件

2)考虑实现一个简单的功能变化需要变更多少代码

2.5.7  告知,不要询问

1)开发人员绝对不应该基于被调用对象的状态做出任何决策,更不能去改变该对象的状态, 这样的逻辑应该是被调用对象的责任,而不是你的,即符合依赖倒置原则

2)要将功能和方法分为“命令”和“查询”两类

3)用发送消息或事件来代替调用函数

2.5.8  根据契约进行替换

1)通过替换遵循接中契约的类,来添加并改进功能特性

2)多使用委托而不是继承

2.6 (六)敏捷调试

2.6.1  记录问题解决日志

1)维护一个保存曾遇到的问题以及对应解决方案的日志

2)记录发生问题时应用程序、应用框架或平台的特定版本

2.6.2  警告就是错误

1)找到一种方式让编译器将警告作为错误提示出来

2)解释性语言通常也有标志,相用相关标志,然后捕获输出

2.6.3  对问题各个击破

1)不要试图马上了解系统所有细节,要想认真调试,就必须将有问题的组件或模块与其他代码分离出来

2)用原型进行分离

2.6.4  报告所有异常

1)处理或是向上传播所有的异常

2)不是所有的问题都应该抛出异常

3)报告的异常应该在代码的上下文中有实际意义

4)记录运行日志

2.6.5  提供有用的错误信息

1)提供详细的运行日志,记录运行状态

2)区分错误类型:程序缺陷、环境问题、用户错误

2.7 (七)敏捷协作

2.7.1  定期安排会面时间

1)立会:大家到公司的30-60分钟进行

1.昨天有什么收获

2.今天计划要做哪些工作

3. 面临着哪些困难

2)立会时,只能给予每个参与者很少的时间发言,如:两分钟

3)采取立会的形式需要管理层的承诺和参与

4)立会时间不要超过30分钟,10-15分钟比较理想

5)立会时,要注意报告的细节,只给出具体的进度,但不要陷入细节之中

2.7.2  架构师必须写代码

1)作为设计人员,不能理解系统具体细节,就不可能作出有效的设计

2)只通过一些高度概括的、粗略的设计图无法很好地理解系统

3)鼓励程序员参与设计,优秀的设计从积极的程序员那里开始演化

2.7.3  实现代码集体所有制

1)在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码

2)注意有些场合是不能采用代码集体所有制的,这时候,人多了反而容易误事

2.7.4  成为指导者

1)教学相长

2)分享自己的知识、经验和体会

2.7.5  允许大家自己有办法

1)作为指导者,应该鼓励、引领大家思考如何解决问题

2)用问题来回答问题,可以引导提问的人走上正确的道路

2.7.6  准备好后再共享代码

1)绝不要提交尚未完成的代码

2)完成一项任务后,应该马上提交代码

3)保证所有代码通过单元测试

4)使用持续集成是保证源代码控制系统没有问题的一种良好方式

2.7.7  做代码复查

1)代码刚完成时,是寻找问题的最佳时机

2)让不同的开发人员在每个任务完成后复查代码

3)运用静态代码检查工具,如:Similarity Analyzer、Jester

4)注意每次复查的代码量不宜过大,保持每次在1k Line以下

5)代码复查内容

1.代码能否被读懂和理解

2.是否有任何明显的错误

3.代码是否会对应用的其他部分产生不良影响

4.是否存在重复代码

5.是否存在可以改进或重构的部分

2.7.8  及时通报进展与问题

1)发布进展状态、新的想法和目前正在关注的主题,不要等别人来问题项目状态如何

2)每日立会让每个人都能明确了解最新进展和形势

3)可以作日报和周报来反馈项目进度

3 工具

3.1 Wiki

3.2 版本控制

3.3 单元测试

3.4 自动构建

4 宗旨

4.1 以人为本

4.2 团队合作

4.3 快速响应变化

4.4 可工作软件

5 核心:Just Do It!!!

【声明:若有摘录,请注明来自http://gameislife.info/archives/133】

《Lua游戏开发实践指南》读后感

书籍地址:http://book.douban.com/subject/20392269/

一句话点评该书:想用Lua作游戏脚本开发的同学值得一读!

(一)本书特点

市面专门讲Lua的中文书籍很少,窃以为,一方面可能觉得Lua比较简单,可深入讲的东西并不多;另一方面,说明Lua的开发者数量,(尤其是国内)还是一个比较小众的群体,出版商们也无利可图。回到这本书,它不同于一般纯粹讲Lua语言本身的书籍,如:《Lua程序设计》等,而是专注于讲解Lua在游戏领域的应用,从书中列出的几个例子来看,可以看得出作者在游戏行业是有比较丰富的经验的。下面摘取了书中的一些要点,与诸君分享之:)

(二)要点分享

(1)Lua在游戏开发的应用场景

1)编辑游戏的用户界面

我的理解:GUI图形绘制等基础功能还是要由宿主语言来完成,如:C/C++,Lua可以负责GUI的排版、布局等逻辑处理;

2)定义、存储和管理基础游戏数据

我的理解:游戏对象各配置数据如果比较简单的,均可以用Lua代码直接描述,用以代替文本文件,并省却解析的代价。复杂一点的,可以结合excel(保存为cvs文件),并利用Lua强大的文本解析功能来完成。

3)管理实时游戏事件

我的理解:玩家与游戏的交互都是通过鼠标、键盘等外设来完成,而在游戏设计中,普遍的做法是用事件机制来驱动完成。在Lua中可以通过定义LuaGrue函数与C/C++等宿主语言进行交互调用来形成一整套完整的事件系统。具体实现时,宿主语言实现捕获鼠标、键盘各类事件的底层接口,而事件触发后具体做什么,以及事件之间可能的依赖关系等逻辑,则由Lua来完成;

4)创建和维护开发者友好的游戏存储和载入系统

我的理解:在单机游戏中的游戏存档等数据,也可以很方便的用Lua来直接描述;

5)编写游戏的人工智能系统

我的理解:作者说的在AI中应用Lua,我觉得应用场景应该是在一些比较小的单机游戏中,而在大型多人在线的网络游戏中,恐怕还是需要性能更高的C/C++来实现。当然,作者也讲到,一个灵活的做法是,先用Lua来快速实现原型,遇到性能瓶颈了,再用C/C++来替换。

作者在讲到Lua在游戏开发团队中的应用分工时说,“程序员负责将Lua整合到游戏开发环境中,游戏设计师(策划)是脚本语言的主要使用者,因为他们和上层的游戏设计和数据直接打交道,美术师也会经常使用Lua,进行诸如界面布局、设计和3D场景中各种模型的摆放之类的工作。”看到这里时,不禁感叹,我们与国外游戏开发同行的水平差距:人家认为游戏策划和美术人员写脚本是理所当然的事情,而咱们这里,却认为这些不都是程序员该干的活吗?开发理念的高低直接导致了开发成果的巨大差异!

(三)本书的不足

(1)书中讲的Lua版本是5.0,而现在最新的已是5.2.1了,与C语言通信的API也有了一些变化;

(2)没有讲Lua的一个重要特性:协程,协程在异步编程中应用广泛,不但能简化传统异步编程的代码编写,而且还能有效的提高性能;

《程序员的职业素养》读书笔记

书籍地址:http://book.douban.com/subject/11614538/

一句话点评该书:Bob大叔的职业生涯经验总结,现身说法,可信可敬!

(一)专业主义

(1)“专业主义”就意味着担当责任;

(2)所谓专业人士,就是能对自己犯下的错误负责的人,哪怕那些错误实际上在所难免;

(3)你写的每一行代码都要测试。如果你希望自己的软件灵活可变,那就应该时常修改它!

(4)每个专业人士必须精通的事项;

1)设计模式:必须能描述GOF书中全部24种模式,同时还要有POSA书中多数模式的实战经验;

2)设计原则:必须了解SOLID原则,而且要深刻理解组件设计原则;

3)方法:必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等;

4)实践:必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程;

5)工件:必须了解如何使用UML图、DFD图、结构图、Petri网格图、状态迁移图、流程图和决策表;

(5)坚持学习。

不写代码的架构师必然遭殃,他们很快会发现自己跟不上时代了;不学习新语言的程序员同样会遭殃,他们只能眼睁睁看着软件业径直向前,把自己抛在后面;学不会新原则和技术的开发人员必将沦落,他们身边的人都是益卓越;

(6)业精于勤。

我常用的一个技巧是重复做一些简单练习:不妨早晚都个10分钟的卡塔吧!学习的第二个最佳方法是与他人合作。

(7)每位专业软件人员都有义务了解自己开发的解决方案所对应的业务领域;

(8)雇主的问题就是你的问题,每次开发系统,都应该站在雇主的角度来思考,确保开发的功能真正能满足雇主需要;

(二)说“不”

(1)专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”!

(2)最要说“不”的是那些高风险的关键时刻。越是关键时刻,“不”字就越具价值。

(3)许诺“尝试”,就意味着你承认自己之前未尽全力,承认自己还有余力可施。如果承诺尝试,你其实也在承诺将改自己原来的方案。你是在承认原来的方案中存在不足。

(三)说“是”

(1)做出承诺包含三个步骤:

1)口头上说自己将会去做;

2)心里认真对待做出的承诺;

3)真正付诸行动;

(2)识别“缺乏承诺”的征兆,注意搜寻如下词语:“需要/应当”、“希望/但愿”、“让我们”

(3)真正的承诺是,你对自己将来做某件事做清晰的事实陈述,而且还明确说明了完成期限;

(4)如果你无法兑现承诺,那么最重要的就是尽早向你的承诺对象发出预警、越快越好,越早越好;

(5)专业人士不需要对所有请求都回答“是”。不过,他们应该努力寻找创新的方法,尽可能做到有求必应。当专业人士结出肯定回答时,他们会使用承诺用语,以确保各方能明白无误地理解承诺内容;

(四)编码

(1)编码原则

1)首先,代码必须能够正常工作;

2)代码必须能够帮你解决客户提出的问题;

3)代码必须要能和现有系统结合得天衣无缝;

4)其他程序员必须能读懂你的代码;

(2)如果感到疲劳或心烦意乱,千万不要编码。强而为之,最终只能再回头返工。相反,要找到一种方法来消除干扰,让心绪平静下来;

(3)结对是应对中断的一种好方法,另一种有帮助的方法便是采用TDD;

(4)广泛阅读包括软件、政治、生物、航天、物理、化学、数学等,能激发创造力:“创造性输出”依赖于“创造性输入”,创造力会激发创造力;

(5)软件开发是一场马拉松,而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛,只有通过保存体力和维持稳定节奏来取胜;

(6)管理延迟的诀窍,便是早期检测和保持透明;

(五)测试驱动开发

(1)TDD的三项原则

1)在编好失败单元测试之前,不要编写任何产品代码;

2)只要有一个单元测试失败了,就不要再写测试代码,包括无法通过编译;

3)产品代码恰好能够让当前失败的单元测试成功通过即可,不要多写;

(2)TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。

(六)练习

(1)专业人士都需要借助专门训练来提升自己的技能;

(2)保持不落伍的一种方法是为开源项目贡献代码;

(3)我的理解:练习就像是学生时代的课后作业,日事日毕,练习内容可包括:经典算法、常用数据结构、设计模式等;

(七)验收测试

(1)做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化;

(2)验收测试定义为业务方与开发方合作编写的测试,其目的在于确定需求已经完成;

(3)业务分析员测试“正确路径”,以证明功能的业务价值;QA则测试“错误路径”、边界条件、异常、例外情况;

(4)实现某项功能的代码,应该在对应的验收测试完成后开始;

(5)验收测试不是单元测试。单元测试是程序员写给程序员的,它是正式的设计文档,描述了底层结构及代码的行为;验收测试是业务方写给业务方的,它们是正式的需求文档,描述了业务方认为系统应该如何运行;

(6)整套持续集成系统应该由源代码管理系统来触发。只要有人提交了代码,持续集成系统就会开始构建,并运行所有的测试,测试结果会用电子邮件发送给团队所有人;

(八)测试策略

(1)开发小组要把“QA”应该找不到任何错误“作为努力的目标;

(2)QA在团队中扮演的是需求规约定义者和特性描述者;

(3)专业开发人员遵循测试驱动开发的要求来创建单元测试。专业开发团队使用验收测试定义系统需求,使用持续集成保证质量稳步提升;

(4)测试金字塔,由下至上的顺序是:单元测试–>组件测试–>集成测试–>系统测试–>人工探索式测试,其中单元测试是基石。

(九)时间管理

(1)站立会议的核心:

1)我昨天干了什么?

2)我今天打算做什么?

3)我遇到了什么问题?

(2)迭代计划会议用来选择在下一轮迭代中实现的开发任务;

(3)凡是不能在5分钟内解决的争论,都不能靠辩说来解决。这类争论依据的不是事实,而是信念。唯一出路是,用数据说话。

(4)用番茄工作法管理时间。(呵,没想到Bob大叔也用这个)

(5)睡眠的重要性怎么强调都不为过,保证7小时睡眠!

(6)要避免的行为:优先级错乱、死胡同、泥潭;如果你掉进入坑里,别继续再挖!

(十)预估

(1)专业开发人员不随便承诺,除非他们确切知道可以完成;

(2)专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下,他们才会给出承诺。此外,他们也会小心避免给出暗示性的承诺。他们尽可能清楚地说明预估的概率分布,这样主管就可以做出合适的计划;

(3)预估实践方法之三元分析法,即划为乐观预估O、标称预估N、悲观预估P,结果u=(O+4N+P)/6;

(4)预估实践方法之德尔菲法:一组人集合起来,讨论某项任务,预估完成时间,然后重复”讨论–预估“的过程,直到意见统一;

(5)预估是非常容易出错的,控制错误的方法之一是大数定律:把大任务分成许多小任务,分开预估再加总。

(十一)压力

(1)即使有压力,专业开发人员也会冷静果断。尽管压力不断增大,他仍然会坚守所受的训练和纪律,他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法;

(2)在压力下保持冷静的最好方式,便是规避会导致压力的处境;

(3)避免压力的方法

1)不做不切实际的承诺;

2)让系统、代码和设计尽可能整洁;

3)在危机中依然遵守纪律原则;

(4)应对压力

1)避免孤注一掷的想法,鲁莽仓促只会把你带入更深的深渊。相反,要放松下来,对问题深思熟虑。

2)和团队、主管沟通;

3)坚信并依靠你的纪律原则;

4)结对寻求帮助;

(十二)协作

(1)不正常的团队最糟糕的症状是,每个程序员在自己的代码周边筑起一道高墙,拒绝让其他程序员接触到这些代码;

(2)专业开发人员是不会阻止别人修改代码的;期望拥有代码的是整个团队,而非个人;

(3)专业人士结对工作,是解决程序间合作的最有效方法,也是分享知识的最好途径;

(4)最有效率最有效果的代码复查方法,就是以互相协作的方式完成代码编写;

(十三)团队与项目

(1)形成团队是需要时间的。团队成员需要首先建立关系。他们需要学习如何互相协作,需要了解彼此的癖好,强项、弱项,最终,才能凝聚成团队。否则,那就是团伙,而非团队!

(2)最理想的团队是12人,7名程序员,2名测试人员,2名分析师和1名项目经理;

(3)创建有凝聚力的团队,然后不断地把新项目分派给他们,而不是围绕项目来构建团队;

(4)团队对项目更难构建。因此,组建稳健的团队,让团队在一个又一个项目中整体移动共同工作是较好的做法;

(十四)辅导、学徒期与技艺

(1)所谓大师

已经领导过多个重要软件项目的程序员。一般说来,他们已经拥有10年以上的从业经验,曾在多个不同类型的系统、语言和操作系统上工作过。他们懂得如何领导和协调多个团队,他们是熟练的设计师和架构师,能够游刃有余地编程。

(2)专业主义价值观和技术敏锐度需要进行不断地传授、培育、滋养和文火慢炖,直至其深植入文化当中;

【Bob大叔使用的开发工具】

使用Git来管控源代码,使用Tracker来管理Bug,使用Jenkins来进行持续构建,使用IntelliJ作为集成开发环境,使用XUnit来做单元测试,使用FitNesse来做组件测试

【附Bob大叔不完全Resume】

(1)1968年自学计算机编程,时年15岁,学习PDP-8汇编器、FORTRAN、COBOL、PL/1;

(2)1970年,没有上大学,被ASC公司聘为程序员,时年17岁;

(3)1973年,20岁与妻子Ann Marie永结连理,妻子那年刚18岁过去3天。Bob大叔深情地说:“38年来,她一直是我坚定不移的伴侣,是我的舵和我的帆,是我的爱与生命。我期待同她携手再走40年!”看来,一个卓越的程序员,也一定是一个深爱妻子与家庭的人!这点倒是与我不谋而合!大笑

(4)到目前为止,Bob编了42年的程序,与妻子育有二女一子!