读《走出软件作坊》有感

   第一次看到这个书的副标题《三五个人十来条枪，如何成为开发正规军》，心里就觉的这是一本十足的IT小说书，但是读了几段之后，就放不下手了，很久没有看书看到欲罢不能的境地了，所以晚上一有空就读上几章，当然也不放过在等车和在轻轨上捧读的那一点时间，因为是部门公共书籍，所以看第一遍的时候也没有写下什么笔记，后面看第2、3遍的时候，顺便写了一些提纲。其实不同的时间不同的心情看这本书，你会发现每看一遍都会有新的体会和思考。那么接下来就有了下面一点读书心得，与大家一起分享一下：(一共十段) 
　　㈠. 团队配合【p27】 
　　我们也应该属于作者以前身处的那种三五个人，十来条枪，旧系统需要维护，新系统也要上线，上有不停的变更，下有客户的意见的情况。虽然我们的团队文化不很明晰，但是我们还是一个很好的团队，那么游击队如何变为兄弟连，如何再变为正规军，那么这个就是要讲究一个团队配合，做到心往一处想，劲往一处使。 
　　至于团队人员的配置上，作者分析下来 除了需要程序员外 还至少需要这么几类人 
　　1、Help文档编写人员 
　　2、搞内部培训的人 
　　3、测试人员 
　　4、设计文档编写人员 
　　5、核心代码和公共代码编写人员 
　　6、比客服更懂软件的支持人员 
　　如果再压缩一下，1和2可以是一个人 3和6可以是一个人 4和5可以是一个人？ 
　　作者提出一个观点，“不允许开发团队出现多种技术。多种技术，会让团队成本升高，每个人都得会多种技术”【p36】 
　　的确对一个技术(简单举例：java / c# )只有经常用、吃透摸透，才可能提高开发速度和质量，俗话说"拳不离手、曲不离口"应该就是这个道理，技术运用的越多可能掌握的就深度不够，熟练度也不达不到，那么怎么提高开发速度和质量？说到开发速度，不仅对于技术，就是工具的选择也是这样，俗话说”磨刀不误砍柴工“，如果拿一个不熟悉或者不称手的工具，即使很熟悉这个技术，也无法提速。例如我们几年前用Jbuilder作为java开发平台，后来转到eclipse开发平台上，现在利用集成了CVS的eclipse，做开发的时候关注点不会再放在工具怎么用、快捷键是什么的问题上了，可以更专注的解决设计开发的核心问题上。不过如果再让我用回Jbuilder，我可能又要适应一段时间，那么可以想象对比一下，这个效率是如何的。使用工具尚且如此，何况在不同的技术上呢？ 
　　作者在设计方面使用了“PPT+WORD+脑图+EXCEL”的描述方法【p38】 
　　我也谈一下我的感受，作者这里说的四个工具，当然也不光光只能用在设计方面，平日里都可以拿出来晒晒。三个是Office套件工具，的确很好很强大，作者说到用PPT做界面窗口，我觉的不太顺手，可能作者是做C/S架构软件的，我们这里全都做的是B/S架构的，界面都是WEB，如果话原型，用HTML表现更快更好用。其实后面作者也谈到了这一点，呵呵【p91】 
　　word就不说了。 
　　excel我觉得深入学习还是非常有必要的，如果仅仅把excel看做是表格工具，那word就可以搞定了。excel的计算和可编程功能可以大大提高我们的工作效率，我现在家里记账就使用的一个台湾人基于excel做的电子帐簿，用起来非常舒服 
　　第4个是脑图 ，是一个思考问题的方法，近来越来越觉的很实用，特别方便把脑子里的东西理顺，严重推荐。 
　　㈡. 老系统维护【p71】 
　　作者也说把这个主题放在过程管理篇的第一部分，因为现在很多程序员每天干的工作，不是在开发新系统，而是在维护老系统。 
　　维护老系统，不断继承包袱，不断细心剖析问题，剥茧抽丝理清思路，不断改进，才能渐渐从恶性循环走向良性循环，才能把一套人见人厌的系统变个样，当然不要忘记考虑一下成本和代价。 
　　作者提了8项建议，结合我们各类旧系统，我把它精简一下，对于老系统有以下几点： 
　　1、表单输入、存储、显示、打印必须一致。 
　　2、追加新需求功能代码，分离特殊业务和正常业务的功能代码。不要搅在一起，本来就迷糊的代码，更让人难懂。 
　　3、在维护时，觉得程序很烂，不能抱着破罐子破摔的思想，你心态平和一点，修改代码可能还顺利一点。 
　　4、避免编写大函数。 
　　5、如果某个系统一没文档二没注释，怎么维护？的确不要说设计文档、帮助说明，就是代码都可能没有注释或者还有垃圾在里面，还好能从页面上看到数据库字段的定义，并且老系统流程都不复杂。新增加的代码，本来看不懂现在看懂的代码，应该增加上必要的注释，否则下次再来搞一遍？ 
　　㈢. 设计文档编写方法【p127】 
　　作者对于企业管理软件开发过程中的文档是这样的：需求调研-》需求分析说明书-》功能点文档-》按照功能进行优先级标识（3级即3个阶段） 
　　每个功能点文档由一个excel文档来详细描述，这个excel中包括了： 
　　Sheet1 版本信息 
　　Sheet2 页面布局 
　　Sheet3 字段说明 包括：默认值、不可为空、输入约束、主键唯一、输入长度、参照录入等 
　　Sheet4 如果有必要，放业务流程图 
　　Sheet5 非功能性需求等 
　　这个excel完工后，测试人员介入校验。ok了之后，才涉及到具体的实现说明。公共代码人员整理出数据结构【p132】，并在之上建立视图。然后编写每个功能的增删改查的操作文档，并补充到excel的 sheet6中 
　　下面就定义开发计划和公共开发人员的任务列表。 
　　综上所述，公共开发与业务开发在并行，设计编写和功能开发在并行，设计和设计测试在并行，代码和代码测试在并行。 
　　让我们用平和的心态看待编写文档，不是为了正规才编写文档，而是为了用而写。当然，我觉我们现在不是要砍掉什么多余文档，而是要增加必要环节的关键文档，例如：功能点描述文档，关键页面布局（或页面原型），开发设计文档。其实这也是我们要开发的主要内容，先讨论明确了，后面开发时候可以减少点返工或会不一致的地方。 
　　㈣. 开发团队练兵【p135】 
　　3新的情况是指“新技术、新团队、新产品 ”，首先避免这3种情况同时出现，三新同时出现风险太大，特别是避免采用新技术作为基础技术。 
　　其中对于学习新技术，作者提出了应该先“学习基于新技术的第三方的国外开源源代码”。这个观点的确很实在，干嘛要学习新技术？不就是为了用嘛，别人的实际应用不是最好的example了吗？比官方的DEMO还要贴近实际。但问题是找的到，然后是看得懂。 
　　㈤. 企业业务开发平台架构【p141】 
　　如果有个稳定的，易用的底层平台，那对开发会带来很大帮助，作者总结的关键 
　　特性总结好像不太适合我们B/S开发，我也想了一下，B/S下我们需要 
　　 1、可以快速开发(文档化，可查可用) 
　　 2、稳定（需要不断历练） 
　　 3、日志记录 
　　 4、通讯功能 
　　 5、PDF打印框架 
　　 6、页面通用控件 
　　 7、页面CSS样式 
　　 8、常用javascript库（UI特效、前台验证） 
　　 9、安全性控制 
　　 10、简单可用的RBAC 
　　 等等吧 
　　㈥. 代码那些事【p149】 
　　这章中作者提到的新手常出的2个错误，令我印象深刻： 
　　一个是修改bug问题，修改bug，的确有时是非常令人头疼的事情，特别是缺少设计的文档，缺少必要注释或者程序逻辑复杂，或别人写的程序段中古怪的句法。bug好似拔萝卜，连根又带一把泥的，怎么办？我常用的方法是排除法，将各个吃不准的代码块隔离，优先找到出现bug的直接原因，然后看看这个问题如何修改，是否修改后会影响到其他地方。 
　　另外一个，我也能非常体会得到作者当时误操作后的感受，感同身受啊，曾经我也有一次数据库误操作，由于sql控制台中开发和正式都连接着，结果本意是想删除开发中的数据库，结果竟然删掉了正式数据库，当然我也是一身冷汗，万幸这个数据库不是当年度的正在使用和业务操作的数据库，我立即将它回复到最新备份，虽然是很久以前的事情，但是促使我养成了几个习惯，1、除非是真的要操作正式数据库，否则只用Select权限，宁愿让数据库提示我没有权限进行更新或删除操作；2、删除数据库前先脱机，等确定一段时间后删除3、开发数据库的库名不与正式库名相同；4、执行更新删除前检查确认无误，特别是where查询条件子句是否正确 
　　㈦. 软件测试【p157】 
　　关于测试，开发人员首先自己承担测试工作，冒烟测试？代码互查？ 
　　这是否是浪费？违反开发人员的”二八法则“？降低了开发人员效率？可能不一定，测试人员找到case后，还是要交给开发人员，如果不是像界面文字那种简单易见的错误外，开发人员要沟通、查找、修改、自测、再回归测试，反而成本更高。因为其实最后还是需要开发人员找出问题，排除错误，为什么不能开发人员先进行测试呢。无法测试？开发人员首先拿测试人员的case进行自测是否全部pass，这样可以刷掉第一轮测试的大量bug，再者也顺便复查了一下case的是否完备 
　　如果开发人员要问我测试人员做什么？我说 
　　0、测试、把关、QA 
　　1、根据需求（如果没有需求，就需要参与开发人员功能开发讨论的结论）进行编写测试case 
　　2、编写FAQ 
　　3、发布正式系统 
　　4、当系统稳定后，分析是否有必要编写自动化测试脚本时编写和测试自动化测试脚本，如用QTP工具 
　　5、非功能性测试，系统调优 
　　6、系统技术支持或DEMO和培训 
　　7、bug分析和归类 
　　上面太理想化，可以不看。 
　　开发测试比例 1：3，现在主流B/S架构下开发测试人员配置比例 
　　1：1？我觉的更多的软件工程学上的东西，太理论化，没有考虑到不同系统和条件下的关系，要不可能更多的偏向于单机时代，因为大家都知道那时候都是卖盒子软件的，一旦刻好盘那么再出软件bug问题，特别是严重问题，那就变成废品，成本损失代价很高，所以测试产品质量要求非常严格。现在是B/S时代，比C/S更进一步了，不用全部OK才上线，现在可以先上一部分功能，再逐步扩展和完善功能 
　　另外bug管理系统可以有多个用途：除了bug管理外还可能提供需求管理和任务管理。 
　　㈧. PPT 和演示的方法 【p179】 
　　作者最如何做一个专业的PPT文档和如何做演示写的非常朴实。其他不说，我最认同的一点就是，PPT就是你思路的大纲，不要密密麻麻的一堆又一堆文字。如果怕自己忘记可以把演讲稿放大一点字体打印出来放在laptop边上看看。不过我记得我第一次的时候，也想这么干，不过秦老师就说，将的时候一定要脱稿，否则会老是惦记着这张纸，老是怕漏讲什么，呵呵，看来仁者见仁，智者见智了吧。 
　　㈨. 客服支持 【p241】 
　　这章让我想起去年服务人员病了的那段日子，我的开发同事去替代帮助他服务，去前端呆上一段日可以体会到一些在幕后设计开发测试人员所体会不到东西，了解到一些需求中不可能提及的业务实际？呵呵，其实也可以选在课题申报截止的那天，开发或测试人员轮流去隔壁网站编辑部帮半天工，也一定可以体会到不少东西吧？ 
　　㈩. 自我时间管理【p385】 
　　这章是全书对我最有价值的地方，因为首先书中大多案例以企业管理软件信息化为背景，以公司盈利最大化为目标，再者作者已公司管理者的角度待人处事和提出解决企业问题的方法，所以不可能按照他的方法照搬硬套。但是这章却不同，这种是将个人管理，对每个人在每个阶段都有参考意义。 
　　如果用一句话浓缩一下，我觉得就是“二八法则”，把有限的时间做最有价值的事情上去。 
　　上面的一些东西只是我在阅读前后的几点感受和扩展思考，可能和现实状况不搭边，也可能会适得其反。书中大多讲的是一些“土"方法，都是作者长期以来工作中的一些经验和思考总结，没有大段的枯燥理论带你走出软件作坊，而是给你一种思路，思考问题的方法，一种出路，让你自然而然的走出软件作坊。看完这本书后，作者不会代替你思考，但你在思考了吗？