常见软件项目开发模式思考

一、软件项目

在2000左右 程序员还是一种比较罕见的工作，那是的个人台式机还是当时富裕家庭的高级娱乐用品，一开始网络程序员部分前后端，PHP、JSP、ASP这些技术形成了最早的网络程序。BS 系统

简单的设计文档在那时形成，同时诞生了一批技术、团队的外包公司，外包公司比较推崇敏捷开发，单具体操作起来就是一次性开发，根据合同内容，设定好开发目标，利用公司现有的技术架构，快速实现一套系统。

敏捷开发的好处就是短时间内多做项目，多赚钱，对于系统的使用者来说，系统上线之后 开始用着还可以，随着时间的推移，问题暴露的越来越多，导致 系统越来越难用，最后再找一家公司重新开发，往复循环。

或者公司自身成立技术团队，在系统交付之后二次开发，但是一开始设计的时候很少考虑后期扩展，对接收团队的技术、业务能力要求极高，设想一下，一栋建筑，交付之后 给物业做一些日常工作，业主突然有一天要把电梯改成旋转楼梯，还不能影响入驻的客户。

软件项目和我们的生活息息相关，但却是一个年轻的行业，年轻意味着缺少系统性的沉淀，加之软件是虚拟的逻辑整理，没有实体可以感受，一个项目的好坏外行很难看出来，只有实践才能检验。

本文将从开发模式角度入手，分析讨论业务、产品、开发、测试 直接的协作关系，和具体的开发模式的差异。

项目质量的保证，项目的管理心得。

1.1管理离不开技术

软件开发的管理人员一般是产品、开发、测试出身、

产品距离业近，经常和公司管理层打交道，对于业务驱动的公司来说，产品的话语权更高，晋升管理的概率更大，产品出身的管理需要有一个沟通协作良好的开发团队，信任开发给出的技术方案，工时评估，

设想，一个产品提了一份用户头像编辑的功能，技术团队开始确认细节，头像格式的支持、头像图片大小的限制、图片存储方案、头像图片压缩、历史头像存储、头像图片的审核、头像的中文字审核，越是用户多的系统考虑的细节越多，例如头像的文字审核，涉及到OCR、文本处理，这就需要技术强悍的开发人员，设计实现一套可行性方案，考虑产品需求，实现成本、运行成本、维护成本。

需求评估就得需要两天，根据产品确认的需求再确定具体的方案

曾经遇到过产品主管和技术主管沟通不畅，产品找自己信任的开发评估工时的情况。

技术晋升管理走的是技术路线，针对技术部 开发和测试的管理，技术管理主要的协调开发资源，处理跨团队沟通协作，评审团队内部技术方案，不对业务负责。典型如CTO

测试管理，很少遇到，目前测试正在朝着开发测试的方向发展，对测试的技术能力要求越来越高，对比专职开发，测试的技术水平相对浅显，测试 的有事是对于业务很熟练。

开发团队的管理很大程度和领导的个人风格有关系，人都有喜好，很难做到公平公正。

个人认为软件团队的管理主要内容是资源协调，优化开发周期，控制风险，推动困难解决。

对于管理人选 可以根据不同业务场景具体分析，综合分析开发人员最合适，其次是产品

管理需要实践和经验，你的组员突然请假三天怎么办，组员水平低怎么安排，怎么激发组员的工作积极性，这些似乎都没有模板化的方案，
如果一个管理者只是在分配任务，没有担当，不了解项目细节，这个项目很难顺利进行。

二、开发模式

2.1TDD Test-Driven Development

TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。（摘自百度百科）

测试驱动，分广义和狭义，两者都属于敏捷开发的定义范围，
个人不推荐敏捷开发，敏捷意味快速高效，除非是外包公司流水线的开发团队，例如一套人事管理系统已经完成，A 、B 、C 三家公司都需要一套人事管理系统，但是需求细节不完全相同，这时候利用以前的开发团队，和已经有的系统可以实现敏捷开发。

前提条件：对所开发的业务非常熟悉，技术架构成熟。

对于一般规模的管理系统，三五个开发人员 10人以下的团队，没有高并发，高可用的管理系统适用。

互联网公司很少提到敏捷开发，网络服务千头万绪。

回到TDD ，就是以测试为核心，写代码之前先写单元测试，之后写代码，测试用例可以覆盖整个业务，这需要测试对于业务逻辑很熟悉，保证所有测试用例能覆盖所有的业务逻辑情况，不仅仅是happy ending。

测试驱动没有实践过，个人目前的理解 对于业务简单的系统，常见开发模式都可以胜任，业务简单，场景少，只需要重点关注技术架构 ，技术选型。

