软件工程团队队名_对工程团队的设计压力？
软件工程团队队名
您支持或开发了多少次系统，并且认为它可以设计得更好？
快速行动并打破软件中的事物文化，使工程团队可以将产品提前推向市场，但创造了巨大的潜力
团队努力克服的技术债务问题。
工程团队承受着功能压力 ，无法完成工作，而其他重要的事情则保留下来。
系统中的重要内容被列为“非功能性”要求，但实际上，这些是系统长期运行所必须具备的要求。
在像土木工程这样的实际工程项目中，人们受过训练去思考
- 使用什么材料？
- 它可以容纳多少人？
- 何时必须进行维护？
- 紧急出口在哪里？
- 紧急情况下如何疏散？
但是，构建许多软件系统时并未考虑基本的操作或支持要求。
使用机器学习 ， 深度学习 ，最新的Java脚本，最新的NO-SQL或流处理 ， 区块链等软件开发已成为趋势或简历驱动。
如果没有事先考虑，这些尖端技术将无法满足基本工程需求。
作为软件工程师，我们必须首先考虑设计压力。 这些设计压力是什么？
- 服务如何执行？
- 它可以承受什么负载？
- 是否可以在开发人员笔记本电脑上运行它？
- 可以调试吗？
- 如何使用耦合或使用内聚 ？
- 它支持自动打包或部署吗？
- 它是可测试的还是可维护的？
- 单一责任还是多重责任？
- 关注点分离 ？
- 你能从外面观察系统吗？
- 系统是否具有管道或扼流圈体系结构
- 什么是系统依赖关系或需要整个世界
- 它捕获指标还是您必须做出猜测。
- 它适合您的HEAD还是您需要大头或多个HEAD
这些都是非常困难的事情，以后再添加也很昂贵。
我们之所以不首先看这些事情，是因为“我们感到无聊”或“我们喜欢复杂”或“我们想复制google或facebook所做的事情”。 并非每个公司都有Google或Facebook所面临的问题，因此我们在选择大型互联网公司使用的工具/技术时应格外小心。 我想以软件系统的“两个价值的故事”结尾。
行为
雇用软件开发人员来构建新功能，并且利益相关者密切合作以实现此目标。 这是软件的“重要”部分。
建筑
如果正确完成此部分，则软件将保持“软”状态，否则将变成泥潭 。 这是“如何”的部分，工程师必须承担所有责任。 系统的价值既重要又紧迫，但是更多地将重点放在行为上，因为一旦项目开始，它就变得紧急。
如果我们忽略“设计压力”，那么系统的开发成本将会很高，并且无法进行更改。 让我知道您在设计压力方面的经验。
翻译自: https://www.javacodegeeks.com/2018/05/design-pressure-on-engineering-team.html
软件工程团队队名