/*免责声明:全部内容都属于是段友分享,我只是属于整理。**//*写在前边,个人觉得****弄一个积分下载,就是在自掘坟墓。
原创 2022-10-09 21:25:36
113阅读
七年等待换来的经典 本书审校:孟岩  Robert C. Martin的经典著作Agile Software Development中文版面世,这是计算机技术出版领域的一件大喜事。即使在今天技术图书市场非常繁荣的局面下,这本书的问世也仍然是值得广大开发者格外留意和关注的事件。这不仅是因为它刚刚荣获2002年度Jolt震撼大奖,更因为这本书本身的价值和独特魅力。   面向对象设计的原则
转载 精选 2009-03-30 16:30:14
3805阅读
敏捷软件开发模式原则实践摘录敏捷开发遵循的原则:我们最优先要做的是通过尽早的,持续的交付有价值的软件来满足客户满意体来构建项目。给他们提供所
原创 2022-09-28 16:54:16
191阅读
刚才在china-pub看到《敏捷软件开发:原则模式实践(C#版)》已经出版了。这本书是以前那本《敏捷软件开发原则模式实践》的C#版,这是不是说明C#程序员的数量已经多到Robert Martin无法忽视的程度了呢?:)   既然说到了图书,就再推荐一本我现在正在温习的,《高级.NET程序设计》(《Advanced .NET Programming》,中文版
原创 2008-01-03 12:37:00
901阅读
看了一下夹在书中的发票,2010年在当当网购买的。断断续续的也看过几次,一直没有看完过。这次试着写写读书笔记。看看能不能坚持住。
原创 2017-04-03 13:50:08
496阅读
编写单元测试是一种验证行为,更是一种设计行为。测试时一个无价的文档。如果你想知道如何调用一个函数或者创建一个对象,会有一个测试展示给你看。什么是设计?不应该认为设计就是一组和代码分离的UML图。一组UML图也许描绘了设计的一些部分,但是它不是设计。(还是要代码化)僵化性是指难以对软件进行改动,即使是简单的改动。如果单一的改动会导致有依赖关系的模块的连锁改动,那么设计就是僵化的。脆弱性是指在进行一个改动时,程序的许多地方就可能出现问题。要修正这些问题就又会引出更多的问题。牢固性是指设计中包含了其他系统有用的部分,但是要把这些部分从系统中分离出来所需要的努力和风险是巨大的。晦涩性是指模块难以理解。
"你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚. 但你应当把这些原则看成警铃,若违背了其中的一条,那么警铃就会响起." 1.SRP单一职责原则[适用于类功能]   (就一个类而言,应该仅有一个引起它变化的原因.)   详细说明:   如果一个类承担的职责过多,就等于把这些职责耦合在一起.   一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力.   这种耦合会导致脆弱的设计,当变化发
转载 2010-11-21 20:16:00
231阅读
2评论
虽然这本书已经有些年头了,但我还是觉得它有被读的必要,尤其是像我一样这么low的码农。在书中第5章 重构  细胞,只有拥抱变化才能拥有顽强的生命力。所以我们不要
原创 2022-09-08 14:37:15
63阅读
//类Score package com.java.bowlingscore; public class Scorer { public void addThrow(int pins){ itsThrows[itsCurrentThrow++]=pins; } public int scoreForFrame
原创 2018-08-09 23:19:25
1127阅读
2评论
  Review of Agile Software Development: Principles, Patterns, and Practices 本书主要包含4部分内容,这些内容对于今天的软件工程师都非常的重要,它们是: ●Agile方法:主要讲述了如何去使用Agile方法,其中有很大一部分内容是告诉你为什么要这样做。 ●面向对象设计原则
原创 2011-04-05 12:10:53
820阅读
软件开发的历史可以追溯到20世纪40年代,当时计算机主要用于科学计算。随着计算机技术的发展,软件开发逐渐成为一个独立的领域。在早期,软件开发主要采用瀑布模型,这是一种线性的开发方法,每个阶段需要完成特定的任务,然后才能进入下一个阶段。 然而,随着软件系统的复杂性增加和市场竞争的加剧,传统的瀑布模型逐渐暴露出一些问题。首先,由于需求分析和设计阶段的耗时较长,导致开发周期过长,难以适应快速变化的市场需
原创 1月前
25阅读
敏捷软件开发实践
原创 2013-07-31 10:12:01
985阅读
1、我们最优化先要做的是通过尽早的、持续的交付有减脂的软件来使客户惬意。 2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3、常常性地交付能够工作的软件,交付的间隔能够从几周到几个月。交付的时间间隔越短越好。 4、在整个项目开发期间,业务人员和开发者必须天天都在一起工
转载 2017-06-06 09:50:00
212阅读
2评论
在需求变化频繁的环境下,敏捷是个不错的选择。
转载 精选 2012-03-07 10:39:16
473阅读
宣言: 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 原则: 1. 我们最优先做的是通过尽早、持续的交付有价值的软件来使客户满意。 2. 即使到了开发的后期,...
原创 2021-07-31 15:53:00
708阅读
软件开发时,经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的话题。如果您以前没有使用过这种方法,那么适当了解开发方法和理论是必要的;简单地说,这是一种组织软件开发工作的方法。这与项目管理的风格或特定的技术方法无关,尽管您经常会听到这些术语混在一起或互换使用。最流行的两种基本方法是:瀑布开发敏捷开发。这两种方法都是可用的、成熟的方法。现在,说起敏捷
转载 2019-11-22 16:13:30
823阅读
介绍:对于敏捷开发团队来说,团队管理也是必不可少的,我带领的团队分2部分,1个是开发团队,一个是测试团队。开发团队,我大体上比较放心,因为毕竟已经运行1年多了,文档充足,而且技术方面也有很多资料或者现成代码可以参考,测试团队是刚组建没多久的,因为原来测试团队放在onshore那边,但是现在他们测试团队解散了,所以我们这边就组建了一个测试团队。这里共享下我管理团队的一些经验。实现方式:其实我也不是一
原创 2013-08-01 10:49:18
730阅读
!@敏捷开发!@#敏捷开发引入许多人都经历过由于没有实践的指导而导致的项目噩梦。缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。一个由平均水平程序猿组成的团队,如果具有良好的沟通能力,将要比那些虽然拥有一批高水平程序猿,但是成员之间却不能进行交流的团队更有可能获得成功。过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言。客户合作胜过合同谈判。告诉开发团队想要的东西,然后期望开发团队消失一段时间后就能
原创 2021-08-05 15:48:43
1162阅读
<<敏捷软件开发原则模式实践>>时,素数产生程序,第一个java久把我难了半了,之后找百度搜素数的代码才知道了筛选法求素数.
原创 2018-08-04 21:17:50
380阅读
代码中为每个形状指定了序号,如果再来一颗子弹,让你要按类型打印的同时,还要按照序号从小到大排列怎么做呢? 1 using System; 2 using System.Collections.Generic; 3 4 namespace DesignPattern 5 { 6 class Progr ...
转载 2021-10-05 19:58:00
76阅读
2评论
  • 1
  • 2
  • 3
  • 4
  • 5