`
love~ruby+rails
  • 浏览: 867514 次
  • 性别: Icon_minigender_1
  • 来自: lanzhou
社区版块
存档分类
最新评论

26 Hints for Agile Software Development

阅读更多

I collect nuggets of wisdom on various topics. Recently I have been going over the topic of Agile software development; what really matters? Below is a list of 26 key principles to guide an agile software development team.

  • Get case 1 fully working before starting case 2. Another way of saying this to use a kitchen metaphor is: “Serve the current meal before starting to cook the next“. The biggest problem with software development is to start a bunch of things in parallel, because inevitably work will include something that is later discarded, meaning wasted work. Work on one case; get it fully functional; get the tests running; write the documentation; check it all in as a finished piece of work, before you start on the next case.
  • Never break the build. Pretty obvious, but must be included in any list of software development advice. A programmer who is taking all the proper precautions to test before checking in will never break the build. If the build is broken, it is always because someone took a shortcut.
  • Never implement a routine before it is needed in a use case. When implementing a particular class, you should have a particular use case in mind, and you should implement only the methods required for that use case. You might think about the potential for other capabilities on a class, and you might document this in a comment, but implementation should wait until it is actually needed in a use case.
  • Never add a data member before it is needed in a use case. Exactly like above except with regard to class data members. It may seem obvious that a “customer” record will need a “ship to address”, but that ship to address should not be implemented until you have a use case which specifically needs it.
  • Don’t be afraid to make a decision; don’t be afraid to change an earlier decision. Agile development is about responding to uncertainty and quickly responding. Early in development you do not have complete information. You should delay decisions as long as possible, but there comes a time that a decision is needed to move forward. You can not hold up decision until that information comes in. Instead, make the best decision you can on the available information. Later, when new information arrives, don’t be afraid to change that decision. (Some dinosaurs call this flip-flopping, but I call it reacting to a changing environment.)
  • Continually learn how to improve quality. This job never ends, so you should expect to be constantly on the look out for things that could be improved, and collect examples of ways that quality problems were identified and addressed.
  • Measure, measure, measure. Agile development is help address the problem of uncertainty about the future, but there should be no uncertainty about the past. Tests should be continually running. Performance of every run should be measured and recorded.
  • Design around people, not systems. Too often developers get sidetracked into designing for technical opportunities. You should never lose sight of the ultimate purpose of the software, and that is to help people get work done.
  • Tests are part of the product. Many developers and managers consider the product to be what you ship to the customer, and everything else less important. The tests should be considered an actual part of the product, worthy of full consideration during design, and even, in many cases, delivered with the product to the customer. (This latter part is controversial, but a built-in self-test as part of a software delivery takes inconsequential space, and yet provide tremendous benefit when needed. Such an approach should be considered.)
  • Write the test before the code. The test itself can be used to clarify the design for exactly what is needed. Many times there are flaws in the design approach which are discovered when working through the test cases. Think how much time would be saved to work through those cases before coding. But: write the test for case1, and code for case 1, before starting case 2.
  • Eliminate Waste. Frankly, another ubiquitous platitude which must be included in any list of development principles because it is so important. There is no end to the job of looking for waste where it exists and eliminating it. Eliminate anything that does not add value to the actual customer. If you can not identify the value to the customer, then you probably don’t need it.
  • Build a culture of immediate response to build breakage. Understand that when the build is broken, it effect everyone in the project, and so there is nothing more important than making sure that the central core code is building and testing properly. I have seen teams that allowed broken tests to persist for months because is was someone else’s job. Everyone suffered, but nobody acted. Instead, there needs to be widespread recognition that a little work will pay back in a big way over the team.
  • Every team member needs to understand the needs of the customer. Large complex projects must be broken into separate teams and further divided for handing out to developers, but this should never be done to the extent that people lose sight of the desires and goals of the actual users of the final product.
  • Keep related definitions together. Structure the code so that highly related things are located together, possibly within one class. This is a standard OO design principle of encapsulation. Ideally, all the code outside the class will not need to know the details of the internal workings. Some developers delight in spreading details across multiple files in order to organize in different way: such as to keep all the same data types together, or to organize alphabetically. Fro example, putting all the constants in one class in a different package from where they are being used adds unnecessarily to the complexity of the program. The guiding rule should be to group by relatedness with the result being to hide complexity.
  • Always run the tests before checking in. This guideline will help you satisfy the “never break the build” guideline.
  • Premature optimization is the root of all evil. A quote from Don Knuth which rings true today. Code should be written well to avoid needless waste at the micro level, but optimization beyond the individual method level should wait until testing within the entire program with a stress test bases on an actual end user use case. Intuition of what is important for overall performance is almost always wrong when based only on a static understanding of the code. Instead, measure the behavior of the complete system, to identify the 1% of the code that really makes a different in performance, and focus on that.
  • Minimize backlog of uncompleted coding tasks. When a developer starts to work on a use case, there is a cost associated with all the code that has been modified, but not completed and tested. Holding uncompleted changes for days or weeks adds up to a significant risk of waste due to rework. Consider three tasks estimated to take 1 day each. Starting all three at one time, and working in parallel for three days involves an accumulation of 9 “units” of cost. But doing each task sequentially, completing each task before starting the next, involves only 3 “units” of cost. This is not intuitive. Our intuition tells us that while we are in there, we might as well do three things at once, before buttoning the work up. But software is not like physical construction. Short, quick, and complete jobs not only cause less cognitive load, but also reduce the chance that uncompleted work will conflict with another person’s uncompleted work.
  • Never overgeneralize functionality. This is also know as “YAGNI – You Aren’t Going to Need It” . While coding a particular class, programmers like to think with a small tweak this class might be used for several other purposes. This is fine if those purposes are required by the current use case, but usually the programmer is thinking about uses which have not been invented yet, and which may in fact never be needed. (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)
  • Never use 3 lines when 2 lines would do. Succinctness in code pays every time someone else has to read it. But don’t shrink the code to the point of being difficult to read. Smaller, well written code can easier to maintain and easier to spot errors in, than verbose, ornately written code. Always simplify as much as possible, but no more.
  • Never ever measure code by counting lines. The number of lines needed to do a particular task varies greatly from programmer to programmer, and from style to style. The number of lines of code does not tell you much of anything about the completeness or the quality of the code. Code quality can vary by a factor of 200, and this overwhelms any usefulness of the count of the lines. Count instead functioning use cases.
  • Continually re-design and re-factor. Apply this cautiously because some code is brittle and difficult to change, but in general you should not be afraid to change the code to match the real use case. A data member may have been an integer in the past, but when a use case requires it to be a floating point don’t be afraid to change it.
  • Delete dead code. There is a tendency to let “sleeping dogs lie” when it comes to large blocks of code that is not well understood. One example is adding a new method to a class to replace another, quite often the developer will leave the old method there “just in case”. Some effort should be expended to check to see if that method is needed, and delete it if there is no evidence that it is needed. The worst offense is commenting out blocks of code, and leaving that commented code around. Commented code should be deleted as soon as you know that the tests run, and certainly before checking it in. It is easy to add code at any time, it is hard to delete code at any time. Therefor, at a particular time that you have a good idea that something might not be needed, and small extra effort to verify this and eliminate the code will make the codebase more maintainable.
  • Don’t invent new languages. Programmers love to make text files that drive functionality in way configurable at run-time. There are no end of configuration files to be able to change the behavior of the program without recompiling. The advent of XML is driving an unending chain of specialized custom “scripting languages” that allow functionality to be “programmed” by the end user without having to compile. The flaw in this reasoning is that the precise definition of the behavior of the operations almost never well defined outside of the context of a particular implementation, and these types of scripting languages are mainly useful only to people who have an intimate knowledge of the internal working of the code body in question. Thus, real end users without detailed internal knowledge can never possibly know what is necessary to anticipate the effect of complex combinations of commands. Scripting languages have a use, and can not be eliminated, but the designer must take a very very conservative approach and use existing languages as far as possible, and avoid inventing new ones.
  • Do not create a design until you are ready to implement and test the implementation. You should have some overall idea of where you are going, and a overview of the system architecture that will be aimed for, but no detailed design, no detailed description of functional implementation should be written down until the development iteration that will allow that design to be implemented and tests. The detailed design should cover only as much as is needed to handle the current use case. The biggest cause of waste in software development is time spend designing things that are not needed or need to be redesigned because of some mistaken assumptions that the design is based on.
  • Software is Plastic. Unlike physical manufacturing, software can be changed in significant ways very easily. In fact there is plenty of evidence that software is easier to change than the design specifications that describe the software. Furthermore, software communicates the design more effectively than the specification. Therefor, you should spend the time to implement the design directly, so that customers can see the details of the design. If you miss and have the change the design, it is easier to change the software than it would be to change the spec. But most important, your information about what the customers wants is far better after they have seen the code running.
  • Take the time to code a complete description of the problem in the code that detects and reports exceptional situations. Programmers are often very lazy and throw exceptions with superficial descriptions of what is wrong. Thinking that they are the only people who will ever see the problem, and they will remember the meaning of the problem from the vague description included. But in fact more time is wasted in customer support situations because of inaccurate or incomplete error reports than any other cause. Write every error message is if you are explaining the situation to someone who just walked into the room and has no experience with the code. The customer, and the customer support team, after all, have no experience with the code.

These are presented in no particular order. I welcome comments on principles that I have left out, or (if this is the case) principles that you disagree with.

分享到:
评论

相关推荐

    Delphi 12.3控件之TraeSetup-stable-1.0.12120.exe

    Delphi 12.3控件之TraeSetup-stable-1.0.12120.exe

    基于GPRS,GPS的电动汽车远程监控系统的设计与实现.pdf

    基于GPRS,GPS的电动汽车远程监控系统的设计与实现.pdf

    基于MATLAB/Simulink 2018a的单机无穷大系统暂态稳定性仿真与故障分析

    内容概要:本文详细介绍了如何利用MATLAB/Simulink 2018a进行单机无穷大系统的暂态稳定性仿真。主要内容包括搭建同步发电机模型、设置无穷大系统等效电源、配置故障模块及其控制信号、优化求解器设置以及绘制和分析转速波形和摇摆曲线。文中还提供了多个实用脚本,如故障类型切换、摇摆曲线计算和极限切除角的求解方法。此外,作者分享了一些实践经验,如避免常见错误和提高仿真效率的小技巧。 适合人群:从事电力系统研究和仿真的工程师和技术人员,尤其是对MATLAB/Simulink有一定基础的用户。 使用场景及目标:适用于需要进行电力系统暂态稳定性分析的研究项目或工程应用。主要目标是帮助用户掌握单机无穷大系统的建模和仿真方法,理解故障对系统稳定性的影响,并能够通过仿真结果评估系统的性能。 其他说明:文中提到的一些具体操作和脚本代码对于初学者来说可能会有一定的难度,建议结合官方文档或其他教程一起学习。同时,部分技巧和经验来自于作者的实际操作,具有一定的实用性。

    【KUKA 机器人资料】:KUKA机器人剑指未来——访库卡自动化设备(上海)有限公司销售部经理邹涛.pdf

    KUKA机器人相关资料

    基于DLR模型的PM10–能见度–湿度相关性 研究.pdf

    基于DLR模型的PM10–能见度–湿度相关性 研究.pdf

    MATLAB/Simulink中基于电导增量法的光伏并网系统MPPT仿真及其环境适应性分析

    内容概要:本文详细介绍了如何使用MATLAB/Simulink进行光伏并网系统的最大功率点跟踪(MPPT)仿真,重点讨论了电导增量法的应用。首先阐述了电导增量法的基本原理,接着展示了如何在Simulink中构建光伏电池模型和MPPT控制系统,包括Boost升压电路的设计和PI控制参数的设定。随后,通过仿真分析了不同光照强度和温度条件对光伏系统性能的影响,验证了电导增量法的有效性,并提出了针对特定工况的优化措施。 适合人群:从事光伏系统研究和技术开发的专业人士,尤其是那些希望通过仿真工具深入理解MPPT控制机制的人群。 使用场景及目标:适用于需要评估和优化光伏并网系统性能的研发项目,旨在提高系统在各种环境条件下的最大功率点跟踪效率。 其他说明:文中提供了详细的代码片段和仿真结果图表,帮助读者更好地理解和复现实验过程。此外,还提到了一些常见的仿真陷阱及解决方案,如变步长求解器的问题和PI参数整定技巧。

    【KUKA 机器人坐标的建立】:mo2_base_en.ppt

    KUKA机器人相关文档

    风力发电领域双馈风力发电机(DFIG)Simulink模型的构建与电流电压波形分析

    内容概要:本文详细探讨了双馈风力发电机(DFIG)在Simulink环境下的建模方法及其在不同风速条件下的电流与电压波形特征。首先介绍了DFIG的基本原理,即定子直接接入电网,转子通过双向变流器连接电网的特点。接着阐述了Simulink模型的具体搭建步骤,包括风力机模型、传动系统模型、DFIG本体模型和变流器模型的建立。文中强调了变流器控制算法的重要性,特别是在应对风速变化时,通过实时调整转子侧的电压和电流,确保电流和电压波形的良好特性。此外,文章还讨论了模型中的关键技术和挑战,如转子电流环控制策略、低电压穿越性能、直流母线电压脉动等问题,并提供了具体的解决方案和技术细节。最终,通过对故障工况的仿真测试,验证了所建模型的有效性和优越性。 适用人群:从事风力发电研究的技术人员、高校相关专业师生、对电力电子控制系统感兴趣的工程技术人员。 使用场景及目标:适用于希望深入了解DFIG工作原理、掌握Simulink建模技能的研究人员;旨在帮助读者理解DFIG在不同风速条件下的动态响应机制,为优化风力发电系统的控制策略提供理论依据和技术支持。 其他说明:文章不仅提供了详细的理论解释,还附有大量Matlab/Simulink代码片段,便于读者进行实践操作。同时,针对一些常见问题给出了实用的调试技巧,有助于提高仿真的准确性和可靠性。

    linux之用户管理教程.md

    linux之用户管理教程.md

    三菱PLC与组态王构建3x3书架式堆垛立体库:IO分配、梯形图编程及组态画面设计

    内容概要:本文详细介绍了利用三菱PLC(特别是FX系列)和组态王软件构建3x3书架式堆垛式立体库的方法。首先阐述了IO分配的原则,明确了输入输出信号的功能,如仓位检测、堆垛机运动控制等。接着深入解析了梯形图编程的具体实现,包括基本的左右移动控制、复杂的自动寻址逻辑,以及确保安全性的限位保护措施。还展示了接线图和原理图的作用,强调了正确的电气连接方式。最后讲解了组态王的画面设计技巧,通过图形化界面实现对立体库的操作和监控。 适用人群:从事自动化仓储系统设计、安装、调试的技术人员,尤其是熟悉三菱PLC和组态王的工程师。 使用场景及目标:适用于需要提高仓库空间利用率的小型仓储环境,旨在帮助技术人员掌握从硬件选型、电路设计到软件编程的全流程技能,最终实现高效稳定的自动化仓储管理。 其他说明:文中提供了多个实用的编程技巧和注意事项,如避免常见错误、优化性能参数等,有助于减少实际应用中的故障率并提升系统的可靠性。

    基于STM32的循迹避障小车仿真20250426(带讲解视频)

    基于STM32的循迹避障小车 主控:STM32 显示:OLED 电源模块 舵机云台 超声波测距 红外循迹模块(3个,左中右) 蓝牙模块 按键(6个,模式和手动控制小车状态) TB6612驱动的双电机 功能: 该小车共有3种模式: 自动模式:根据红外循迹和超声波测距模块决定小车的状态 手动模式:根据按键的状态来决定小车的状态 蓝牙模式:根据蓝牙指令来决定小车的状态 自动模式: 自动模式下,检测距离低于5cm小车后退 未检测到任何黑线,小车停止 检测到左边或左边+中间黑线,小车左转 检测到右边或右边+中间黑线,小车右转 检测到中边或左边+中间+右边黑线,小车前进 手动模式:根据按键的状态来决定小车的状态 蓝牙模式: //需切换为蓝牙模式才能指令控制 *StatusX X取值为0-4 0:小车停止 1:小车前进 2:小车后退 3:小车左转 4:小车右转

    海西蒙古族藏族自治州乡镇边界,矢量边界,shp格式

    矢量边界,行政区域边界,精确到乡镇街道,可直接导入arcgis使用

    基于IEEE33节点的主动配电网优化:含风光储柴燃多源调度模型的经济运行研究

    内容概要:本文探讨了基于IEEE33节点的主动配电网优化方法,旨在通过合理的调度模型降低配电网的总运行成本。文中详细介绍了模型的构建,包括风光发电、储能装置、柴油发电机和燃气轮机等多种分布式电源的集成。为了实现这一目标,作者提出了具体的约束条件,如储能充放电功率限制和潮流约束,并采用了粒子群算法进行求解。通过一系列实验验证,最终得到了优化的分布式电源运行计划,显著降低了总成本并提高了系统的稳定性。 适合人群:从事电力系统优化、智能电网研究的专业人士和技术爱好者。 使用场景及目标:适用于需要优化配电网运行成本的研究机构和企业。主要目标是在满足各种约束条件下,通过合理的调度策略使配电网更加经济高效地运行。 其他说明:文章不仅提供了详细的理论推导和算法实现,还分享了许多实用的经验技巧,如储能充放电策略、粒子群算法参数选择等。此外,通过具体案例展示了不同电源之间的协同作用及其经济效益。

    【KUKA 机器人资料】:KUKA 机器人初级培训教材.pdf

    KUKA机器人相关文档

    基于MATLAB的CSP电站与ORC综合能源系统优化建模及应用

    内容概要:本文详细介绍了将光热电站(CSP)和有机朗肯循环(ORC)集成到综合能源系统中的优化建模方法。主要内容涵盖系统的目标函数设计、关键设备的约束条件(如CSP储热罐、ORC热电耦合)、以及具体实现的技术细节。文中通过MATLAB和YALMIP工具进行建模,采用CPLEX求解器解决混合整数规划问题,确保系统在经济性和环境效益方面的最优表现。此外,文章还讨论了碳排放惩罚机制、风光弃能处理等实际应用场景中的挑战及其解决方案。 适合人群:从事综合能源系统研究的专业人士,尤其是对光热发电、余热利用感兴趣的科研工作者和技术开发者。 使用场景及目标:适用于需要评估和优化包含多种能源形式(如光伏、风电、燃气锅炉等)在内的复杂能源系统的项目。目标是在满足供电供热需求的同时,最小化运行成本并减少碳排放。 其他说明:文中提供了大量具体的MATLAB代码片段作为实例,帮助读者更好地理解和复现所提出的优化模型。对于初学者而言,建议从简单的确定性模型入手,逐渐过渡到更复杂的随机规划和鲁棒优化。

    网站设计与管理作业一.ppt

    网站设计与管理作业一.ppt

    基于MATLAB的双闭环Buck电路仿真模型设计与优化

    内容概要:本文详细介绍了如何使用MATLAB搭建双闭环Buck电路的仿真模型。首先定义了主电路的关键参数,如输入电压、电感、电容等,并解释了这些参数的选择依据。接着分别对电压外环和电流内环进行了PI控制器的设计,强调了电流环响应速度需要显著高于电压环以确保系统的稳定性。文中还讨论了仿真过程中的一些关键技术细节,如PWM死区时间的设置、低通滤波器的应用以及参数调整的方法。通过对比单闭环和双闭环系统的性能,展示了双闭环方案在应对负载突变时的优势。最后分享了一些调试经验和常见问题的解决方案。 适合人群:从事电力电子、电源设计领域的工程师和技术人员,尤其是有一定MATLAB基础的读者。 使用场景及目标:适用于需要进行电源管理芯片设计验证、电源系统性能评估的研究人员和工程师。主要目标是提高电源系统的稳定性和响应速度,特别是在负载变化剧烈的情况下。 其他说明:文章不仅提供了详细的理论分析,还包括了大量的代码片段和具体的调试步骤,帮助读者更好地理解和应用所学知识。同时提醒读者注意仿真与实际情况之间的差异,鼓励在实践中不断探索和改进。

    MATLAB实现冷热电气多能互补微能源网的鲁棒优化调度模型

    内容概要:本文详细探讨了MATLAB环境下冷热电气多能互补微能源网的鲁棒优化调度模型。首先介绍了多能耦合元件(如风电、光伏、P2G、燃气轮机等)的运行特性模型,展示了如何通过MATLAB代码模拟这些元件的实际运行情况。接着阐述了电、热、冷、气四者的稳态能流模型及其相互关系,特别是热电联产过程中能流的转换和流动。然后重点讨论了考虑经济成本和碳排放最优的优化调度模型,利用MATLAB优化工具箱求解多目标优化问题,确保各能源设备在合理范围内运行并保持能流平衡。最后分享了一些实际应用中的经验和技巧,如处理风光出力预测误差、非线性约束、多能流耦合等。 适合人群:从事能源系统研究、优化调度、MATLAB编程的专业人士和技术爱好者。 使用场景及目标:适用于希望深入了解综合能源系统优化调度的研究人员和工程师。目标是掌握如何在MATLAB中构建和求解复杂的多能互补优化调度模型,提高能源利用效率,降低碳排放。 其他说明:文中提供了大量MATLAB代码片段,帮助读者更好地理解和实践所介绍的内容。此外,还提及了一些有趣的发现和挑战,如多能流耦合的复杂性、鲁棒优化的应用等。

    Simulink与Carsim联合仿真:基于PID与MPC的自适应巡航控制系统设计与实现

    内容概要:本文详细介绍了如何利用Simulink和Carsim进行联合仿真,实现基于PID(比例-积分-微分)和MPC(模型预测控制)的自适应巡航控制系统。首先阐述了Carsim参数设置的关键步骤,特别是cpar文件的配置,包括车辆基本参数、悬架系统参数和转向系统参数的设定。接着展示了Matlab S函数的编写方法,分别针对PID控制和MPC控制提供了详细的代码示例。随后讨论了Simulink中车辆动力学模型的搭建,强调了模块间的正确连接和参数设置的重要性。最后探讨了远程指导的方式,帮助解决仿真过程中可能出现的问题。 适合人群:从事汽车自动驾驶领域的研究人员和技术人员,尤其是对Simulink和Carsim有一定了解并希望深入学习联合仿真的从业者。 使用场景及目标:适用于需要验证和优化自适应巡航控制、定速巡航及紧急避撞等功能的研究和开发项目。目标是提高车辆行驶的安全性和舒适性,确保控制算法的有效性和可靠性。 其他说明:文中不仅提供了理论知识,还有大量实用的代码示例和避坑指南,有助于读者快速上手并应用于实际工作中。此外,还提到了远程调试技巧,进一步提升了仿真的成功率。

Global site tag (gtag.js) - Google Analytics