敏捷实践的横向与纵向开发，重点在于单元测试 [英] Horizontal vs vertical development for Agile practices with an emphasis on unit testing

问题描述

抱歉，这是一个抽象问题.

我们的开发团队正在成长，我的任务是确保建立有效的流程来对其进行管理.

我们目前使用的是非结构化的原型方法，因此我建议使用敏捷方法(例如Scrum)来构建此模型.

我们强调要提高质量，因为我们的产品中经常会出现不兼容的情况，直到在生产环境中实现这些不兼容之后才可以发现.

我们开发了一种SOA解决方案，其中包含多个应用程序/服务，每个应用程序/服务都消耗一个或多个服务.

我已经使用敏捷模板配置了TFS，设置了持续集成和自动化的单元测试.已发布分支和合并策略.使用SOLID原则定义的编码标准.但是我们还没有单元测试.

我正在尝试了解横向或纵向的开发方式或混合方式是否有利于实施有纪律的单元测试机制，特别是在现有开发人员会产生抵制的环境中?

任何评论，建议或与相关文章的链接都将不胜感激.

Hi,

Sorry this is a bit of an abstract question.

Our development team is growing and I''ve been tasked with ensuring effective processes are in place for managing them.

We currently use an unstructured prototyping methodology so I''m proposing we structure this with an Agile methodology such as Scrum.

There''s an emphasis on improving quality as often incompatibilities appear in our product which aren''t identified until implemented in a production environment.

We''ve developed a SOA solution with multiple applications/services each consuming one or more services.

I''ve configured TFS with an Agile template, set up continuous integration and automated unit testing. Published branching and merging policies. Defined coding standards using the SOLID principles. But what we don''t have yet are the unit tests.

I''m trying to develop an understanding of whether a horizontal or vertical approach to development or perhaps a hybrid approach would be beneficial to enforcing a disciplined regime of unit testing, especially in an environment where there will be resistance from existing developers?

Any comments, recommendations or links to relevant articles would be much appreciated.

推荐答案

这是一个非常大而复杂的问题，因此我可以给您一些注释. />
首先，我认为垂直或水平切片的应用不会对单元测试产生太大影响.为什么?一个单位就是一个单位.它不是一个完整的层或一个垂直的故事"，而是一个较小的开发和隔离单元.通常，该单元的作者会为此开发单元测试集，但是此测试可以由其他人进行审查和更新非常重要:一个人，尤其是原始作者经常对他们有所了解，并且这种有限的视野通常会阻止随后看到的问题或疑虑对某些人来说是新鲜的眼光.

现在，关于垂直拼接与水平拼接.至少在他们看来，有很多敏捷绝对主义者提出了非常有力的论据来支持垂直切片.参见例如:
http://www.cincomsmalltalk.com/userblogs/buck/blogView?entry=3311184808 [ ^ ]，
http://agilewarrior.wordpress.com/2009/07/27/horizo​​ntal-vs -vertical-slicing/ [ ^ ].

事情是这样的:我看到了许多关于软件开发方法的书籍和文章，其中一些是由知名人士撰写的；而且我从来没有见过这样的人会令我热衷于用一种方法来武装自己.不要误会我的意思:我不反对方法，也不反对方法.在我看来，这只是一切，不像一门真正的科学，而是像某些亵渎学.同时，一些方法和书籍反映了真实的经验，无论是正面的还是负面的.因此，我会说我会建议一些混合方法，很难说到底有多精确.最好说，不是它们应该是混合的，它们应该是项目驱动的，也就是说，应该根据许多不同的因素来构建和调整方法，以代替工作:主要项目目标，资源，可用代码和技术，以及非常重要的是涉及人员.

谈到支持坚强的垂直方法的牢不可破"的论点，我总能指出一些严重的弊端.该层是由整个团队塑造的?但是，谁来负责它的完整性，优雅性，统一的体系结构和设计呢?层的开发是逐步进行的吗?这很好，但是谁能阻止它的侵蚀呢?该图层将没有所有的花哨功能，也就是说，是否有多余的功能?但是如何实现新功能?逐个?然后，您冒着陷入即席风格的危险，从而有效地防止了代码的重用或刺激了常用实用程序或算法的侵蚀.因此，我的结论是:最谨慎的方法是混合，但应根据项目的具体情况来设想混合的位置和程度，并在开发过程中进行交互式调整.强大的敏捷支持者不珍视同一种交互式方法吗?我想我在使用敏捷开发"这个术语之前就已经在使用敏捷元素，但是方法一直在变化.而且永远不会完美.

现在，我想谈谈项目负责人的角色.即使敏捷思想可以促进团队成员之间决策的分配；这是一个好趋势，该过程需要有人维护适当的体系结构，对代码和开发纪律的要求，而这不仅与正式程序保持一致，否则不可避免地会侵蚀项目，导致无法控制的熵积累.无论您发明什么方法，它都必须是一小撮人中的一个.在我看来，再也没有两三个了.这样的人或团队应该能够预见项目和开发过程的未来，并预见一些谬论.这需要非常狡猾的愿景和经验.这样的人无法预见一切，但他们会犯错.最好的领导力不是当领导者没有犯错并避免他人犯错误时.这看起来几乎是不可能的；不，好的领导者是在错误最终得到纠正后，但修复程序并不会破坏项目.