但对于业务复杂的系统，则不适用，如果测试用例可以覆盖一套业务逻辑复杂的系统，那么整个开发部门测试人员将是比例最高的

开发模式和业务业务复杂度息息相关，单纯的并发高，业界已经有了程序的解决方案，如果并发高加上业务复杂则是对团队能力的挑战。

试想，一个完整的线上会员购买流程，需要 账户、会员、订单、支付、可能还有营销、售后的业务模块整体协作完成，这单元测试怎么写，

如果我们呢把每个模块都写对应的单元测试
， 恐怕测试代码的比例要超过业务逻辑。

单元测试保证基本的代码运行，保证某一段的逻辑正常。

但对于整体 还是需要测试部门手工测试

参考总资料：
https://stackify.com/what-is-test-driven-development/
https://www.guru99.com/test-driven-development.html

What Is Test Driven Development?
ERIC BOERSMAMARCH 23, 2020DEVELOPER TIPS, TRICKS & RESOURCES

When I’m writing new software, one of the most important thoughts in my mind is how I’ll test to make sure it works. There are lots of ways to test software, and when you’re at your best, you should be using all of them. Sure, you should make sure that your QA team is able to verify that your code works before it goes live. You should make sure that the code passes acceptance tests, too. In the best shops, you’ll even have a robust suite of unit tests to ensure that small units of code behave the way that they should.

Lots of times, I’ll write some code, and then write a few tests to make sure that it works. That’s not a bad system. But what would happen if we flipped that process on its head? What if we wrote the tests first, then wrote code that would make the tests pass?

New call-to-action
Test Driven Development: Writing Your Tests Backwards
This method of flipping around how you write your tests is the core idea behind Test Driven Development. Instead of writing your code, you write your tests first. Then, even though you know they won’t pass, you run the tests. You watch them fail?

Why?

Because if your tests fail, you know that you’ve written an effective test. If every test you write only ever passes, that can conceal subtle bugs which make your tests ineffective. I know that I’ve written tests before which always passed. When I ran my tests to ensure my code worked, I was operating under a mistaken sense of security. It turned out that my code didn’t work, but I had no way of telling. My test had never failed, so I had no idea that it wasn’t effectively testing my code. It took until some time later that I realized my error. Sometimes, the bug even made it to production before I noticed.

After you’ve seen your test fail at least once, you write code that makes the test pass. One of the core tenets of Test Driven Development is that you write only enough code to make the test pass.

What Are Some Benefits of Test Driven Development?
In addition to the aforementioned benefits of writing your tests backwards, Test Driven Development provides other benefits. Like we mentioned before, thinking about how you’ll test your code is a key part of building effective software. As a developer, one of your roles is to write software that’s easy to verify. You don’t want to ship code only to find out later that it doesn’t work. Catching defects early saves time and money.

With TDD, thinking about how you’ll test your code is a core part of the code-writing process. You’re writing the tests for your code while you write your code. If you’re an experienced developer, you’ve probably experienced writing a big chunk of code. You’re pretty sure it works, but as you lean back, you have no idea how to guarantee that the code you wrote works the way you expect. With Test Driven Development, that’s never a concern. You’re building your tests right into the process of writing the code itself.

Writing Less Code With Test Driven Development
Another benefit of Test Driven Development is that you write less code. Remember before how we talked about writing just enough code to make the test pass? That’s a key part of the Test Driven Development philosophy. As a developer, your job is to take your feature requests and turn them into testable features. Then, you write the tests for those features and finally the code that satisfies those tests. As we’ve said before, the key is to just write the code that satisfies those requests.

The benefit here is that writing just the code that satisfies the tests means you write fewer bugs. Why? Well, the argument goes, developers are prone to writing more code than they actually need at any given time. I know that I’m guilty of this. I’ll often try to build a more robust, complex solution than the current problem calls for. These robust solutions often lie dormant, because we’re not using all their features. They’ll be useful “someday.” In reality, that code is often never useful. That feature I thought was so important at the time turns out to never be needed. Or, by the time it’s useful, the parameters of that use have changed so that the code needs to be heavily modified before application.

This approach is an extreme variant of the “You Aren’t Gonna Need It” mentality. I know that as a developer, I regularly have to remind myself not to needlessly complicate my work by trying to solve future problems. Effectively adhering to Test Driven Development is a big benefit there.

Test Driven Development Means Easier Refactoring
Another major benefit to Test Driven Development is easier code refactoring. I’ve written enough code in my life to never expect that the work I do is permanent. I fully expect that every piece of code I ever write will be changed by someone down the line. It might be after I’m long gone, but it’ll happen, someday. When that day comes, I want to make it easy for that future teammate (or my future self!) to know how those changes break code that relies on mine. This is another benefit of the TDD philosophy. The tests that I write for my code serve as a form of documentation. It’s also a contract with other parts of the code base. So long as my code continues to pass all the tests I wrote for it, that code behaves the way the rest of the code expects.

