开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 1 天，点击查看活动详情
这是第二次参加掘金的活动了，参加活动获得奖品是次要的，重要的是我希望可以用这种方式让自己能够坚持去记录一件事情，正好最近在看Clean architecture这篇文章，所以我就想把自己一些理解和体会写在这里。
今天看的篇章讲的是一个软件的系统行为和系统架构到底哪一个更重要。 如果让大家回答，大家肯定会说都很重要，但是如果当一个任务分配给你，但是你会不知不觉的偏向行为，这里的行为指的是什么呢？这里的行为指的是系统的行为，系统正确的行为，系统可以工作的行为。我们为什么要做任务是为了让它工作，在某一些程度上来讲，只有让一个软件工作了，这个才是你的成果，更多的时候老板刚开始不会想你的软件设计有多好，而是看你的功能能不能工作。同样的公司给客户去演示也只是看功能是否正常，而不是看你的软件架构是什么样子。所以整个开发过程中其实都会导向以系统行为优先。
按照书上的说法，如果把事情分为两个维度，重不重要，紧不紧急，我们可以有下面的组合：
- Urgent and important 重要且紧急
- Not ungent and important 重要不紧急
- Urgent and not important 不重要但紧急
- Not urgent and not important 不重要且不紧急
系统行为可以认为是紧急的事情，系统设计可以认为是重要的事情。 所以对于这两个维度应该在什么时候优先，这是研发团队和其他部门经常争执的问题。但是我认为如果你对一个功能有足够的把握做好，并且是你属性的领域，那么我认为，刚开始就去把架构设计好，会是一个明智的选择。但是如果一个功能你从来没有涉足过，也不知道该从何开始，那么这个时候实现功能0的突破是重要的，当你的功能实现了0的突破那么这个时候一定要想想设计的事情了。如果忽视设计的价值，那么系统将会变的越来越难维护。
最后作者也说了一句话，我希望大家可以记住：如果系统变成了难以维护的样子，那么说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的责任。
所以说抗争还是要有的，为了我们的软件能更好的维护！
