当您需要在公司建立软件开发基础架构时，什么最重要？
假设您在一家大公司工作，该公司突然决定进行定制的内部软件开发。 此外，他们还希望能够为客户提供成功的开发（如果有的话）。
现在你负责它。
您认为构建成功的软件开发基础设施最重要的是什么？
- 应对未来的增长
- 灵活使用所使用的技术（使用 c、java、.net、web、移动等的项目）
- 灵活 工具（源代码控制、锻造……）、硬件（虚拟、单独的开发和生产……）、流程（指南、代码审查……）等。
更新：请不要回答说您需要合适的人员和合适的工具。 这正是我正在寻找的......什么是正确的工具以及您将首先雇用什么类型的人员加入您的团队？ 将其视为您将成为该开发的领导者。
Let's say you work for a huge company which suddenly decides to do custom in-house software development. Additionally, they want to be able to offer successful developments to their customers as well (if any).
Now you are in charge of it.
What would you see as most important to build a successful software development infrastructure?
- flexible to future growth
- flexible on used technologies (projects with c, java, .net, web, mobile, ...)
- What kind of tools (source control, forge, ...), hardware (virtual, seperate dev & production, ..), processes (guidelines, code reviews, ...), etc.
UPDATE: Please don't answer that you need the right people and the right tools. This is exactly what i am looking for.. What are the right tools and what people of what type would you hire first to join your team? Think of it as you will be the lead of that development.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
您应该雇用的第一批人应该是经验丰富的高级专业人员。 然后根据他们/他们的意见进行构建。 稍后添加初级人员。
The first persons you should hire should be experienced senior level professionals. Then build up from them / with their input. Add the junior people later.
显然，有很多因素，但我认为以下是至关重要的：
Obviously, there are lots of factors, but here are the ones I'd say are crucial:
不要试图在技术上保持灵活性。 首先从专注于一种技术（Java、.NET，等等......）开始，然后根据需要转向其他技术。 你可以使用任何技术来解决问题，但很难找到擅长许多技术的人。
在基础设施层面，源代码控制是必须的。 持续集成是一个优点。 花一些时间制定一个您将能够改进的标准项目布局。 它使开发人员更容易切换项目。 花时间建立一个良好的构建过程（Ant、Maven，在 Java 世界中）。 将构建过程与 IDE 集成，这样开发人员就不必在每次想要测试代码更改时等待 5 分钟来部署项目。
Dont try to be flexible in technologies. First start by focusing on one technology (Java, .NET, whatever...) and then move to other if you need to. You will be able to solve problems using any technologies, but it is very hard to find people good in many technologies.
At the infrastructure level, Source Control is a must. Continuous integration is a plus. Take time to put in place a standard project layout that you will be able to evolve. It make it easier for developers to switch projects. Take time to put in place a good build process (Ant, Maven, in the Java world). Integrate your build process with your IDE so that developers dont have to wait 5 minutes to deploy their project every time they want to test a code change.
我同意纪尧姆的观点：如果你想从头开始建立一个部门，你需要集中精力。 你需要建立你的团队，让每个人都承担新的责任，互相了解等等。试图同时进入太多的方向是走向失败的方向。
因此，确定您想要开发的技术。由于您的示例中的主要目标是内部开发，因此内部需求将决定您的决定。 牢记这一主要目标来组建您的团队。
对于内部开发，您至少需要两个已经了解公司及其流程的人员。 （两个，因为当第一次重大危机袭击你时，一个人肯定会生病或正在度假）。 另一方面，你需要一些局外人，他们不会被“我们一直这样做”的心态所束缚，能够跳出框框思考。 出于上述原因，这些人也应该至少是两个人。 作为团队领导者，你的工作就是平衡这两个群体并将他们整合成一个团队。
对于未来的增长，始终考虑有机增长。
不要将团队规模增加 200%，在这里雇佣一个新人，在那里雇佣另一个人（或女孩）。 慢慢建立你的团队。
当您承担新项目时，请始终考虑扩展团队的专业知识。 每个项目都尝试一些新的东西。 这可以是一个新的源存储库、一个自动化的日常构建过程、一个编写规范或文档的新系统，甚至是一种不同的技术（例如，当您通常使用 .Net、Delphi 或 C++ 进行开发时，使用 Java）。 只要确保您永远不会尝试在重要项目中取得重大飞跃。 （我曾经在一家公司工作过，该公司决定从 VB 6.0 转向 .Net，以完成他们以前尝试过的最大项目。他们幸存下来。勉强生存。）
这样，您的部门将缓慢但不断地扩展其能力。 然后，当有机会为外部客户进行开发时，您将已经积累了实现这一目标所需的大部分知识。
哦，是的，smacl 也是对的：如果您希望您的部门长期生存，您需要可靠的 QA/QM。
从第一天起就开始制定（并遵循）您的质量检查规则。 使它们尽可能短且灵活。 添加您发现缺少的内容，并丢弃那些被证明是不必要或不切实际的内容。
不确定这是你想知道的，但我觉得有必要说出来;-)
I agree with Guillaume: If you want to build a department from scratch, you need to focus. You need to build your team, have everybody grow into their new responsibilities, get to know each other etc. Trying to go into too many directions at once is the direction towards failure.
So, identify the technology you want to develop in. Since the primary goal in your example is in-house development, the in-house requirements will determine your decision. Build your team with that primary goal in mind.
For in-house development, you need at least two people who already know the company and its processes. (Two because one will definitely be ill or on holidays when the first major crisis hits you). On the other hand you need some outsiders, who are not entrenched by the "we have always done it like this" mindset, who can think out of the box. Those should also be at least two people, for the reason stated above. Your job as the team leader is to balance those two groups and integrate them into a team.
For future growth, always think in terms of organic growth.
Do not increase the team size by 200 %, hire one new guy here and another guy (or gal) there. Slowly build your team.
When you take on a new project, always think of expanding your teams expertise. Try something new with every project. That can be a new source repository, an automated daily build process, a new system to write specifications or documentation, or even a different technology (for example Java when you usually develop in .Net, Delphi or C++). Just make certain you never try to make a big leap in an important project. (I once worked for a company who decided to switch from VB 6.0 to .Net for the biggest project they had ever attempted before. They survived. Barely.)
That way your department will slowly but constantly expand its capabilities. Then when the opportunity presents itself to do development for an external customer, you will already have accumulated most of the knowledge you need in order to pull it off.
Oh yes, and smacl is right, too: You need solid QA/QM if you want your department to survive long term.
Start laying out (and follwing) your QA rules from day one. Keep them as short and flexible as possible. Add what you discover to be missing, and throw out what proves to be unnecessary or impractical.
Not sure this is what you wanted to know, but I felt the need to say it ;-)
制定强大的质量保证策略，包括验收标准和变更控制。 最好保持轻量级以适应内部客户。 另外了解如何进行需求分析、期望管理和资源管理。
换句话说，不要随心所欲地创建蹩脚的解决方案，浪费的时间多于节省的时间，而且无法维护。 花点时间思考你想要什么和需要什么，如何实现它，以及它会花费多少。
Develop a strong QA strategy, including acceptance criteria and change control. Preferably keeping it lightweight to suit internal clients. In addition understand how to carry out requirements analysis, expectation management, and resource management.
Put another way, don't just wing it to create crappy solutions that waste more time than they save and are impossible to maintain. Take time to think about what you want and need, how you can achieve it, and what it is going to cost.
除了之前关于团队、版本控制、质量保证等方面的答案之外，我将提供一个更具体地关注编码和开发人员/架构师角色的答案，这些当然都很重要。
您的许多决定很大程度上取决于您的特定业务和软件结构（单一产品代码库、SOA、许多项目等），但一般来说，您应该始终花费大量时间预先开发核心软件基础设施，这将在开发过程中带来巨大的红利。 SDLC。
软件基础设施
编码命名约定例外
处理策略日志记录
策略设置和配置
基类和辅助类
通用体系结构和层
（演示、外观、域
实体、数据存储等）
设计工具，例如 UML 2.0
需求
管理/最终用户交互
还有很多，但这些肯定是需要考虑的一些基础知识。 我参与过的所有成功项目都包含了良好的软件基础设施。 我还要指出，许多失败的项目都有一个共同的主题……缺乏通用的基础设施。 在大多数情况下，这些失败的项目是由非技术人员领导的，他们认为他们可以简单地向一些程序员提出一堆想法，并期望他们在几周内交付。
最重要的是，您需要投入一些前期规划和原型设计，以确保长期成功！
祝你好运。
雷福德
www.blacksaber.com
I will offer an answer more focused specifically on coding and the developers / architects role in addition to the previous answers on teams, version control, qa etc. which are of course all important.
Many of your decision is very dependant on your specific business and software structure (a single product code base, SOA, many projects etc.) But in general you should always spend significant time up front developing Core Software Infrastrcuture that will pay huge dividends during the SDLC.
Software infrastruture
Coding Naming Conventions Exception
Handling strategies Logging
Strategies Settings and Configuration
Base classes and Helper Classes
General Architecture and Layers
(Presentation, Facade, Domain
Entities, Data Stores etc.)
Design Tools such as UML 2.0
Requirements
Management / End user interaction
There are tons more, but these are certainly some basics to think about. All of the successful projects I have been involved with incorporated decent software infrastructure. I will also note that many of the project that fail have a common theme... lack of a common infrastructure in place. In most cases these failed projects are lead by a non-technical person that think they can simply throw a bunch of ideas at a few programmers and expect them to deliver in a few weeks.
Bottom line, you need to invest some up front planning and prototyping to ensure success in the long term!
Good luck.
Raiford
www.blacksaber.com
负责人知道自己在做什么。
Someone in charge who knows what they're doing.
我认为拥有合适的人是最重要的。 如果你的程序员很糟糕，其他一切都不重要了。
I think having the right people is going to be the most important. Nothing else will matter if your programmers stink.
让自己以至少 10 分的成绩通过 Joel 测试。
Set yourself up to pass the Joel Test with at least a score of 10.