So, if someone ever needs to refactor my code, they can do so confidently. The same is true if their refactoring breaks one of the tests. It might be that they need that test to change! It’s OK to refactor things and for those changes to break code. With a broad suite of unit tests, like those proscribed by TDD, you’ll know which behaviors of the code you’re changing. Then, as the person making those changes, it’s up to you to make sure you fix all the places that code is used.

black and silver laptop computer on brown wooden table
Taking Test Driven Development to the Next Level
Test Driven Development is a powerful philosophy. Most developers that follow it truly write better code. But it’s not enough on its own to deliver bug-free software. You’ll need to add more skills to your testing tool belt to deliver the best software that you can.

That’s where a tool like Prefix comes in. Prefix works best in test-driven teams. It runs on your local machine, and works like a web-request profiler. But it’s really powerful: it provides a lot more insight than an average profiler. It’s also really easy to read and understand the data it shows you. This means that if you’re working with one of the languages it supports, like Java and C#, you’ll find more bugs more quickly. You’ll also quickly identify bottlenecks in your code that are killing your performance. Even the best unit tests can’t tell you why or where your code is slow. Using Prefix will give you visibility into your code that you can’t get from tests alone.

Give Test Driven Development a Try
Test Driven Development isn’t for everyone. I’ll be honest: I don’t use it for every piece of code that I write. But I do find the lessons it teaches to be valuable in writing better, clearer, bug-free code. It’s a good idea for every developer to give Test Driven Development a try, for at least a little while in their career. You’ll learn how to build better tests, and how to trust those tests to write better code.

Is today the right day for you to take your first steps into Test Driven Development? I don’t see why not!

2.2BDD

Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。06年提出。

行为驱动开发 强调全部角色参与，集体思维覆盖系统中所有的行为，BDD定义为敏捷开发的一种，网上也有一种观点BDD 是TDD 的一种变种，
作为开发者，没有实践过BDD的开发模式，其实没有最好的开发模式，只有最适合某种业务的开发模式，世界复杂，业务千变万化，个人认为在选择开发模式的时候，针对具体的业务，其中最重要的影响因素是业务的复杂度，
国内，很多用户认为技术是万能的，有时候甚至提出来拦截用户收到的短信验证码的需求，很少见到有业务为技术让路的场景。

针对行为驱动的开发模式思考：

以一家行业内建材B2B 平台业务举例，业务对接产品、产品对接开发、测试、设计。

整个流程是产品为中心，这就对产品的岗位综合要求最高，但是一个项目或者一个版本上线的时候，考虑的因素纷繁复杂，例如开发排期，针对历史业务的兼容，数据迁移，服务器环境，并发量，是否对接第三方，技术选型等

由于产品针对业务逻辑设计需求，由于平台业务复杂，产品的逻辑相互依赖影响，这就需要一个level 比较高的人能掌握平台的所有业务逻辑，针对不断堆积的业务逻辑进行梳理。

若是采用BDD的模式，全员会针对产品逻辑提出自己的问题，看法，这样产品设计的业务逻辑就很难达成一致，反而不会那么敏捷，

如果场景简单的系统，那么即便是口头沟通也不会有大问题。

参考资料：https://specflow.org/bdd/

2## 标题.3 DDD

领域驱动设计是由 Eric Evans在其开创性著作 Domain Driven Design：

Trckling Complexity in the heart of software 中定义的一种发展理念。

DDD 擅长解决复杂的业务逻辑，这一点业界很少有反对，使用DDD的开发模式，强调业务的规划，管控，往往需要一个精通业务的领域专家，这个角色往往有项目经理或者架构师承担，业务精通则通过和具体业务人员的沟通取得。

DDD 的特点很鲜明，实践起来也也行之有效。

缺点则是 学习曲线高，03年发布之后 后续没有进一步优化，可见业界软件的系统往往不复杂，很多时候使用TDD 或者BDD 都可以实现需求。

DDD 之前应用于大规模的复杂的业务系统，对于简单的系统来说应用DDD

有点成本过高，个人建议，简单系统也可以使用DDD 开发模式，优点是降低开发、业务、测试之间的沟通成本，设计、开发阶段可以预留足够的扩展空间，有助于延长软件系统的寿命。
是的
大部分软件系统都有自己的预期寿命，少则3年 ，多则5年。
根据熵定律 一个系统如果没有新的能力注入 则慢慢会释放能力变回自然状态，自然状态的CPU和沙子没啥区别。