郁闷的架构师 (The Frustrated Architect)

在软件成功交付的过程中,软件架构师起着控制方向的作用,然而很多团队却忽视了这一点,这很令人郁闷。不管是一个人承担,还是团队中多个人共享,不管是在敏捷实施最彻底的团队中,还是要做大量前期设计的团队,架构师角色总是不可或缺,而且他们的演化式思维方式常常能够激发灵感,而不仅仅是对现实的关照。真正的成功,光靠对新东西的着迷是不够的,还需要开始提出各种问题。敏捷需要架构师么?架构师又是不是需要敏捷?这几年来,对于好的软件设计,我们是不是忘掉的比学到的还要躲?浮现式设计真的就是坐在那里盼着最好的事情出现么?如果我们明天真的不再培养架构师了,我们说的这些又有何意义?我们如何不再郁闷,走向宁静?

The IT industry is either taking giant leaps ahead or it's in deep turmoil. On the one hand we're pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other though, we're continually forgetting the good of the past and software teams are still failing on an alarmingly regular basis.

Software architecture plays a pivotal role in the delivery of successful software yet it's frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.

If we really do want to succeed, we need to get over our fascination with shiny new things and starting asking some questions. Does agile need architecture or does architecture actually need agile? Have we forgotten more about good software design than we've learnt in recent years? Does any of this matter if we're not fostering the software architects of tomorrow? How do we move from frustration to serenity?

Other formats

PDF


    of 100