使用Visio 画 UML图
Categories: Development Notes; Tagged with: Better Developer • UML • visio; @ January 10th, 2009 0:23说来惭愧, 今天第一拿Visio画UML图, 虽然在大学里曾写过很多论文, 画过很多所谓的”图”…
创建一个UML图:
new>Software>UML Model Diagram
左侧 UML Static Structure中包含多数的需要使用的素材 如package, interface, class等
Tips:
1. 连线
可以按住Shift画笔直的线, 也可以点击线条右键format 为线条选择一个样式
2. 快捷键:
缩放: ctrl + 鼠标转动
左右移动 shift + 鼠标滚动
拷贝元素: 按下ctrl拖动
3. 另外可以下载使用Yahoo! Design Stencil Kit:
Yahoo! Design Stencil Kit下载地址:http://developer.yahoo.com/ypatterns/wireframes/
软件开发模型 – 增量模型
Categories: Development Notes; Tagged with: Better Developer • 增量模型; @ January 9th, 2009 17:23大学里曾在考试前认真背诵过几个模型 , 不求甚解, 也觉得乏味至极, 知道今天从新读来, 才稍稍领悟到一些知识之上的知识.
增量模型融合了线性顺序模型的基本成分(重复地应用)和原型的迭代特征。
增量模型采用随着日程时间的进展而交错的线性序列。每一个线
性序列产生软件的一个可发布的“增量”.例如，使用增
量范型开发的字处理软件，可能在第一个增量中发布基本的文件管理、编辑和文
档生成功能；在第二个增量中发布更加完善的编辑和文档生成能力；第三个增量
实现拼写和文法检查功能；第四个增量完成高级的页面布局功能。应该注意：任
何增量的处理流程均可以结合进原型范型。
当使用增量模型时，第一个增量往往是核心的产品，即实现了基本的需求，
但很多补充的特性(其中一些是已知的，另外一些是未知的)还没有发布。核心产
品交用户使用(或进行更详细的复审)，使用和/或评估的结果是下一个增量的开
发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布
一些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终
的完善产品。
增量过程模型，像原型和其他演化方法一样，具有迭代的特征。
但与原型不一样，增量模型强调每一个增量均发布一个可操作产品。早期的增量
是最终产品的“可拆卸”版本，但它们确实提供了给用户服务的功能，并且提供
了给用户评估的平台。
增量开发是很有用的，尤其是当配备的人员不能在为该项目设定的市场期限
之前实现一个完全的版本时。早期的增量可以由较少的人员实现。如果核心产品
很受欢迎，可以增加新的人手(如果需要的话)实现下一个增量。此外，增量能够
有计划地管理技术风险，例如，系统的一个重要部分需要使用正在开发的且发布
时间尚未确定的新硬件，有可能计划在早期的增量中避免使用该硬件，这样，就
可以先发布部分功能给用户，以免过分地延迟系统的问世时间。
参考资料:
Software Engireering-A Practitioner’s Approach
Use Case Reference – 用例模板, 场景书写准则
Categories: Development Notes; Tagged with: Better Developer • Use Case • 用例; @ January 8th, 2009 23:50用例Use cases:
| User Case 用例 | 增加学生 | ||
| Brief description | 增加/修改 学生 | ||
| Scope/Level | AthenaES/User goal | Primary actor/role | 管理员 |
| Minimal & Success Guarantees 保证 | Minimal: The system logs how far it may get Success: 新的学生被添加; 被更新(E3) |
||
| Preconditions 前提 | Actor is logged in | ||
| Triggers 引发条件 | 用户点击”ADD” | ||
| Main Success Scenario 成功场景 | 1. 用户点击”ADD” 2. 系统打开编辑用户界面 3. 用户输入符合要求的: 姓名 年龄 性别[可选] 4. 用户点击”Save” 5. 系统保存学生成功, 系统关闭编辑窗口并返回主窗口 |
||
| Extension 扩展 #1 | 4a: 用户点击”Cancel”, 系统关闭编辑窗口并返回主窗口 | ||
| Extension 扩展 #2 | 5a: 系统无法连接服务器或服务器存储报错, 提示错误 | ||
| Extension 扩展 #3 | 编辑学生: 1b: 用户选中学生之后点击”Edit” 5b: 系统保存学生成功, 系统关闭编辑界面并返回主界面 |
||
| Notes and Issues | 无 |
场景书写准则
| 场景书写准则 | 举例 | ||||
| 使用简洁明确的句子 | 格式: 主语 + 谓语动词 + 直接宾语 + 状语 √ 用户点击”ADD”按钮 |
||||
| 从系统外部以第三人称视角来编写用例 | × 读取ATM卡和PIN号码, 并从帐号余额中扣除一定数量 √ 用户插入ATM卡并输入PIN; 系统从帐号余额中扣除一定数量 |
||||
| 记录执行者的意图, 而非具体动作 |
|
||||
| 包含”合理”的活动集 | 3到6步是较为合适 & 具体情况具体分析 – 可以把每个部分作为一个单独的步骤, 也可以用不同的方式合并其中的几个部分, 甚至可以合并为一个步骤, 具体要视每个部分的复杂程度和执行过程中什么地方会发生自然中断来决定的. 一般来说的. | ||||
| “确认” 而不是 “检查是否” |
|
||||
| 必要时的时间限制 | √ 在步骤3跟步骤5之间的任何时候, 用户将… √ 当用户…系统将… |
||||
| 习惯用语: “用户让系统A与系统B交互” |
|
||||
| 习惯用语: “循环执行步骤x到y, 直到条件满足” | √ 1) 顾客提供帐号或者姓名和地址; 2) 系统查出顾客的爱好信息 3) 用户选择一个商品, 并做上购买的标记; 4) 系统将这个商品加入顾客的”购物车”中 顾客重复步骤3~4 , 直到顾客指明他已完成购物 5) 顾客购买所有在购物车中的商品 |
参考书目: Writing Effective Use Cases
Pair Programming对程序员的要求与具体实践
Categories: Development Notes; Tagged with: Better Developer • Pair Programming • 双人编程 • 结对编程; @ January 4th, 2009 9:37什么样的人不适合做Pair Programming
太过自负
•不能容忍别人的意见
•我总是对的
•我吃盐多过你吃米
太过自卑
•没主见
•没责任心
什么样的人适合做Pair Programming
Extreme Programming对实施的程序员提出了更高的要求。这种要求不是技术水平，也不是学历水平也不是工作经验。这种要求是对一个人的心智，道德，修养的更高要求。
程序员的四怕：
1) 怕自己看上去傻
2) 怕被认为是没用的
3) 怕自己变的不重要（过时）
4) 怕自己不够好
Pair Programming中，编码不再是私人的工作，而是一种公开的“表演”。程序员的代码，工作方式，技术水平都变得公开和透明。
XPer的素质
一个XPer应该具备这样一些基本素质：诚实，公正，开明，勇敢和谦卑！在这些素质的基础之上，才是对技术水平，能力和天分等的要求。
•诚实
•公正
•开明
•勇气
•谦卑
具备这些素质才能克服“四怕”，才能成为一个成熟和专业的Developer。
如何Pair Programming
•Driver – 写设计文档(Class diagram等)，进行编码(Unit Test and Business Object)等XP开发流程。
•Navigator – 审阅Driver的文档、Driver对编码等开发流程的执行；考虑Unit Test的覆盖程度；是否需要和如何Refactoring；帮助Driver解决具体的技术问题。
•Driver和Navigator不断轮换角色，不要连续工作超过一小时，每一小时休息15分钟。Navigator要控制开发时间。
•主动参与 – 虽然每个Engineering Task都有owner，但不能一旁观者的心态来做。任何一个Task都首先是两个人的责任，也是所有人的责任。没有“我的Code”、”你的Code”或“她的Code”，只有“我们的Code”。
•只有水平上的差距，没有级别上的差异。一个Pair,尽管可能大家的级别资历不同，但不管在分析，设计或编码，双方都拥有平等的决策权利。
•Pairs之间互换Partner。每个Task都应该和不同的Developer配对。
•每隔一天，甚至是半天，互换Partners。但Task的owner因该继续留该Task的Pair中。
•如果Pair中的一人请假，另一人应尽量不要写Production Code。
•Pair一起加班
Pair Programming[双人编程, 结对编程] 准备知识总结
Categories: Development Notes; Tagged with: Better Developer • Pair Programming • 双人编程 • 结对编程; @ January 3rd, 2009 22:31双人编程指在一个项目中由两个程序员编写一个软件的技术.每两人在同一台机器上工作，其中一人操作机器的同时另一个在旁边仔细看着代码被编写出来.操作者从战术上关心当前自已在编写的每一行代码，观察者确认语法规范，并从战略上考虑整个程序.他们频繁地交换彼此的角色，并且更快地编写出比单人编写更少错误的代码.并且，这些代码至少被两个以上的开发者所熟悉。
The Practice 实践
Pairing 配对
Pairing begins when the developer responsible for a task asks someone else for help. The rule is: when asked, you must say yes. This does not mean you have to immediately stop what you are doing. Rather it means that you must negotiate a time when you can offer that help and another time when you can get help in return.
双人编程开始于负责某个任务的程序员寻求他人的帮助。原则是：有人来问，你必须说是，不过这不意味着你要马上停下你在做的工作，而是说，可以商定某个时间帮忙，而在另一个时间让对方帮你的忙。
The pair partner does not assume responsibility for the task. That responsibility remains with the task owner. Nor does the pair partner commit to staying with the owner until the task is complete. The pair partner only commits to help.
双人编程的拍档者不对所做的任务承担责任，责任由负责任务的那个程序员承担，，拍档者直到任务完成也不会承诺与任务负责人共同负担任务的责任，只是承诺会帮忙。
One member of the pair becomes the driver, while the other looks on. The driver types in the code, runs the compiler, runs the unit tests, and so forth. The watcher examines each keystroke, each command, each test result, and offers help and suggestions. Both parties are engaged at all times.
双人编程中的某个成员成为操作者，同时另一个作为观察者。操作者敲代码，编译，做单元测试，观察者检查每一次敲击，每一个命令，每次测试的结果，并提供帮助和建议，整个时间里两边都同样的忙碌。
Sometimes the driver will know best what to do, and the watcher will simply be following along. At other times, the watcher will dictate what to do to the driver. Sometimes the driver will get frustrated and will hand the keyboard to the watcher,thereby switching roles. Other times, the watcher will ask for the keyboard and switch roles. this will happen many times in a pairing session.
有时，操作者知道该如何做到最好，这时观察者就只是随着思路走就行了。反之，观察者可以指示操作者该如何做。有时操作者会思路阻碍做不下去，键盘交给观察者，两者便换了角色。在整个编码过程中，观察者会主动要求键盘输入，从而交换角色，这种情况是经常发生的。
Changing pairs 交换配对
Pair partners are not long term. A typical pairing session will last about half a day. Either partner can opt out of the pair for any reason. When this happens, the owner of the task must find another pair partner. This may mean that it is time for the task owner to pay back a favor to someone who paired with him or her last week. On the other hand, perhaps he or she should ask
someone with the right experience to help with a particularly sticky problem.
双人编程的两个拍档不是长期合作的。一个典型的双人编程会持续大约半天，其中每个拍挡可以以任何理由要求重新选
优点
一、Pair 可以最大化的提高工作效率。 软件开发并不只是程序员堆砌代码的过程，它更多的是一个创新的过程，是一个发现问题、分析问题、解决问题的过程。一个人编程时，往往有了一丝零碎的想法就开始编写代码。写完代码之后，忽然发现这个方案行不通，只好废弃这些代码，重新开始新的想法。当一个人在遇到疑难问题时，很容易走入“死角”。而Pair则不同，一个人有了想法，首先要表达出来，让自己的同伴理解，经过深刻的讨论，一致认可之后才开始编写代码。一个人编写代码，另一个则在旁边思考，会为下一步的工作提出建设性的意见。发现了问题可以及时的指正。大大的提高了代码质量。
一个人一天有效工作时间不超过3－4个小时。两个人一起Pair。一个人编写代码，另一个人则从设计的角度思考下一步的工作，有了想法之后，互相讨论，再互换角色。在开发过程中，设计思考和编码实现不停的进行交换，保持了良好的开发节奏。同时可以互相督促，使彼此更加认真的工作。遇到问题和压力时，可以一起面对，互相鼓励。可以一起分享解决问题的成就和乐趣。
二、Pair 是知识传播的最好途径。 很多软件公司都建立有自己的知识库，有的还建立自己的培训部门，甚至高薪聘请一些专家做技术培训。但发现效果并不理想。培训之后，开发人员面临实际的项目，还是一片茫然。而与有经验的同事一起Pair则是在实际项目中学习，具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起Pair，你的经验和能力可以得到快速的提高。
在ThoughtWorks公司，如果你要加入一个项目，完全不用担心它使用的技术和涉及的业务。只要你有一定的基础，和有经验的同事一起Pair能让你很快熟悉和掌握它们。
三、Pair 可以打造出最佳的合作团队。 团队是有组织有计划的，合理有效地利用各种资源，进行最佳的组合。Pair并不是一对固定的伙伴，我们鼓励在团队中经常交换Pair伙伴。这时我们发现，项目不再是一个人的事情，也不是两个人的事情，而是整个团队的事情。
通过Pair，大家可以在最短的时间内完成磨合。Pair很好的促进了团队的沟通交流，经常一起合作Pair的伙伴，彼此了解、熟悉，很多都是工作和生活上的好友。在这样的团队里，大家很乐意互相协助，一起分享知识，分享快乐。
参考资料:
Pair Programming (结对编程) 作者: 作者：钱安川（Moxie） http://www.blogjava.net/moxie/archive/2006/09/14/69714.html
RUP/XP指南:双人编程 http://accp.chinaitlab.com/ACCP/9763.html
Moxie同学把在项目中遇到的developer分为四类。
1、优秀型的Developer。有丰富的工作经验，很好的解决问题能力，善于沟通，有幽默感，还有生活情调。这个不说了，他在任何地方都是受欢迎的。
2、巨大潜力的Developer。没有工作经验，理解能力不错，悟性比较高，人很勤快，爱问问题，脾气也好，懂得尊重其他同事。这类 developer，我们也非常喜欢。我们遇到一个这样的应届毕业生，刚来的时候，只会一些基本的Java知识，他在团队中工作5个月，并已成为客户公司的主力developer了。
3、Trick型的Developer。也许没什么经验，但思维非常活跃，也许喜欢狡辩，也偶尔会指责别人，有点小懒惰，而且会自我感觉非常良好。与这样的develoer合作时候，问题争论会很多，但对问题的理解也会更加深刻。这样的devloper，需要教育提醒。告诉他我们是一个 Team，多用“我们”这个词，你指责别人，别人也会以同样的方式对你。如果能改正这些缺点，他绝对是个好同志。
4、普通的Developer。要么是技术不错，但是理解能力很弱；要么是沟通、理解能力不错，但是工作态度不好，爱混日子。和这样的 developer 一起Pair是要辛苦一些，需要一些技巧。能把你的技术方案，讲得通俗易懂，这也正说明你思考正确和深刻，我们在开发的时候，要善于分解问题，将一个复杂的问题分解，小步前进，这样开发才有一个非常好节奏。工作态度不好的，那就多问问题，逼他思考工作.