最后，我想提到一个痛苦的问题，例如非技术项目经理(有时甚至是建筑师")的问题.我的意思是说，非技术人员或作为软件开发人员的工作做得不够.这是经常发生的事情，这是所有软件行业的诅咒.它的机制是可以理解的:人们不想浪费才华的开发人员来进行管理，因此一些对创意开发和技术决策过于不满意的较差或平庸的开发人员被提升"为管理人员.结果，每个人都遭受苦难.没有人尊重这样的人并抗拒，这样的经理阻碍了好的决定，提倡糟糕的决定，造成压力并遭受所有这些的折磨.当这样的人有太多的主动权时，情况就更糟了.它经常造成灾难.我认为许多开发人员都非常熟悉此类设置，但通常不会谈论它.知识渊博的人提高自己的声音以防止这种情况真的很重要.这不容易.

好，我为什么要写作和写作?整篇文章……让我在这里四舍五入.

感谢您的阅读，

—SA

This is a very big and complex problem, so I can give a few notes.

First, I don''t think the application of a vertical or horizontal slicing does not effect the unit testing so much. Why? A unit is a unit. It is not a whole layer or a vertical "story", but a smaller unit of development and isolation. Normally, the author of the unit develops the unit test set for it, but it''s very important that this test could be reviewed and updated by others: one person, especially the original authors often have some vision they are preoccupied with, and this limited vision often prevent then from seeing problems or concerns apparent to some people of fresh glance.

Now, about the vertical vs. horizontal splicing. There is a good number of Agile absolutists who bring very strong arguments in favor of vertical slicing, at least in their opinion. See for example:
http://www.cincomsmalltalk.com/userblogs/buck/blogView?entry=3311184808[^],
http://agilewarrior.wordpress.com/2009/07/27/horizontal-vs-vertical-slicing/[^].

Here is the thing: I saw so many books and articles on the software development methods, some are written by people of big well-known names; and I never saw one which would make me too enthusiastic about arming myself with a method''s techniques. Don''t get me wrong: I am not against the method and not against methodology. It''s just everything looks to me not like a real science but rather like some blah-blahology, so to speak. At the same time, some methods and books reflect real experience, positive or negative. So, I would say I would advise some hybrid approaches, hard to say how exactly. It''s better to say, not that they should be hybrid, they should be project-driven, that is, the method should be built and adjusted in place of work, depending on many different factors: major project goals, resources, available code and technologies, and, very importantly, people involved.

Speaking of the "unbreakable" arguments in favor of strong vertical approach, I can always point out some serious drawbacks. The layer is shaped by the whole team? But then, who would be responsible for its integrity, elegance, unified architecture and design? Development of a layer is performed incrementally and constantly? This is good, but who will prevent the erosion of it? The layer will be free from all the bells and whistles, that is, redundant features? But how the new features can be implemented? One by one? Then you risk to fall into ad-hoc style, effectively preventing reuse of the code or stimulating erosion of commonly used utilities or algorithms. So, my conclusion is: some hybrid approach is the most prudent, but the location and degree of hybridization should be envisioned based on the project specifics and adjusted interactively during development. Isn''t this the same interactive approach so valued by the strong Agile proponents? I think I was using Agile elements well before the term "Agile development" was coined, but the method was ever changing. And never perfect.

Now, I want to touch the role of the project leader. Even though Agile ideas promote distribution of the decision making among the team members; and this is the good trend, the process needs someone to uphold proper architecture, requirements to the code and development discipline, and this is not just keeping up with the formal procedures, otherwise the erosion of the project an unmanageable entropy build-up is unavoidable. Whatever method you invent, it has to be one person of a very small group of people; in my opinion, no more them two or three. Such person or a group should be able envision the future of the project and development process and foresee some of the fallacies. It takes a very cunning vision and experience. Such people cannot foresee everything, but they can do mistakes. The best leadership is not when the leaders make no mistake and keep others out of mistakes; this looks nearly impossible; no, the good leadership is when the mistakes are finally fixed, but the fixes are not so expensive to ruin the project.

And finally, I want to mention such a painful problem as the problem of a non-technical project managers (and sometimes even "architects"). I mean, non-technical or not doing enough work as a software developer. This is something which often happens, and this is a curse of all the software industry. The mechanism of it is quite understandable: people don''t want to waste the time of talented developers for the management, so some worse or mediocre developers who just are too uncomfortable with creative development and technical decision making are "promoted" to the management. As a result, everyone suffers; nobody respect such people and resist, such managers block good decisions and promote lousy ones, create tension and also suffer from all of it. It goes even worse when such people gets too much initiative; it often creates disaster. I think many developers are well familiar with such settings but usually don''t speak about it. It''s really important that the knowledgeable people raise their voice to prevent such situations. This is not easy.

OK, why am I writing and writing? A whole essay… Let me round up here.

Thank you for reading,

—SA

这篇关于敏捷实践的横向与纵向开发，重点在于单元测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！