对工程团队的设计压力？

您支持或开发了多少次系统，并认为它本可以设计得更好？

快速行动并打破软件中的事物文化，使工程团队可以将产品提前推向市场，但创造了巨大的潜力
团队努力克服的技术债务问题。

工程团队承受着功能压力 ，无法完成工作，而其他重要事情则保留得很好。

系统中的重要内容被列为“非功能性”要求，但实际上，这些是系统长期运行所必须具备的要求。

在像土木工程这样的实际工程项目中，人们受过训练去思考

• 使用什么材料？
• 它可以容纳多少人？
• 何时必须进行维护？
• 紧急出口在哪里？
• 紧急情况下如何疏散？

但是，许多软件系统是在没有考虑基本操作或支持要求的情况下构建的。

使用机器学习 ， 深度学习 ，最新的Java脚本，最新的NO-SQL或流处理 ， 区块链等软件开发已成为趋势或简历驱动。

如果没有事先考虑，这些尖端技术将无法满足基本工程需求。

作为软件工程师，我们必须首先考虑设计压力。 这些设计压力是什么？

• 服务如何执行？
• 它可以承受什么负载？
• 是否可以在开发人员笔记本电脑上运行它？
• 可以调试吗？
• 如何使用耦合或使用内聚 ？
• 它支持自动打包或部署吗？
• 它是可测试的还是可维护的？
• 单一责任还是多重责任？
• 关注点分离 ？
• 你能从外面观察系统吗？
• 系统是否具有管道或扼流圈体系结构
• 什么是系统依赖性或它需要整个世界
• 它捕获指标还是您必须做出猜测。
• 它适合您的HEAD还是您需要BIG头或多个HEAD

这些都是非常困难的事情，以后再添加也很昂贵。

我们之所以不首先看这些事情，是因为“我们感到无聊”或“我们喜欢复杂”或“我们想复制google或facebook所做的事情”。 并非每个公司都有Google或Facebook所面临的问题，因此我们在选择大型互联网公司使用的工具/技术时应格外小心。 我想以软件系统的“两个价值的故事”结尾。

行为

雇用软件开发人员来构建新功能，并且利益相关者密切合作以实现此目标。 这是软件的“重要”部分。

建筑

如果正确完成此部分，则软件将保持“软”状态，否则将变成泥潭 。 这是“如何”的部分，工程师必须承担所有责任。 系统的价值既重要又紧迫，但是更多地将重点放在行为上，因为一旦项目开始，它就变得紧急。

如果我们忽略“设计压力”，那么系统的开发成本将变得很高，并且无法进行更改。 让我知道您在设计压力方面的经验。

翻译自: https://www.javacodegeeks.com/2018/05/design-pressure-on-engineering-team.html