资深架构师的经验分享——软件项目开发和决策

这篇文章是关于什么的

参与项目决策的人必须意识到他们的决定对项目的成功和成本以及时间和金钱的影响。

对于我20多年的软件开发经验和10多年的咨询工作，我作为架构师或开发人员参与了许多项目 - 其中大多数成功，有些失败，但每个项目（无论成功与否）都涉及好的和不好的决策由各种人制作。

本文的目的是通过提倡根据我的经验做出的决定以及避免错误的决策来为项目成功奠定基础。

总的来说，我拥有C ++，Java，C＃和JavaScript的经验，但在过去的10年中，我一直主要致力于C＃桌面应用程序。尽管如此，这里提出的许多想法都具有一般性。当我讨论一个C＃桌面应用程序时，我明确地陈述它。

软件开发始终存在一个“政治组件” - 本文不涉及这一点。本文的目的是提供建议，以最大限度地提高客户满意度，同时最大限度地减少支出。

项目开发主要指南

在这里，我介绍了软件开发的两个主要准则，这将在文章中进一步详细描述。

1. 在软件开发主题上有很多书籍，文章和更多的广告垃圾。用一粒盐吧！如果你读的东西与常识冲突 - 选择常识。

2. 在公司，项目或个人层面，需求的传播（特别是API需求）应该从使用它的人（客户）流向构建它的人，而不是相反。通过客户端，我也指同一项目中使用其他人构建的软件的开发人员。这个非常重要的规则常常被忽视，不利于项目的成功。

在项目的开始

在一个项目的开始阶段就要做出一些重要的决定。理论上，在项目开始时做出的错误决策可以稍后纠正。然而，错误的决定浪费的金钱或时间越多，后来纠正的可能性越小，因为纠正它们会引发能力问题。

选择一种语言

对于一门语言，我强烈建议不要使用C ++（除非你正在构建一些非常高性能的算法，因为它的编译时间很慢，因此一秒钟的分裂至关重要）。每个软件开发（如果正确完成）都涉及很多原型设计，并重新启动应用程序或为应用程序运行测试。代码更改后的每次新运行都涉及编译。C ++模板的构建方式是在编译时必须生成代码，这样C ++通常编译起来非常慢。编译速度缓慢将导致原型设计速度缓慢，开发速度相应缓慢。没有模板，C ++没有现代强类型语言那么强大。

而且，Java和C＃拥有许多内置于该语言的标准库，而C ++则依赖于第三方库。

最佳团队规模

在我的经验中，较小的团队可以更快地生成更好的软 例如，对于桌面三层项目，我会推荐一个3人团队 - 每个层级一个人+一个建筑师+ 1-3个裁员。

我最成功的项目正是由3-7名成员组成的团队。我参与过的最不成功的项目之一是拥有20多名成员的团队，几年内无法实现几个月内小型项目将实现的目标。

Scrum或不Scrum

毫无疑问 - 对Scrum来说！敏捷/ Scrum可能并不完美，但它比替代品更好。然而，Scrum的某些方面并不有效（我认为它们不应该成为过程的一部分，尽管大多数敏捷教科书都会提到它们）。以下是scrum的正面和负面特征列表。我的建议是：避免使用负面特征。

Scrum的积极

1. 通常，在项目开始时，客户本身可能不清楚他们需要什么。它需要很多迭代（包括客户和开发人员的错误）让客户弄清楚需要构建什么，以及开发人员如何构建它。Scrum的迭代方法最适合这种范式。

2. 在scrum之下，开发人员可以估计自己需要多长时间才能实现某个功能 - 他们通常可以做得比管理人员好得多。

3. 每日更新对经理和开发人员都有益。双方都可以更好地了解项目的位置。此外，对于开发者来说，这是一个与他人分享他们一直在努力工作的机会，以便了解他人正在做什么，并且一般来说，在编程时可以锻炼大脑的非编程部分部分休息一下。

4. Scrum会议结束后，包括演示和计划在内，也会因日常会议的原因而受益，但规模较大。

Scrum的负面影响

1. 一些Scrum版本倡导只跟踪整个团队的表现 - 不考虑个人开发者的贡献。虽然团队绩效非常重要，但认识个人努力仍然很重要。

2. 在Scrum结束时召开了会议，人们捶胸说出了什么问题 - 越多越好。我从来没有看到从他们身上出现任何好东西。发生问题时，应由开发人员解决。更严重的问题应该升级到建筑师/经理，有时候应该改变项目程序。

对等编程