《97 Things Every Software Architect Should Know》读书笔记
(从网上搜集的,并且整理为DOC文档,希望大家可以从这篇文章中学到更多的东西,
我准备将该文档翻译成中文,大家可以不定期的访问我的博客http://blog.csdn.net/jianglike18)
1、Don't put your resume(n. 履历) ahead of therequirements
As engineers we sometimes recommend(v.推荐) technologies, methodologies(方法论) and approaches for solving problemsbecause we want to have these on our resume and not because they are the bestsolution for the problem. Such decisions very rarely result in(v.导致)happy outcomes(n.结果).
The best thing for your career(n.职业) is a longstring of(一长串的) happy customers eager(adj.热心于) to recommend you because you didthe right thing by(对, 例如He did well by me.
他待我好) them and for the project.This goodwill (n.友好关系) will serve(帮助)you orders of magnitude(若干数量级) better than the latest shiny(闪耀的) object in the latestshiny language or the latest shiny paradigm. While (adj.虽然) it is important, evencritical, to stay abreast(并肩地) of the latest trends (n.趋势) and technologies thisshould never happen at the cost of (adv.以...为代价) the customer. It’simportant to remember that you have a fiduciary(adj.基于信用的) duty. As an architectyou have been entrusted with(v.委托) the well-being(n.安宁)of your organization and itsexpected that you will avoid all conflicts of interest(n.利害) and give the organization your undivided(adj.专一的) loyalty(n.忠诚). If the project isn't cutting edge(n.刀刃) or challenging enoughfor your current career needs then find one that is.
If you can't do that and you are forced to be in such a project, then you andeveryone else will be happier using the right technology for the customerrather than for your resume. It is often difficult to resist(vt.抵抗) utilizing a solution that is newand cool, even when it is inappropriate for the current situation.
With the right solution, the project will have a happier team, a happiercustomer and overall far less stress. This will often give you time to go deeper into(v.探究) the existing oldertechnology or to learn the new stuff(n.东西) on your own time. Or togo take that painting class(油画课) you always wanted to do.Your family will love you for it, too - they'll notice the difference when you get home(v.回到家里).
Overall(全面的) always put the customer's long-term(adj.长期的) needs ahead of your own short-term(adj.短期的) needs and you won't go wrong(v.走错路, 误入歧途, (机器等)发生故障).
注:架构师不能置客户的利益于不顾而去沉迷于那些酷酷的技术。
By Nitin Borwankar
This work is licensed under a Creative CommonsAttribution 3
2、Simplify(v.简化) essential(adj.根本的) complexity; Diminish(v.减少)accidental(adj.附属的) complexity
Essential complexity represents the difficulty inherent(adj.固有的) in any problem. For example, coordinating anation’s air traffic is an inherently complex problem. Every plane’s exactposition (including altitude), speed, direction and destination must be trackedin real time to prevent mid(mid smoke and flame.在烟火之中) air and runway(n.飞机跑道) collisions. The flight(n.航班) schedules(n.时间表) of aircraft(n.飞机) must be managed to avoid airport congestion(n.拥塞) in a continuously changing environment – a sever change in weather throws the entire schedule outof whack(n.紊乱).
Conversely(n.相反地), accidental complexity grows from(由……发展起来) the things we feel we must build to mitigate(v.减轻)essential complexity. The antiquated(adj.陈旧的) air traffic control system used today is anexample of accidental complexity. It was designed to address the essentialcomplexity of controlling the traffic of thousands of airplanes, but thesolution itself introduces its own complexity. In fact, the air traffic controlsystem used today is so complex that updating it has proven to be difficult ifnot impossible. In much of the world air traffic is guided by technology thatis more than 30 years old.
Many frameworks and vendor(n.卖方) "solutions" are the symptoms ofthe accidental complexity disease. Frameworks that solve specific problems areuseful. Over-engineered frameworks add more complexity than they relieve.
Developers are drawn to(v.使…接近)complexity like moths(n.蛾) to flame(n.火焰), frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn't like the rush of solving some incredibly(adv.不能相信地) complex problem? In large-scale software, though(adv.可是) removingaccidental complexity while retaining(v.保留) the solution to the essential complexity ischallenging.
How do you do this? Prefer frameworks derived from working code rather thanones cast down from ivory(n.象牙) towers. Look at the percentage of code youhave in a solution that directly addresses the business problem vs. code that merely (adv.仅仅)services the boundary between the application and the users. Cast a wary(adj.机警的)eye on vendor driven solutions. They may not be inherently bad, but vendorsoften push accidental complexity. Make sure that the solution fits the problem.
It’s the duty of the architect to solve the problems inherent in essentialcomplexity without introducing accidental complexity.
By Neal Ford
This work islicensed under a Creative Commons Attribution 3
(wc 342)
3、Chances(n.机会) are your biggest problem isn't technical
Right now someone's running afailing project to build a payroll(n.工资单) system. Probably more than one someone.
Why? Was it because they chose Rubyover Java, or Python over Smalltalk? Or because they decided to use Postgresrather than Oracle? Or did they choose Windows when they should have chosenLinux? We've all seen the technology take the fall for failed projects. Butwhat are the chances that the problem was really so difficult to solve that Javawasn't up the task?
Most projects are built by people,and those people are the foundation(n.基础) for success and failure. So, it pays(v.值得) to think about(v.考虑) what it takes to(v.求助于) help make those peoplesuccessful.
Equally, there's a good chance thatthere's someone who you think is "just not doing it right" and is undermining(v.破坏) the project. In thesecases, the technology you need to solve your problem is very old and wellestablished indeed, in fact it's possibly the most importanttechnical innovation in the history of humanity. What you need is aconversation.
Mere(adj.仅仅的) familiarity(n.精通) with the conversation as(conj.像)a technology isn't enough. Learning to treat(v.对待) people with respect(n.尊敬), and learning give them thebenefit of the doubt(在没有相反的证据以前暂时相信他的话), is one of the coreskills that turn a smartarchitectinto one an effectivearchitect.
There's lots more to it than this,but a couple small tips can significantly increase yourconversational effectiveness:
1) Approach these events asconversations -- not asconfrontations.
If you assume the best about peopleand treat this as a way to ask questions you definitely learn more, and you areless likely to put people on the defensive.
2) Approach these conversations onlyafter you've got your attitude right.
If you're angry, frustrated,annoyed, or otherwise flustered its very likely that the other person will interpret(v.认为是...的意思) you non-verbals asindicating that you're on the attack.
3) Use these as opportunities to setmutually agreed upon goals.
Instead of telling a developer thatthey need to be quiet in meetings because they never let anybody speak, ask ifthey can help you increase other people's participation. Explain that somepeople are more introverted(adj.内向的) and need longer silences before they jump into aconversation, and ask if they will help you out by waiting 5 seconds beforejumping in.
If you start with a shared purpose,treat people "problems" as an opportunity to learn, and manage yourown emotions(n.情绪), you'll not only becomemore effective, you'll also discover that you learn something every time.
By MarkRamm
This work is licensed under a Creative Commons Attribution3
4、Communication is King; Clarity(n.清楚) and Leadership(n.领导能力) its humble(恭顺的) servants(n.仆人)
All too often(n.时常)software architects sitin their ivory towers, dictating(v.规定) specifications, technology decisions, and technologydirection to the developers below. More often than not(n.时常) this leads to(v.导致) dissension in the ranks,quickly followed by a revolt by the masses, finally resulting in a softwareproduct that doesn't even come close to resembling the original requirements.Every software architect should know how to communicate the goals andobjectives of a software project. The key to effective communication is clarityand leadership.
Clarity describes how you communicate. No one on your team is going to read a100 page architecture decisions document. Being clear and concise(adj.简明的) in the way youcommunicate your ideas is vital(adj.至关重要的) to the success of any software project. Keep thingsas simple as possible at the start of a project, and by all means(adv.尽一切办法) do not start writinglengthy Word documents. Use tools like Visio to create simple diagrams to convey(v.传达) your thoughts. Keep themsimple, for(conj.因为) they will almostcertainly be changing frequently. Another effective means of communication isinformal whiteboard meetings. Nothing gets your ideas across better thanbringing in a group of developers (or other architects) into a room andwhiteboarding your ideas. Also, be sure to always have a digital camera withyou at all times. Nothing is more frustrating than being pushed out of ameeting room with all of your ideas stuck on a white board. Snap a picture,download it, and share it via a wiki to the rest of the team. So throw away thelengthy Word documents and focus more on getting your ideas across, andafterwards worry about recording the details of your architectural decisions.
One thing most software architects fail to realize is that a software architectis also a leader. As a leader, you must gain the respect of your co-workers(n.同事) to work effectively in ahealthy and effective environment. Keeping developers in the dark about the bigpicture or why decisions were made is a clear recipe(n.处方) for disaster. Having thedeveloper on your side creates a collaborative environment whereby(adv.凭什么) decisions you make as anarchitect are validated. In turn, you get buy-in from developers by keepingthem involved in the architecture process. Work with developers, not againstthem. Keep in mind that all team members (e.g. QA team, BusinessAnalysis, and Project Managers as well as developers) require clear communicationand leadership. Employing(v.使用) clarity and effectiveleadership will improve communication and create a strong and healthy workenvironment.
If “Communication is King” thenclarity and leadership are its humble servants.
By Mark Richards
This work is licensed under a Creative CommonsAttribution 3
(wc 434)
5、Architecting is about balancing
Balance(v.平衡) stakeholders'(n.股东) interests(n.利益) with technical requirements.
When we think of architectingsoftware, we tend to(v.趋向) think first of(v.考虑) classical(adj.传统的) technical activities(n.行为), like modularizingsystems, defining interfaces, allocating responsibility, applying patterns, andoptimizing performance. Architects also need to consider security,usability, supportability, release management, and deployment options, amongothers things. But these technical and procedural(adj.程序上的) issues must be balancedwith the needs of stakeholders and their interests. Taking(v.采取) a “stakeholders andinterests” approach(n.步骤) in requirements analysisis an excellent way to ensure completeness(n.完备性) of requirements specifications for the software beingdeveloped.
Analyzing the stakeholders, and their interests, in the process by which anorganization develops software, and in the organization itself, reveals(v.揭示) the ultimate(adj.最终的) set of priorities bearing on(v.有关) a software architect.Software architecting is about balancing this set of priorities, over the shortand long term, in a way that is appropriate to the context at hand.
Consider, for example, the engineering department of a software-as-a-servicebusiness. The business likely has certain priorities(n.优先考虑的事), such as meeting contractual(adj.契约的) obligations(n.义务), generating revenue,ensuring customer referenceability, containing costs, and creating valuabletechnology assets(n.资产). These businesspriorities may translate to departmental(adj.部分的) priorities like ensuring the functionality andcorrectness, and “quality attributes” (i.e. “-ilities”) of the software beingdeveloped, as well as ensuring the productivity of the development team,ensuring the sustainability and auditability of development operations, and theadaptability(n.适应性) and longevity(n.寿命) of the softwareproducts.
It is the architect’s job to not only create functional, quality(n.优质) software for users, butalso to do so while balancing the other departmental priorities, with the costcontainment interests of the business’s CEO, with the ease-of-administrationinterests of the operations staff, with the ease-of-learning andease-of-maintenance interests of future programming staff, and with bestpractices of the software architect’s profession.
The architect may choose to consciously(adv.有意识地) tilt(v.(使)倾斜) the balance in favor of(adv.赞同) one priority in theshort term, but had better(adv.最好) maintain a proper balance over the long term in order totruly do the job well. And the balance that is struck needs to be appropriateto the context at hand, considering factors such as the expected lifespan(n.寿命) of the software, the criticality(n.临界点) of the software to thebusiness, and the technological and financial culture of the organization.
Insummary(综上), software architectingis about more than just the classical technical activities; It is aboutbalancing technical requirements with the business requirements of stakeholdersin the project.
By Randy Stafford
This work is licensed under a Creative CommonsAttribution 3
(wc 391)
6、Seek the value in requested capabilities
Often customers and end-users state(v.宣称) what they think is a viable(adj.可行的) solution to a problem asa requirement. The classical story on this was told by Harry Hillaker, the leaddesigner of the F-16 Falcon(n.猎鹰). His team was requestedto design a Mach 2 - 2.5 aircraft, which was then, and probably still is, a non-trivial(adj.重要的) task – especially whenthe objective is to create "cheap" lightweight aircraft. Rememberthat the force required to overcome drag(n.阻力) quadruples(n.四倍) when doubling(v.使加倍) the speed, and what impact that have on aircraft weight.
When the design team asked the air force why they needed Mach 2 - 2.5, theanswer was to be able to escape from combat(n.格斗). With the real need on the table the design team was ableto address the root problem and provide a working solution. Their solution wasan agile aircraft with a high thrust-to-weight ratio, providing accelerationand maneuverability(n.机动性), not maximum speed.
This lesson should be brought into software development as well. By asking forthe value to be provided by a requested feature or requirement architects areable address the real problem, and hopefully provide a better and cheapersolution compared to addressing the solution suggested by the client. The focuson value also simplifies prioritization. The most valuable requirements becomethe driving(adj.强烈的) requirements.
So, how to proceed then? In many ways the required approach is found in theagile manifesto(n.宣言): "Collaboration(n.协作) over(v.优先于) contract".Practically speaking this implies arranging workshops(n.讨论会) and meetings where thearchitects focus are on customer needs, helping the customers to answer the"why" question. Be aware that answering the "why" questioncan be difficult because we very often talk about tacit(adj.隐含的) knowledge. Discussionson how to provide a technical solution should be avoided in these workshops,because they move the discussions away from the customer’s domain and into thedomain of software development.
By Einar Landre
This work is licensed under a Creative CommonsAttribution 3
(wc 309)
7、Stand Up!
As architects, many of us have grownfrom highly technical positions where our success was derived mainly from ourability to talk to machines. However, in the role of architect much of ourcommunication is now done with our fellow human beings. Whether it's talking todevelopers about the benefits of employing a specific pattern, or explaining tomanagement the cost-benefit(adj.成本效益的) tradeoffs(n.n.权衡) of buying middleware, communication is core to oursuccess.
Although it's difficult to measure an architect's impact on a project, ifdevelopers consistently ignore their guidance(n.指导) and management doesn't buy-in(v.买账) to theirrecommendations, the "rightness(n.正确性)" of their guidance will do little toadvance their career. Experienced architects understand that they need to"sell" their ideas and need to communicate effectively in order to dothat.
Many books have been written on the topic of inter-personal(adj.人与人之间的) communication, but Iwanted to call out one simple, practical, easy-to-employ tip that willdrastically increase the effectiveness of your communication, and,consequently, your success as an architect. If you’re in any situationwhere you’re talking to more than one person about your guidance, standup. Whether it’s a formal design review or an informal discussion oversome diagrams, it doesn’t matter. Stand up, especially if everyone else issitting down.
Standing up automatically communicates authority(n.威信) and self-confidence. Youcommand the room. People will interrupt you less. All that is going to make abig difference to whether or not(n.无论是否) your recommendations will be adopted.
You’ll also notice that once you stand, you’ll start making more use of yourhands and other body language. When speaking to groups of 10 or more people,standing up will also help you can make eye contact with everybody. Eyecontact, body language, and other visual elements account for(v.占) a large portion ofcommunication. Standing up also tends to change your tone of voice, volume, pitch(n.音调), and speed: projecting(v.使突出) your voice to largerrooms; slowing down(v.(使)慢下来) to make more importantpoints. These vocal elements contribute substantially(adv.充分地) to the effectiveness ofcommunication.
The easiest way to more than double your effectiveness when communicating ideasis quite simply to stand up.
By Udi Dahan
This work is licensed under a Creative CommonsAttribution 3
(wc 352)
8、Skyscrapers(n.摩天楼) aren't scalable
We often hear software engineering compared to(比喻为) building skyscrapers, dams(n.水坝), or roads. It's true insome important aspects(n.方面).
The hardest part of civilengineering(土木工程学) isn't designing abuilding that will stand up once(conj.一旦) it is finished, but figuring out the construction process.The construction process has to go from a bare(adj.空的) site to a finishedbuilding. In the interim(在这期间), every worker must beable to apply his trade, and the unfinished structure has to stand up the wholetime. We can take a lesson from that when it comes to deploying largeintegrated systems. ("Integrated" includes virtually every enterpriseand web application!) Traditional "big bang" deployments are like stacking up(v.加起来) a pile of beams andgirders, throwing them into the air, and expecting them to stick together inthe shape of a building.
Instead, we should plan to deployone component at a time. Whether this is a replacement or a greenfield project, this has two largebenefits.
First, when we deploy software, weare exposing ourselves to the accumulated technical risk embodied in the code.By deploying one component at a time, we spread technical risk out over alonger period of time. Every component has its own chance to fail inproduction, letting us harden each one independently.
The second large benefit is that itforces us to create well-defined interfaces between components. Deploying asingle component of a new system often means reverse-integrating it with theold system. Therefore, by the time deployment is complete, each component hasworked with two different systems: the original and the replacement. Nothing isreusable until it has been reused, so piecewise deployment automatically meansgreater reusability. In practice, it also leads to better coherence and loosercoupling.
Conversely, there are some importantways that civil engineering analogies mislead us. In particular, theconcreteness of the real world pushes us toward a waterfall process. After all,nobody starts building a skyscraper without knowing where it's going or howtall it should be. Adding additional floors to an existing building is costly,disruptive and risky, so we strive to avoid it. Once designed, the skyscraperisn't supposed to change its location or height. Skyscrapers aren't scalable.
We cannot easily add lanes to roads,but we've learned how to easily add features to software. This isn't a defectof our software processes, but a virtue of the medium in which we work. It's OKto release an application that only does a few things, as long as users valuethose things enough to pay for them. In fact, the earlier you release yourapplication, the greater the net present value of the whole thing will be.
"Early release" may appearto compete with "incremental deployment", but they can actually worktogether quite well. Early release of individual components means that each onecan iterate independently. In fact, it will force you to work out thorny issueslike continuous availability during deployments and protocol versioning.
It's rare to find a technique thatsimultaneously provides higher commercial value and better architecturalqualities, but early deployment of individual components offers both.
By Michael Nygard
This work is licensed under a Creative CommonsAttribution 3
9、You're negotiating more often than you think.
We've all been hit withbudgetecture. That's when sound technology choices go out the window in favorof cost-cutting. The conversation goes something like this.
"Do we really need X?"asks the project sponsor (n.发起人).
For "X", you cansubstitute nearly anything that's vitally(n.极其) necessary to make the system run: software licenses,redundant servers, offsite backups, or power supplies. It's always asked with a sort of(一种) paternalistic(adj.家长式统治的) tone, as though(好像) the grown-up(n.成年人) has caught us blowing(乱花钱) all our pocket money on comic(adj.喜剧的) books and bubble gum(n.泡泡糖), whilst(n.同时) the serious adults aretrying to get on with(继续做) buying more buckets tocarry their profits around in.
The correct way to answer this is"Yes. We do." That's almost never the response.
After all, we're trained asengineers, and engineering(n.工程) is all about making trade-offs(n.平衡). We know good and well that youdon't really need extravagances(n.浪费) like power supplies, so long as there's a sufficientsupply of hamster wheels and cheap interns in the data center. So instead ofsaying, "Yes. We do," we say something like, "Well, you could dowithout a second server, provided you're willing to accept downtime for routinemaintenance and whenever a parity bit flips, causing a crash, but if we geterror-checking parity memory then we get around that, so we just have to worryabout the operating system crashing, which it does about every three-point-ninedays, so we'll have to do nightly restart. The interns can do that wheneverthey get a break from the power-generating hamster wheels."
All of which might be completelytrue, but is utterly the wrong thing to say. The sponsor stopped listeningright after the word "well."
The problem is that you see yourpart as an engineering role, while your sponsor clearly understands he'sengaged in a negotiation. We're looking for a collaborativesolution-finding exercise; they're looking for a win-lose tactical maneuver.And in a negotiation, the last thing you want to do is make concessions(n.让步) on the first demand. Infact, the right response to the "do we really need" question issomething like this:
"Without a second server, thewhole system will come crashing down at least three times daily, particularlywhen it's under heaviest load or when you are doing a demo for the Board ofDirectors. In fact, we really need four servers so we can take one HA pair downindependently at any time while still maintaining 100% of our capacity, even incase one of the remaining pair crashes unexpectedly."
Of course, we both know you don'treally need the third and fourth servers. This is a counter-negotiating gambitto get the sponsor to change the subject to something else. You're upping the ante(n.赌注) and showing that you're alreadyrunning at the bare, dangerous, nearly-irresponsible minimum tolerableconfiguration. And besides, if you do actually get the extra servers, you cancertainly use one to make your QA environment match production, and the otherwill make a great build box.
By Michael Nygard
This work is licensed under a Creative CommonsAttribution 3
10、Quantify
"Fast" is not arequirement. Neither is "responsive". Nor "extensible". Theworst reason why not is that you have no objective way to tell if they're met.But still users want them. The architect's role is largely to help the systemhave these qualities. And to balance the inevitable conflicts andinconsistencies between them. Without objective criteria architects are at themercy of capricious users ("no, I won't accept it, still not fastenough") and of obsessive programmers ("no, I won't release it, stillnot fast enough").
As with all requirements we seek towrite down these desires. Too often then the vague adjectives come out:"flexible", "maintainable" and the rest. It turns out thatin every case (yes even "usable", with effort) these phenomena can bequantified and thresholds set. If this is not done then there is no basis foracceptance of the system by its users, valuable guidance is stolen from itsbuilders as they work, and the vision is blurred for those architecting it.
Some simple questions to ask: Howmany? In what period? How often? How soon? Increasing or decreasing? At whatrate? If these questions cannot be answered then the need is not understood.The answers should be in the business case for the system and if they are not, thensome hard thinking needs to be done. If you work as an architect and thebusiness hasn't (or won't) tell you these numbers ask yourself why not. Then goget them. The next time someone tells you that a system needs to be"scalable" ask them where new users are going to come from and why.Ask how many and by when? Reject "Lots" and "soon" asanswers.
Uncertain quantitative criteria mustbe given as a range: the least , the nominal, and the most. If this rangecannot be given, then the required behavior is not understood. As anarchitecture unfolds it can be checked against these criteria to see if it is(still) in tolerance. As the performance against some criteria drifts overtime, valuable feedback is obtained. Finding these ranges and checking againstthem is a time-consuming and expensive business. If no one cares enough aboutthe system being "performant" (neither a requirement nor a word) topay for performance trials, then more than likely performance doesn't matter.You are then free to focus your architectural efforts on aspects of the systemthat are worth paying for.
"Must respond to user input inno more than 1500 milliseconds. Under normal load (defined as...) the averageresponse time must be between 750 and 1250 milliseconds. Response times lessthan 500 milliseconds can't be distinguished by the user, so we won't pay to gobelow that." Now that's a requirement.
By Keith Braithwaite
This work is licensed under a Creative CommonsAttribution 3
11、One line of working code is worth(相当...价值) 500 of specification(说明书)(一行可以工作的代码相当于500页规格说明书的价值)
Design is a beautiful thing. A systematic(系统的), detailed presentation(陈述) and review of a problem space andsolution reveals(揭示) errors and opportunitiesfor improvement, sometimes in a startlingly(令人吃惊地) dramatic(生动的) way. The specificationsare important because they provide the pattern for building. Taking the time tothink through the architecture is important, both on a macro level with an eyefor interactions between components and on a micro level with an eye forbehavior within a component.
Unfortunately it's far too easy toget wrapped up in(酷爱) the process of design, enthralled(迷惑) by architecture in abstract. Thefact is that specifications alone have no value. The ultimate goal of asoftware project is a production system. A software architect must always keep an eyeon(密切注视) this goal, and remember that designis merely a means to an end, not an end in itself. An architect for a skyscraper(摩天楼) who ignored the laws of physics tomake the building more beautiful would soon regret(为...感到遗憾) it. Losing sight of(忽略) the goal of working code spells(意味着) serious trouble for any project.
Value the team members who work on(继续工作) implementing your vision(想象力). Listen to them. When they haveproblems with the design, there's a good chance(有很大的可能性) they're right and the design is wrong, or at least unclear. It's your job, in these cases, to modify the design to meet real-worldconstraints by working with(与...合作) your team members to determine whatworks and what does not. No design is perfect from the start; all designs needto be modified as they are implemented.
If you're also adeveloper on the project, value(重视) the time you spend writing code, and don't believe anyonewho tells you it's a distraction(分心的事物) from your work asarchitect. Your vision of both macro and micro levels will be greatly enhancedby the time you spend in the belly(腹中) of the beast(兽) bringing it to life.
注:设计规格是重要的,但规格不是我们的最终目的。多听同事的,重视写代码,有助于你的设计。所有的设计在实现时都需要被修正。
By Allison Randal
Licensed under Creative CommonsAttribution 3
(wc 313)
12、There is no one-size-fits-all(万全之策) solution
Architects must continuously develop and exercise “contextual sense” – because there is noone-size-fits-all solution to problems which may be widely(相差大地) diverse(变化多的).
The incisive(深刻的) phrase “contextual sense”was coined(铸造), and its meaning insightfully(深刻见解地) described, by Eberhardt Rechtin in his 1991 book Systems Architecting:Creating & Building Complex Systems:
[The central ideas of the ‘heuristic(启发式的) approach’ to architecting complex systems] come from asking skilledarchitects what they do when confronted with(面对) highly complex problems. The skilled architect and designer would mostlikely answer, ‘Just use common sense(常识).’ … A better expression than ‘common sense’is contextual sense – a knowledge(知识) of what is reasonable within a given context. Practicing(积极活动的) architects through education, experience, and examples accumulate a considerable(相当可观的) body(大量) of contextual sense by(通过) the time they’re entrusted(委托) with solving a system-level problem – typically 10 years.” [RechtinSysArch] (emphasis in the original)
A big problem in thesoftware industry, in my opinion, is that people are often responsible forsolving problems requiring more contextual sense than they’ve accumulated.Perhaps this is because the software industry isbarely(仅仅) two generations old andgrowing explosively(爆发地); perhaps it will be a sign of maturity in the software industry when thisproblem no longer exists.
I encounter examplesof this problem frequently in my consulting(顾问) engagements(雇佣). Typical examplesinclude failures to apply Domain-Driven Design [Evans DDD] when appropriate, straying(偏离) from a pragmatic(注重实效的) outlook(观点) and over-designing a software solution for the essential need at hand,and making irrelevant or unreasonable suggestions during performanceoptimization crises(紧要关头).
The most importantknowledge of software patterns is the knowledge of when to apply them and whennot to apply them, and the same is true of different root cause hypotheses(假定) and associated correctiveactions during problem analysis. In both activities – system architecting andproblem analysis – it is axiomatic(不言自明的) that there is no one-size-fits-all solution;architects must develop and exercise contextual sense in formulating(构想) and troubleshooting theirarchitectures.
注:最重要的是要体会contextual sense这个词,我的理解它是一种具体问题具体分析的能力或者那种感觉。
By Randy Stafford
This work islicensed under a Creative Commons Attribution 3
(wc 265)
13、It’s never too early to think about performance
Business users specify their needsprimarily through functional requirements. The non-functional aspects ofthe systems, like performance, resiliency(弹性), up-time(正常运行时间), support needs, and the like(等等), are the purview(范围) of the architect. However, oftenthe preliminary testing of non-functional requirements is left until very latein the development cycle, and is sometimes delegated completely to theoperations team. This is a mistake that is made far too often.
The reasons are varied(各式各样的). There is presumably(大概) no sense in making something fastand resilient if it doesn't actually perform the required function. Theenvironments and tests themselves are complex. Perhaps the early versionsof the production system will not be as heavily utilized.
However, if you aren't looking at performance until late in the project cycle,you have lost an incredible(难以置信的) amount of information asto when performance changed. If performance is going to be an importantarchitectural and design criterion, then performance testing should begin assoon as possible. If you are using an Agile methodology based on two weekiterations, I'd say performance testing should be included in the process no later than(不迟于) the third iteration.
Why is this so important? The biggest reason is that at the very least(丝毫) you know the kinds of changes thatmade performance fall off a cliff(悬崖). Instead of having to think about the entire architecturewhen you encounter performance problems, you can focus on the most recentchanges. Doing performance testing early and often provides you with a narrowrange of changes on which to focus. In early testing, you may not even try todiagnose performance, but you do have a baseline of performance figures to workfrom. This trend data provides vital information in diagnosing the sourceof performance issues and resolving them.
This approach also allows for the architectural and design choices to bevalidated against the actual performance requirements. Particularly forsystems with stringent(迫切的) requirements, earlyvalidation is crucial to delivering the system in a timely fashion.
Technical testing is also notoriously(出了名地) difficult to get going(实行). Setting up appropriate environments, generating theproper data sets, and defining the necessary test cases all take a lot of time.By addressing performance testing early you can establish your test environmentincrementally avoiding much more expensive efforts once after you discoverperformance issues.
By Rebecca Parsons
This work is licensed under a Creative CommonsAttribution 3
(wc 389)
14、Application architecture determines application performance
Application architecture determinesapplication performance. That might seem rather(相当) obvious, but real-word experienceshows that its not. For example, software architects frequently believe thatsimply switching from one brand of software infrastructure to another will besufficient to solve an application’s performance challenges. Such beliefs maybe based on a vendor’s benchmark(基准) trumpeting(吹嘘), say, 25% better performance than the closestcompetition’s. But, taken in context, if the vendor’s product performs anoperation in three milliseconds while the competition’s product takes fourmilliseconds, the 25% or one-millisecond advantage matters little in the midstof(在…之中) a highly inefficient architectureat the root of an application’s performance characteristics.
In addition to IT managers andvendor benchmarking teams, other groups of people – vendor support departments,and authors of application performance management literature – recommend simply“tuning” the software infrastructure, by fiddling(微不足道地) with memory allocations, connectionpool sizes, thread pool sizes, and the like. But if the deployment of anapplication is insufficiently architected for the expected load, or if theapplication’s functional architecture is too inefficient in its utilization ofcomputing resources, then no amount of “tuning” will bring about the desiredperformance and scalability characteristics. Instead a re-architecting of internallogic, or deployment strategy, or both, will be required.
In the end, all vendor products andapplication architectures are constrained by the same fundamental principles ofdistributed computing and underlying physics: applications, and the productsthey use, run as processes on computers of limited capacity, communicating witheach other via protocol stacks and links of non-zero latency. Therefore peopleneed to appreciate that application architecture is the primary determinant ofapplication performance and scalability. Those quality attributes cannot be miraculously(奇迹地) improved with some silver-bulletswitch of software brands, or infrastructure “tuning”. Instead, improvements inthose areas require the hard work of carefully-considered (re-) architecting.
By Randy Stafford
This work is licensed under a Creative CommonsAttribution 3
(wc 300)
15、Commit-and-run is a crime. Respect your Colleagues
It's late in the afternoon. The teamis churning out(艰苦地做出) the last pieces of thenew feature set for the iteration, and you can almost feel the rhythm(节奏) in the room. John is in a bit of ahurry though. He's late for a date, but he manages to(设法) finish up his code, compile,check-in and off he goes. A few minutes later, the red light turns on. Thebuild is broken. John didn't have time to run the automated tests, so he made acommit-and-run and thereby left everybody else hanging. The situation is nowchanged and the rhythm is lost. Everybody now knows that if they do an updateagainst the version control system, they will get the broken code onto theirlocal machine as well, and since the team has a lot to integrate this afternoonto prepare for the upcoming demo, this is quite a disruption. John effectivelyput the team flow to a halt because now no integration can be done before someonetakes the time to revert his changes.
This scenario is way(非常) too common. Commit-and-run is acrime because it kills flow. It's one of the most common ways for a developerto try to save time for himself, that ends up wasting other peoples time and itis downright(完全) disrespectful(无礼的). Still, it happens everywhere. Why?Usually because it takes too long time to build the system properly or to runthe tests.
This is where you, the architect, come intoplay(开始活动). If you've put a lot ofeffort into creating a flexible architecture where people can perform, taughtthe developers agile practices like test-driven development and set up acontinuous integration server, then you also want to nurture a culture whereit's not alright to waste anybody else's time and flow in any way. To be ableto get that, you need to make sure the system among other things has a soundarchitecture for automated testing, since it will change the behavior of thedevelopers. If tests run fast, they will run them more often, which itself is agood thing, but it also means that they won't leave their colleagues withbroken code. If the tests are dependent on external systems or if they need tohit the database, reengineer them so they can be run locally with mocks orstubs, or at the very least with an in-memory database, and let the buildserver run them in the slow way. People should not have to wait for computers,because if they have to, they will take shortcuts which often causes problemsfor others instead.
Invest time in making the systemfast to work with. It increases flow, lessens the reasons for working in silosand in the end makes it possible to develop faster. Mock things, createsimulators, lessen dependencies, divide the system in smaller modules or dowhatever you have to. Just make sure there's no reason to even think aboutdoing a commit-and-run.
By Niclas Nilsson
This work is licensed under a Creative CommonsAttribution 3
16、There Can be More than One
It seems to be a never–ending sourceof surprise and distress(不幸) to system builders thatone data model, one message format, one message transport—in fact, exactly oneof any major architectural component, policy or stance(姿态)—won'tserve all parts of the business equally well. Of course: an enterprise ("enterprise" is red flag #1) big enough to worry about how manydifferent "Account" tables will impact system building next decade ismost likely too big and diverse for one "Account" table to do the jobanyway.
In technical domains we can forceuniqueness. Very convenient for us. In business domains the inconsistent,multi–faceted, fuzzy, messy world intrudes(闯入). Worse yet, business doesn't even deal with "theworld", it deals with people's opinions about aspects of situations inparts of the world. One response is to deem(相信) the domain to be technical andapply a unique solution by fiat(批准). But reality is that which does not go away when one stopsbelieving in it, and the messiness always returns as the business evolves. Thusare born enterprise data teams, and so forth(等等), who spend all their (very expensive) time trying to tame(制服) existential dread(恐惧) through DTD wrangling. Payingcustomers tend to find the level of responsiveness that comes form thissomewhat unsatisfactory.
Why not face up to the reality of amessy world and allow multiple, inconsistent, overlapping representations,services, solutions? As technologists we recoil(畏缩) in horror form this. We imagineterrifying scenarios: inconsistent updates, maintenance overhead,spaghetti–plates of dependencies to manage. But let's take a hint from theworld of data warehousing(仓库贮存). The schemata data martsare often (relationally) denormalized, mix imported and calculated valuesarbitrarily, and present a very different view of the data than the underlyingdatabases. And the sky does not fall because of the non–functional propertiesof a mart(市场). The ETL process sits atthe boundary of two very different worlds, typically transaction versusanalytical processing. These have very different rates of update and query,very different throughput, different rates of change of design, perhaps verydifferent volumes. This is the key: sufficiently different non–functionalproperties of a sub–system create a boundary across which managing inconsistentrepresentations is tractable(易驾驭的).
Don't go duplicatingrepresentations, or having multiple transports just for the fun of it, but doalways consider the possibility that decomposition of your system bynon–functional parameters may reveal opportunities to allow diverse solutions toyour customers' advantage.
By Keith Braithwaite
This work is licensed under a Creative CommonsAttribution 3
17、Business Drives
In the context of businessenterprise application development, an Architect must act as a bridge betweenthe business and technology communities of an organization, representing andprotecting the interests of each party to the other, often mediating betweenthe two, but allowing the business to drive. The business organization'sobjectives and operating realities should be the light in which an Architectleads technology-oriented decision making.
Businesses routinely plan for andarticulate a specific, desired Return on Investment (ROI) before undertaking asoftware development initiative. The Architect must understand the desired ROI,and by implication, the limits of the value of the software initiative to thebusiness, so as to avoid making technology decisions that could cause theopportunity to be out-spent. ROI should serve as a major piece of objectivecontext in the give-and-take conversations with the business about the value ofa feature versus the cost of delivering that feature, and with the developmentteam about technical design and implementation. For example, the Architect mustbe careful to represent the interests of the business to the development teamby not agreeing to choose technology that has unacceptably costly licensing andsupport cost implications when the software is deployed into testing orproduction.
Part of the challenge of letting thebusiness “drive” is providing enough quality information about the ongoingsoftware development effort back into the business to support good businessdecision making. That’s where transparency becomes crucial. The Architect, inconjunction with development management, must create and nurture the means forregular, ongoing information feedback loops. This can be accomplished by avariety of lean software development techniques, such as big visible charts,continuous integration, and frequent releases of working software to thebusiness starting early in the project.
Software development isfundamentally a design activity, in that it involves an ongoing process ofdecision making until the developed system goes into production. It isappropriate for software developers to make many decisions, but usually not tomake business decisions. However, to the extent that the business communityfails to fulfill its responsibility to provide direction, answer questions andmake business decisions for the software development team, it is actuallydelegating the making of business decisions to software developers. TheArchitect must provide the macro-context for this ongoing series ofmicro-decisions made by developers, by communicating and protecting thesoftware architecture and business objectives, and seek to ensure developers donot make business decisions. Technical decision making un-tethered to thecommitments, expectations and realities of the business, as articulated by thebusiness community on an ongoing basis, amounts to costly speculation and oftenresults in an unjustifiable expenditure of scarce resource.
The long-term interests of thesoftware development team are best served when business drives.
By Dave Muirhead
This work is licensed under a Creative CommonsAttribution 3
18、Simplicity before generality, use before reuse
A common problem in componentframeworks, class libraries, foundation services, and other infrastructure codeis that many are designed to be general purpose without reference to concreteapplications. This leads to a dizzying array of options and possibilities thatare often unused, misused, or just not useful. Most developers work on specificsystems: the quest for unbounded generality rarely serves them well (if atall). The best route to generality is through understanding known, specificexamples and focusing on their essence to find an essential common solution.Simplicity through experience rather than generality through guesswork.
Favoring simplicity beforegenerality acts as a tiebreaker between otherwise equally viable designalternatives. When there are two possible solutions, favor the one that issimpler and based on concrete need rather than the more intricate one that boastsof generality. Of course, it is entirely possible (and more than a littlelikely) that the simpler solution will turn out to be the more general one inpractice. And if that doesn't turn out to be the case, it will be easier tochange the simpler solution to what you now know you need than to change the'general' one that turns out not to be quite general enough in the right way.
Although well meant, many thingsthat are designed just to be general purpose often end up satisfying nopurpose. Software components should, first and foremost, be designed for useand to fulfill that use well. Effective generality comes from understanding,and understanding leads to simplification. Generalization can allow us toreduce a problem to something more essential, resulting in an approach thatembodies regularity across known examples, a regularity that is crisp, concise,and well grounded. However, too often generalization becomes a work item initself, pulling in the opposite direction, adding to the complexity rather thanreducing it. The pursuit of speculative generality often leads to solutionsthat are not anchored in the reality of actual development. They are based onassumptions that later turn out to be wrong, offer choices that later turn outnot to be useful, and accumulate baggage that becomes difficult or impossibleto remove, thereby adding to the accidental complexity developers and futurearchitects must face.
Although many architects valuegenerality, it should not be unconditional. People do not on the whole pay for(or need) generality: They tend to have a specific situation, and it is asolution to that specific situation that has value. We can find generality andflexibility in trying to deliver specific solutions, but if we weigh anchor andforget the specifics too soon, we end up adrift in a sea of nebulouspossibilities, a world of tricky configuration options, overburdened (not justoverloaded) parameter lists, long-winded interfaces, and not-quite rightabstractions. In pursuit of arbitrary flexibility you can often lose valuableproperties, accidental or intended, of alternative, simpler designs.
By Kevlin Henney
(Edited RMH 2008-05-28,re-edited KH 2008-06-11 & 2008-07-02)
This work is licensed under a Creative CommonsAttribution 3
19、Architects must be hands on
A good architect shouldlead by example, he (or she) should be able to fulfill any of the positionswithin his team from wiring the network, and configuring the build process towriting the unit tests and running benchmarks. Without a good understanding ofthe full range of technology an architect is little more than a projectmanager. It is perfectly acceptable for team members to have more in-depthknowledge in their specific areas but it's difficult to imagine how teammembers can have confidence in their architect if the architect doesn'tunderstand the technology. As has been said elsewhere the architect is theinterface between the business and the technology team, the architect mustunderstand every aspect of the technology to be able to represent the team tothe business without having to constantly refer others. Similarly the architectmust understand the business in order to drive the team toward their goal ofserving the business.
An architect is like an airline pilot, he might not look busy all of the timebut he uses decades of experience to constantly monitor the situation, takingimmediate action if he sees or hears something out of the ordinary. The projectmanager (co-pilot) performs the day-to-day management tasks leaving thearchitect free from the hassles of mundane tasks and people management.Ultimately the architect should have responsibility for the delivery andquality of the projects to the business, this is difficult to achieve withoutauthority and this is critical the success of any project.
People learn best by watching others; it's how we learn as children. A goodarchitect should be able to spot a problem, call the team together and withoutpicking out a victim explain what the problem is or might be and provide anelegant work-around or solution. It is perfectly respectable for an architectto ask for help from the team. The team should feel part of the solution butthe architect should chair from discussion and identify the right solution(s).
Architects should be bought into the team at the earliest part of the project;they should not sit in an ivory tower dictating the way forward but should beon the ground working with the team. Questions about direction or choices oftechnology should not be spun off into separate investigations or new projectsbut be made pragmatically through hands-on investigation or using advice fromarchitect peers, all good architects are well connected.
A good architect should be an expert in at least one tool of their trade, e.g.an IDE, remember they are hands-on. It stands to reason that a softwarearchitect should know the IDE, a database architect should know the ER tool andan information architect an XML modelling tool but a technical or enterprisearchitect should be at least effective with all levels of tooling from beingable to monitor network traffic with Wireshark to modelling a complex financialmessage in XMLSpy - no level is too low or too high.
An architect usually comes with a good resume and impressive past, he canusually impress the business and technologists but unless he can demonstratehis ability to be hands-on it's difficult gain the respect of the team,difficult for the team to learn and almost impossible to deliver what they wereoriginally employed to do.
By http://commons.oreilly.com/wiki/index.php/User:JtdaviesJohn Davies
This work is licensed under a Creative CommonsAttribution 3
20、Continuously Integrate
The build as a "big bang"event in project development is dead. The architect, whether an application orenterprise architect, should promote and encourage the use of continuousintegration methods and tools for every project.
The term Continuous Integration (CI)was first coined by MartinFowler in a design pattern. CI refers to a set practices and tools thatensure automatic builds and testing of an application at frequent intervals,usually on an integration server specifically configured for these tasks. Theconvergence of unit testing practices and tools in conjunction with automatedbuild tools makes CI a must for any software project today.
Continuous Integration targets auniversal characteristic of the software development process – the integrationpoint between source code and running application. At this integration pointthe many pieces of the development effort come together and are tested. Youhave probably heard the phrase “build early and often”, which was a riskreduction technique to ensure there were no surprises at this point indevelopment. “Build early and often” has now been replaced by CI which includesthe build but also adds features that improve communication and coordinationwithin the development team.
The most prominent part of a CIimplementation is the build which is usually automated. You have the ability todo a manual build but they can also be kicked off nightly or can be triggeredby source code changes. Once the build is started the latest version of thesource code is pulled from the repository and the CI tools attempts to buildthe project then test it. Lastly, notification is sent out detailing theresults of the build process. These notifications can be sent in various formsincluding email or instant messages.
Continuous Integration will providea more stable and directed development effort. As an architect you will love itbut more importantly your organization and your development teams will be moreeffective and efficient.
By Dave Bartlett
This work is licensed under a Creative CommonsAttribution 3
21、Avoid Scheduling Failures
Failed projects can happen for a multitude of reasons. One of the mostcommon sources of failure is altering the project schedule in midstream(在中途)without proper planning. This kind of failure is avoidable, but it can requiremajor effort on the part of multiple people. Adjusting the time line orincreasing resources on a project are not normally(一般地)of concern(重要的)(不是一般地重要,也就是非常重要).Problems start when you are asked to do more in the same time line or when theschedule is shortened without reducing the workload(工作量).
The idea that schedules can be shortened in order to reduce cost or speed updelivery is a very common misconception(误解). You’ll commonly see attempts to requireovertime or sacrifice(牺牲) “less important scheduled tasks” (like unit-testing) as a way to reducedelivery dates or increase functionality while keeping the delivery dates as is(照原来的样子). Avoidthis scenario at all costs. Remind those requesting the changes of thefollowing facts:
1. A rushed(匆忙的) design schedule leads to poor design, bad documentation and probableQuality Assurance or User Acceptance problems.
2. A rushed coding or delivery schedule has a direct relationship to thenumber of bugs delivered to the users.
3. A rushed test schedule leads to poorly tested code and has a directrelationship to the number of testing issues encountered.
4. All of the above lead to Production issues which are much more expensiveto fix.
The end result is an increase in cost as opposed to a reduction in cost(最后的结果是本来想降低成本却导致成本的增加). This is normally why the failures happen.
As an Architect you will one day(总有一天) find yourself in the position of having to act quickly to increase the likelihood(可能性) of success. Speak up(大声地说) early. First try tomaintain quality by negotiating the originally planned timeline. If a shortenedschedule is necessary then try to move non-critical functionality to futurerelease(s). Obviously this will take good preparation, negotiating skills and aknack(诀窍)for influencing people. Prepare by sharpening your skills in those areas today.You will be glad you did.
注:架构师面对中途改变计划时,一定要通过调整基线或者削减非关键功能去保证质量,这需要高超的协调技巧。
By NormanCarnovale
This work islicensed under a Creative Commons Attribution 3
22、Architectural Tradeoffs
Every software architect should knowand understand that you can't have it all. It is virtually(事实上) impossible to design anarchitecture that has high performance, high availability, a high level ofsecurity, and a high degree of abstraction all at the same time. There is atrue story which software architects should know, understand, and be able tocommunicate to clients and colleagues. It is the story of a ship called the Vasa(瓦萨号).
In the 1620's Sweden(瑞典) and Poland(波兰) were at war. Wanting a quick end tothis costly war, the King of Sweden commissioned(授权) the building of a ship called the Vasa.Now, this was no(不是) ordinary(普通的) ship. The requirements for thisship were unlike any other ship of that time; it was to be over 200 feet long,carry 64 guns on two gun decks(甲板), and have the ability to transport 300 troops(军队) safely across the waters intoPoland. Time was of the essence(极重要的), and money was tight(sound familiar?). The ship architect had never designed such a ship before.Smaller, single gun deck ships were his area of expertise. Nevertheless(不过), the ship's architect extrapolated(推断) on(基于)his prior experience and set out(开始) designing and building the Vasa. The ship waseventually built to specifications, and when the eventful(重要的) day came for the launch, the shipproudly sailed into the harbor(海港), fired its gun salute(鸣礼炮), and promptly(迅速地) sank to the bottom of the ocean.
The problem with the Vasa wasobvious; anyone who has ever seen the deck of a large fighting ship from the1600's and 1700's knows that the decks on those ships were crowded and unsafe,particularly in battle. Building a ship that was both a fighting ship and atransport ship was a costly mistake. The ship's architect, in an attempt tofulfill all of the kings wishes, created an unbalanced and unstable ship.
Software architects can learn a lotfrom this story and apply this unfortunate event to the design of softwarearchitecture. Trying to fulfill each and every requirement (as with the Vasa)creates an unstable architecture that essentially accomplishes nothing well. A goodexample of a tradeoff is the requirement to make a Service-OrientedArchitecture (SOA) perform as well as a point-to-point solution. Doing sousually requires you to bypass the various levels of abstraction created by anSOA approach, thereby(从而) creating an architecturethat looks something like what you would typically order at your local Italianrestaurant. There are several tools available to architects to determine whatthe tradeoffs should be when designing an architecture. Two popular methods arethe Architecture Tradeoff Analysis Method (ATAM) and the Cost BenefitAnalysis Method (CBAM). You can learn more about ATAM and CBAM by visitingthe Software Engineering Institute (SEI) websites at http://www.sei.cmu.edu/architecture/ata_method.htmland http://www.sei.cmu.edu/architecture/cbam.htmlrespectively.
注:架构师在设计时要学会取舍,如果你什么都想实现结果是什么都实现不了。可以用ATAM和CBAM去决定怎么做权衡。
By Mark Richards
(Edited RMH 5/28/2008)
This work is licensed under a Creative CommonsAttribution 3
23、Database as a Fortress(堡垒)
The database is where all of thedata, both input by your employees and data collected from your customers,resides. User interfaces, business and application logic, and even employeeswill come and go, but your data lasts forever. Consequently, enough cannot besaid about the importance of building a solid data model from Day One.
The exuberance(生气勃勃) over agile techniqueshave left(留下了) many thinking that it’sfine, or even preferable, to design applications as you go. Gone are thedays of writing complex, comprehensive technical designs up front(一开始就写复杂设计的日子已经不再了)! The new school(学派) says deploy early and often. A lineof code in production is better than ten in your head. It seems almost too goodto be true, and where your data is concerned, it is.
While business rules and userinterfaces do evolve rapidly, the structures and relationships within the datayou collect often do not. Therefore, it is critical to have your data modeldefined right from the start, both structurally and analytically. Migratingdata from one schema to another in situ is difficult at best, time consumingalways, and error prone often. While you can suffer(忍受) bugs temporarily at the applicationlayer, bugs in the database can be disastrous(灾难性的). Finding and fixing a data layer design problem does notrestore your data once it has been corrupted.
A solid data model is one thatguarantees security of today’s data, but also extensible for tomorrow’s.Guaranteeing security means being impervious to bugs that will – despite yourbest efforts – be pervasive(普遍深入的) in an ever-changing(经常改变的) application layer(不管你怎么努力,缺陷总是普遍深入经常发生变化的应用层,保证安全意味着不受这些缺陷的影响). It means enforcingreferential integrity. It means building in domain constraints wherever theyare known. It means choosing appropriate keys that help you ensure your data’sreferential integrity and constraint satisfaction. Being extensible fortomorrow means properly normalizing your data so that you can easily addarchitectural layers upon your data model later. It means not taking shortcuts.
The database is the final gatekeeperof your precious data. The application layer which is, by design ephemeral(短暂的), cannot be its own watchdog. Forthe database to keep proper guard, the data model must be designed to rejectdata that does not belong, and to prevent relationships that do not make sense.Keys, foreign key relationships, and domain constraints, when described in a schema are succinct(简洁的), easy to understand and verify, andare ultimately self-documenting. Domain rules encoded the data model are alsophysical and persistent; a change to application logic does not wash them away.
To get the most out of a relationaldatabase – to make it a true part of the application as opposed to simply astorehouse for application data – you need to have a solid understanding ofwhat you are building from the start. As your product evolves, so too will thedata layer, but at each phase of its evolution, it should always maintain itsstatus as Fortress. If you trust it and bestow(给与) upon it the heavyresponsibility of trapping bugs from other layers of your application, you willnever be disappointed.
注:一开始就要把数据库设计好,易扩展,让它不受业务层的影响,把它作为最后的堡垒。
(RMH Edited 7/13/2008)
By Dan Chak
(Edited RMH 5/28/2008)
This work is licensed under aCreative Commons Attribution 3
24、Use uncertainty as a driver
Confronted with two options, mostpeople think that the most important thing to do is to make a choice betweenthem. In design (software or otherwise), it is not. The presence of two optionsis an indicator that you need to consider uncertainty(不确定性) in the design. Use the uncertaintyas a driver to determine where you can defer commitment to details and whereyou can partition(分类) and abstract to reducethe significance of design decisions. If you hardwire the first thing thatcomes to mind you're more likely to be stuck with(被...缠住无法摆脱) it, so that incidental(非主要的)decisions become significant and thesoftness of the software is reduced.
One of the simplest and mostconstructive definitions of architecture comes from GradyBooch: "All architecture is design but not all design is architecture.Architecture represents the significant design decisions that shape(塑造) a system, where significant ismeasured by cost of change." What follows from this is that aneffective architecture is one that generally reduces the significance of designdecisions(紧跟着上面的是,一个有效的架构是一个可以降低设计决定重要性的架构). An ineffectivearchitecture will amplify(扩大) significance.
When a design decision canreasonably go one of two ways, an architect needs to take a step back. Insteadof trying to decide between options A and B, the question becomes "How doI design so that the choice between A and B is less significant?" The mostinteresting thing is not actually the choice between A and B, but the fact thatthere is a choice between A and B (and that the appropriate choice is notnecessarily obvious or stable).
An architect may need to go incircles before becoming dizzy(晕眩的) and recognizing(认可) the dichotomy(二分法). Standing at whiteboard (energetically(积极地)) debating options with a colleague?Ummingand ahhing(唧唧歪歪) in front of some code,deadlocked over whether to try one implementation or another? When a newrequirement or a clarification of a requirement has cast doubt on(对...产生怀疑) the wisdom of a currentimplementation, that's uncertainty. Respond by figuring out(计算出)what separation or encapsulationwould isolate that decision from the code that ultimately depends on it.Without this sensibility(敏感性) the alternative responseis often rambling(蔓延) code that, like anervous interviewee, babbles(喋喋不休) away trying tocompensate for uncertainty with a multitude of speculative(投机的) and general options. Or,where a response is made with arbitrary but unjustified(未被证明其正确的) confidence, a wrong turnis taken at speed(飞快地) and without looking back(倒退).
There is often pressure to make adecision for decision's sake(缘故). This is where options thinking can help. Where there isuncertainty over different paths a system's development might take, make thedecision not to make a decision. Defer the actual decision until a decision canbe made more responsibly(可靠地), based on actualknowledge, but not so late that it is not possible to take advantage of theknowledge.
Architecture and process are interwoven(交织), which is a key reason thatarchitects should favor development lifecycles and architectural approachesthat are empirical(完全根据经验的) and elicit(得出)feedback, using uncertainty constructivelyto divide up both the system and the schedule.
注:当面对选择的时候,最有效的架构就是后退一步,通过分割或封装让选择变得不重要。
By Kevlin Henney
(Edited RMH 2008-05-28,re-edited KH 2008-07-02, edited-again 2008-07-12)
This work is licensed under a Creative CommonsAttribution 3
25、Scope is the enemy of success
Scope refers to a project's size. How much time, effort, and resources?What functionality at what level of quality? How difficult to deliver? How muchrisk? What constraints exist? The answers define a project's scope. Softwarearchitects love the challenge of big, complicated projects. The potential rewardscan even tempt people to artificially expand a project’s scope to increase itsapparent importance. Expanding scope is the enemy of success because theprobability of failure grows faster than expected. Doubling a project’s scopeoften increases its probability of failure by an order of magnitude.
Why does it workthis way? Consider some examples:
· Intuition tells us todouble our time or resources to do twice as much work. History[1] says impactsare not as linear as intuition suggests. For example, a four person team willexpend more than twice the communication effort as a team of two.
· Estimation is far from anexact science. Who hasn’t seen features that were much harder to implement thanexpected?
Of course, someprojects aren’t worth doing without some built-in size and complexity. While atext editor without the ability to enter text might be easy to build, itwouldn’t be a text editor. So, what strategies can help to reduce or managescope in real-world projects?
· Understand the real needs– The capabilities a project must deliver are a set of requirements.Requirements define functionality or qualities of functionality. Question anyrequirements not explained in terms of measurable value to the customer. If ithas no effect on the company’s bottom line, why is it a requirement?
· Divide and conquer – Lookfor opportunities to divide up the work into smaller independent chunks. It iseasier to manage several small independent projects than one large project withinterdependent(相互依赖的) parts.
· Prioritize – The world ofbusiness changes rapidly. Large projects’ requirements change many times beforethey’re completed. Important requirements usually remain important as thebusiness changes while others change or even evaporate(消失). Prioritization lets you deliver the most important requirements first.
· Deliver results as soon aspossible – Few people know what they want before they have it. A famous cartoonshows the evolution of a project to build a child’s swing based on what thecustomer said and what various roles in the project understood. The complicatedresult only faintly resembles a swing. The last panel, titled “What would haveworked”, shows a simple swing using an old tire. When the customer hassomething to try, the solution may be simpler than expected. Building the mostimportant things first gets you the most important feedback early, when youneed it most.
Agile advocates(提倡)[2] exhort(忠告) us to build "Thesimplest thing that could possibly work". Complex architectures fail farmore often than simpler architectures. Reducing project scope often results ina simpler architecture. Scope reduction is one of the most effective strategiesan architect can apply to improve the odds(几率) of success.
注:架构师要把握真实需求,尽量控制项目的范围。
By Dave Quick
[1] See "TheMythical Man-Month" by Fred Brooks
[2] See"eXtreme Programming eXplained" by Kent Beck
This work islicensed under a Creative Commons Attribution 3
26、Reuse is about people and education, not just architecture
You might adopt the approach that aframework that is well designed, or an architecture that is carefullyconsidered, and cleverly implemented will lend itself to re-use within yourorganization. The truth is that even the most beautiful, elegant and re-usablearchitecture, framework or system will only be re-used by people who:
a) know it is there
b) know how to use it
c) are convinced that it is betterthan doing it themselves
a) Know its there
Within your organization, developersor designers need to know a design, framework, library, or fragments of codeexists and where they can find all the critical information about theseelements (e.g. documentation, versions, and compatibility) in order to reusethem. It is a simple, logical truth that people won't look for things that theydon't believe to exist. You are more likely to succeed with reusable elementsif the information about them is “pushed”.
There are any number of methods forpushing information about reusable elements in an organization. These rangefrom wiki pages with an RSS feed providing update information, useful in verylarge teams, to e-mail announcing version updates in the source repository. Ina tiny team, the designer or lead developer can inform his colleagues inpersonal conversations or shouting it across the office. Ultimately, whateveryour process for communicating about reusable elements... make sure you haveone, don’t leave it up to chance.
b) Know how to use it
Understanding how to reuse anelement depends on skills and training. Of course there are those people who(to use Donald Knuth’s terminology) "resonate(共鸣)" with coding and design. Wehave all worked with them, the gifted(有天才的) developers and architects whose speed and depth ofunderstanding is impressive, even scary. But these people are rare. The rest ofyour team might be made up of good, solid, intelligent developers anddesigners. They need to be taught.
Developers and designers might notknow of the particular design pattern used in a design, or fully understand theinheritance model that the framework designer intended them to use. They needto be given easy access to that information in the form of up-to-datedocumentation, or even better, training. A little training goes a long way toensuring that everyone is on the same page when it comes to reuse.
c) Are convinced that its betterthan doing it themselves
People, and particularly developers,tend to prefer to solve problems themselves rather than ask for help. Askinghow something works is a sign of weakness, or even an indication of ignorance.This has a lot to do with the maturity and personality type of your individualteam-members, “Better than doing it themselves” means different things todifferent people. The “young guns” on your team will always want to writethings themselves because it appeases their ego(自负), whereas your more experiencedpeople are more likely to accept that someone else has given thought to theproblem domain and has something to offer in terms of a solution.
If your team doesn’t know where tofind reusable artifacts or how to reuse them they will default to the natural,human position: they will build it themselves. And you will pay for it.
注:架构师要别人知道有可重用的东西,怎样重用,让别人确信重用比自己重新实现的更好。
(RMH Edited 7/13/2008)
By Jeremy Meyer(Edited RMH 5/28/2008)
This work is licensed under a Creative CommonsAttribution 3
27、There is no 'I' in architecture
I know, there really is an ‘i’ inarchitecture. But it’s not a capital ‘I’, calling attention to(唤起注意) itself, dominating discussion. Thelower-case character fits neatly within the word. It’s there only because itfulfills requirements for proper spelling and pronunciation.
How does that relate to us assoftware architects? Our egos(自负) can be our own worst enemy. Who hasn’t experiencedarchitects who:
- Think they understand the requirements better than the customers.
- View developers as resources hired to implement their ideas.
- Get defensive when their ideas are challenged or ignore the ideas of others.
I suspect any experienced architecthas fallen into at least one of these traps at some point. I’ve fallen into allof them and learned painful lessons from my mistakes.
Why does this happen?
- We’ve had success – Success and experience build self-confidence and allow us to become architects. Success leads to bigger projects. There is a fine line between self-confidence and arrogance(自大). At some point the project is bigger than our personal ability. Arrogance sneaks in(渐显) when we cross that line but don’t know it yet.
- People respect us – Tough design questions provide a critical safety net. Our own defensiveness, arrogance, or emphasis on our experience can result in missed design questions.
- We’re human – Architects pour(灌注) themselves into each design. Criticism(批判) of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.
How do we avoid it?
- Requirements don’t lie - With correct, complete requirements, any architecture that meets them is a good one. Work closely with the customer to make sure you both understand the business value each requirement provides. You don’t drive the architecture, the requirements do. You do your best to serve their needs.
- Focus on the team –These are not just resources; they are your design collaborators and your safety net. People who feel unappreciated usually make a poor safety net. It’s the teams’ architecture, not yours alone. You provide guidance but everyone does the heavy lifting together. You need their help as much or more than they need yours.
- Check your work – The model is not the architecture. It is only your understanding of how the architecture should work. Work with your team to identify tests that demonstrate how the project’s architecture supports each requirement.
- Watch yourself – Most of us fight our natural tendencies(倾向) to defend our work, focus on our selfish interests, and see ourselves as the smartest person in the room. Pressure pushes these tendencies to the surface. Consider your interactions for a few minutes every day. Did you give everyone’s ideas the respect and acknowledgement they deserved? Did you react negatively to well meaning input? Do you really understand why someone disagreed with your approach?
Removing the ‘I’ from architecturedoesn’t guarantee success. It just removes a common source of failure that’sentirely your fault.
By Dave Quick
Thiswork is licensed under a Creative CommonsAttribution 3
28、Get the 1000ft(英尺) view
As an architect we want to know howgood the software is that we are developing. Its quality has an obviousexternal aspect, the software should be of value to its users, but there isalso a more elusive(难捉摸的) internal aspect toquality, to do with the clarity of the design, the ease with which we canunderstand, maintain, and extend the software. When pressed for a definition,this is where we usually end up saying "I know it when I see it." Buthow can we see quality?
In an architecture diagram littleboxes represent entire systems and lines between them can mean anything: adependency, the flow of data, or a shared resource such as a bus. Thesediagrams are a 30.000ftview, like a landscape seen from a plane. Typically the only other viewavailable is the source code, which is comparable to a ground level view. Bothviews fail to convey much information about the quality of the software, one istoo high level and the other provides so much information that we cannot seestructure. Clearly, what is missing is a view in between, a 1000ft view.
This 1000ft view would provide information at the rightlevel. It aggregates large amounts of data and multiple metrics, such as methodcount, class fan out, or cyclomatic complexity. The actual view very muchdepends on a specific aspect of quality. It can be a visual representation of adependency graph, a bar chart that shows metrics at a class level, or asophisticated polymetric view that correlates multiple input values.
Manually creating such views andkeeping them in sync with the software is a hopeless endeavor. We need toolsthat create these views from the only true source, the source code. For someviews, a design structure matrix for example, commercial tools exists but it isalso surprisingly easy to create specialized views by combining small toolsthat extract data and metrics with generic visualization packages. A simpleexample would be to load the output from checkstyle, which is essentially a setof metrics on the class and method level, into a spreadsheet to render charts.The same metrics could also be shown as a tree-map using the InfoViz toolkit. Agreat tool to render complex dependency graphs is GraphViz.
Once a suitable view is availablesoftware quality becomes a little less subjective. It is possible to comparethe software under development with a handful of similar systems. Comparingdifferent revisions of the same system will give an indication of trends whilecomparing views of different subsystems can highlight outliers. Even with justa single diagram we can rely on our ability to spot patterns and perceiveaesthetics. A well-balanced tree probably represents a successful classhierarchy, a harmonious(协调的) set of boxes might showcode that is organized into appropriately sized classes. Most of the time avery simple relationship holds: If it looks good it probably is good.
(RMH Edited 7/11/2008)
By Erik Doernenburg
This work is licensed under a Creative CommonsAttribution 3
29、Try before choosing
Creating an application requiresmany decisions to be made. Some might involve choosing a framework or librarywhile others revolve around the use of specific design patterns. In either casethe responsibility for the decision generally lies with(在于) the architect on the team. A stereotypical(典型的) architect might gather all theinformation that can be gathered, then mull(深思) over it for a while, and finally decree(颁布) the solution from the ivory towerfor it to be implemented by the developers. Not surprisingly there is a betterway.
In their work on lean developmentMary and Tom Poppendieck describe a technique for making decisions. They arguethat we should delay commitment until the last responsible moment, that is themoment at which, if the team does not make a decision, it is made for them;when inaction results in an outcome that is not (easily) reversible(可逆的). This is prudent(谨慎的) because the later a decision ismade the more information is available on which to base the decision. However,in many cases more information is not the same as enough information, and wealso know that the best decisions are made in hindsight(事后). What does this mean for the goodarchitect?
The architect should constantly be on the lookout(警惕) for decisions that will have to bemade soon. Provided the team has more than a handful of developers andpractices collective(集体的) code ownership thearchitect can, when such a decision point approaches, ask several developers tocomeup with(提出) a solution to theproblem and go with(伴随) it for a while. As thelast responsible moment arrives the team gets together and assesses the benefitsand drawbacks of the different solutions. Usually, now with the benefit ofhindsight, the best solution to the problem is apparent to everybody. Thearchitect does not have to make the decision, he or she merely orchestrates(组织) the decision making process.
This approach works for smalldecisions as well as for large ones. It can allow a team to figure out(解决) whether or not to use the Hibernatetemplates provided by the Spring framework but it can equally answer thequestion of which JavaScript framework to use. The duration for which thedifferent approaches evolve is obviously very dependent on the complexity ofthe decision.
Trying two or even more approachesto the same problem requires more effort than making a decision upfront andthen just implementing one. However, chances are that an upfront decision leadsto a solution that is later recognized to be sub-optimal(次优的), leaving the architect with adilemma: either the team rolls back the current implementation or they livewith the consequences, both of which result in wasted effort. Even worse, it isentirely possible that nobody on the team recognizes that the approach chosenis not the best one, because none of the alternatives were explored. In thiscase effort is wasted without any chance of addressing the waste. After all,trying multiple approaches might be the least expensive option.
注:架构师应该是组织开发者各自提出自己对问题的解决办法,然后大家评估最好的一个。
(RMH Edited 7/10/2008)
By Erik Doernenburg
This work is licensed under a Creative CommonsAttribution 3
30、Understand The Business Domain
Effective software architectsunderstand not only technology but also the business domain of a problem space.Without business domain knowledge, it is difficult to understand the businessproblem, goals, and requirements, and therefore difficult to design aneffective architecture to meet the requirements of the business.
It is the role of the softwarearchitect to understand the business problem, business goals, and businessrequirements and translate those requirements into a technical architecturesolution capable of meeting those requirements. Knowing the business domainhelps an architect decide which patterns to apply, how to plan for future extensibility,and how to prepare for ongoing industry trends. For example, some businessdomains (e.g., Insurance) lend themselves well to a Service-orientedarchitecture approach where as other business domains (e.g. Financial Markets)lend themselves more towards a workflow-based architecture approach. Knowingthe domain helps you decide which architecture pattern may work best to satisfythe specific needs of the organization.
Knowing the industry trends of aspecific domain can also help a software architect in designing an effectivearchitecture. For example, in the insurance domain, there is an increasingtrend towards "on-demand" auto insurance, where you only pay for autoinsurance when you actually drive your car. This type of insurance is great ifyou park your car at the airport on Monday morning, fly off to your workdestination, and return Friday to drive back home. Understanding such industrytrends enable you as a software architect to plan for these trends in thearchitecture, even if the company you are working with hasn't planned for themyet as part of their business model.
Understanding the specific goals ofthe business also helps you design an effective architecture. For example, dothe goals of the particular business you are working for include non-organicgrowth through heavy mergers and acquisitions? The answer to this question mayinfluence the type of architecture you design. If the answer is yes, thearchitecture might include many layers of abstraction to facilitate the mergingof business components. If the goals of the business include increased marketshare through a heavy online presence, then high availability is most likelygoing to be a very important attribute. As a software architect, alwaysunderstand the goals of the company you are working with, and validate that thearchitecture can support these goals.
The most successful architects Iknow are those who have broad hands-on(容易地) technical knowledge coupled with a strong knowledge of aparticular domain. These software architects are able to communicate withC-level executives and business users using the domain language that thesefolks know and understand. This in turn creates a strong level of confidencethat the software architect knows what he or she is doing. Knowing the businessdomain allows a software architect to better understand the problems, issues,goals, data, and processes, which are all key factors when designing aneffective enterprise architecture.
注:架构师不单需要掌握技术,还必须理解业务,否则很难设计出满足需求的架构。
By Mark Richards
This work is licensed under a Creative CommonsAttribution 3
31、Programming is an act of design
Kristen Nygaard, father ofobject-oriented programming and the Simula programming language, used to say:Programming is learning. Accepting the fact that programming or more preciselysoftware development is a processes of discovery and learning and not a processof engineering and construction are fundamental to bring software practicesforward. Applying the concepts of traditional engineering and construction onsoftware development does not work. The problems have been documented andcommented upon by leading software thinkers for more than 30 years. As anexample, In 1987 Fredric Brooks JR stated in the "Report of the DefenseScience Board Task Force on Military Software" that the document driven,specify-then-build approach lies at the heart of so many software problems.
So where should the softwareindustry go and look for improving their practices? What about the industriesinvolved in production of sophisticated mass-market products such as cars,pharmaceutical drugs or semiconductors?
Lets take a look at the carindustry. When planning a new model, the first thing is to choose a concept or archetype(原型). It’s primarily an architecturalpositioning mechanism. BMW X6 is an example of a new concept that combines theproperties of a SUV and a Coupe into what BMW calls a Sports Activity Coupe.The thing is that before you can purchase a new X6, BMW has invested thousandsof hours and millions of dollars in both its vehicle and manufacturing design.When BMW receives your order, one of their assembly lines will kick in andproduce your customized version of the X6.
So what is the lesson learned fromthis carmaker scenario? The important lesson is that the making of a new carinvolves two processes: The first process is the creative design process,including establishing the required assembly lines. The second process is themanufacturing of cars in line with customer specification. In many ways theseare the processes we find in the software industry as well. The challenge iswhat we put into the terms.
In the article “What is softwaredesign?” Jack Reeves suggested that the only artifact of software engineeringthat satisfied the criteria for a design document, as such document isunderstood and used in classical engineering, is the source code. Themanufacturing of the software is automated and taken care of by the compiler,build and test scripts.
By accepting that carving out sourcecode is an act of design, not an act of construction we are in a position toadopt useful management practices that are proven to work. Those are thepractices used to manage creative and unpredictable work such as developing anew car, a new medical drug or a new computer game. We talk about the practicesof agile product management and lean production such as SCRUM. These practicesfocus on maximizing return-on-investment in terms of customer value.
For the software industry to capitalize on(利用) these practices we must remember:Programming is an act of design, not an act of construction.
(RMH Edited 7/13/2008)
By Einar Landre
This work is licensed under a Creative CommonsAttribution 3
32、Time changes everything
One of the things I've been most entertained by as the years have gone by,is observing what things have lasted and what haven't. So many patterns,frameworks, paradigm changes, and algorithms, all argued for with passion bysmart people, thinking of the long term, balancing all the known issues, havenot warranted more than a yawn over the long haul. Why? What is history tryingto tell us?
Picka worthy challenge
This one is trickyfor a software architect. Challenges or problems are given to us, so we don'thave the luxury of choosing, right? It's not that simple. First of all we oftenmake the mistake of believing that we can't influence what we are asked to do.Usually we can, but it gets us out of our comfort zone in the technology space.There are dragons there when we don't choose to do the right things. Timepasses, we have worked diligently and hard solving the requested challenge, andin the end it doesn't matter: we didn't do what was really needed and our workis wasted. Over time, a good solution to the right challenge will probablyoutlast all others.
Simplerules
We say it toourselves: keep it simple stupid. We say it but we don't do it. We don't do itbecause we don't have to. We are smart and we can handle some complexity andeasily justify it because it adds agility to our design, because it is moreelegant to our aesthetic sensibilities, because we believe we can anticipatethe future. Then time passes, you walk away from the project for a year ormore. When you come back look at it, you almost always wonder why you did whatyou did. If you had to do it all over again, you would probably do itdifferently. Time does this to us. It makes us look silly. It is good torealize this early and get over yourself, and really try to learn what simplemeans in the lens that only time can grind.
Behappy with that old stuff
Architects love tosearch for the “one true way”, the methodology, or school of thought thatprovides the predictability we crave and the clear answers that always seemjust out of reach. The problem is that whatever guiding light you have in oneyear will probably not match the guiding light you have in a couple of years,much less a decade later. As you look back, you will always be looking atdesigns that don't match your current expectations. Learn to embrace that oldstuff, and resist the temptation to think you should go back and “fix” it. Wasthe solution an appropriate one for the problem? Did it solve the needs of theproblem? Keep these as your measure, you will be a lot happier.
By Philip Nelson
This work is licensed under a Creative Commons Attribution 3
33、Give developers autonomy
Most architects begin their careeras developers. An architect has new responsibilities and greater authority indetermining how a system is built. You may find it difficult to let go of(释放) what you did as a developer in yournew role as an architect. Worse, you may feel it's important for you toexercise a lot of control over how developers do their work to implement thedesign. It will be very important to your success and your team's success togive all of your teammates enough autonomy to exercise their own creativity andabilities.
As a developer you rarely get the time to sit back and really look at how thewhole system fits together. As an architect, this is your main focus. Whiledevelopers are furiously(猛烈地) building classes,methods, tests, user interfaces and databases, you should be making sure thatall those pieces work well together. Listen for points of pain and try toimprove them. Are people are having trouble writing tests? Improve theinterfaces and limit dependencies. Do you understand where you actually needabstraction and where you don't? Work for domain clarity. Do you know whatorder to build things in? Build your project plan. Are developers consistentlymaking common mistakes using an API you designed? Make the design more obvious.Do people really understand the design? Communicate and make it clear. Do youreally understand where you need to scale and where you don't? Work with yourcustomer and learn their business model.
If you're doing a great job of being an architect, you really shouldn't haveenough time to interfere with developers. You do need to watch closely enoughto see that the design is being implemented as intended. You do not need to bestanding over people's shoulders to accomplish that goal. It's reasonable tomake suggestions when you see people struggling, but it's even better if youcreate the environment where they come and ask you for suggestions. If you aregood, you will deftly(灵巧地) walk the fine linebetween guaranteeing a successful architecture and limiting the creative andintellectual life of your developers and teammates.
注:架构师要给开发者足够的自治权。
By Philip Nelson
This work is licensed under a Creative CommonsAttribution 3
34、Value stewardship(工作) over showmanship
When an architect enters a project,there is an understandable desire to prove one's worth. Being assigned the roleof software architect typically indicates implicit trust on the part of thecompany in architect's technical leadership, and it only follows that thearchitect would desire to make good on that expectation as soon as possible.Unfortunately, there are those who labor under the misapprehension that provingone's worth consists of showmanship; bedazzling(使困惑)ifnot(否则) baffling(困惑) the team with one's technical brilliance(光辉).
Showmanship(演出技巧), the act of appealing to(有吸引力) your audience, is important inmarketing, but it's counter productive to leading a software developmentproject. Architects must win the respect of their team by providing solidleadership and by truly understanding the technical and business domain inwhich they are expected to operate.
Stewardship(工作), taking responsibility and care ofanother’s property, is the appropriate role of an architect. An architectmust act in the best interests of their customer and not pander to(迎合) the needs of their own ego.
Software architecture is about serving the needs of one's customers, typicallythrough direction from those with domain expertise that surpasses one's own.Pursuing successful software development will lead one to create solutions ofcompromise, balancing the cost and complexity of implementation against thetime and effort available to a project. That time and effort are the resourcesof the company, which the software architect must steward(管理) without self-serving(自私的) undercurrents(潜流). Unduly(过度地) complex systems that sport the latest hot framework ortechnology buzzword(时髦词语) seldom do so withoutsome sacrifice at the company's expense. Much like an investment broker, thearchitect is being allowed to play with their client's money, based on thepremise that their activity will yield an acceptable return on investment.
Value stewardship over showmanship; never forget that you are playing withother peoples' money.
By Barry Hawkins
This work is licensed under a Creative CommonsAttribution 3
35、
36、The title of software architect has only lower-case 'a's; deal withit
A disappointing trend has been inbloom for some time now within software development; the attempt toprofessionalize the practice of software architecture as one on par with theclassical school of Architecture. Thisseems to stem from some need for further legitimization of one's accomplishmentbeyond acknowledgment among one's peers and employer. By comparison,Architecture itself was not professionalized until the late 19th century, atleast a few millennia after the practice had been around. It would be no greatstretch to say that some software architects seem a bit eager by comparison.
Software architecture is a craft,and it certainly takes practice and discipline to achieve success in the field.That said, software development is still a relatively nascent endeavor. Wedon't even know enough about this practice to adequately professionalize it.Despite its youth, software development's product has become a highly valued tool,and as such, the accomplished individuals (as well as those who wish to be seenas accomplished) have enjoyed levels of compensation on par with the leadingprofessional fields, including medicine, accounting, and law.
Practitioners of software developmentenjoy considerable compensation for work that is highly creative andexploratory. The fruits of our labors have been used to accomplish manysignificant milestones, some that benefit all of mankind. The barriers to entryare largely one's own merit and opportunity; the fully-professionalized fieldsundergo programs of study and internship that dwarf our own. Dwell on that fora moment and ponder how much cause we have to be content, and just how brash itis to insist that software architect be considered a title that sits as peer toLawyer, Doctor, and Architect.
The title of software architect hasonly lower-case 'a's; deal with it.
By Barry Hawkins
This work is licensed under a Creative CommonsAttribution 3
37、Software architecture has ethical(道德的) consequences(结果)
The ethical dimension in software isobvious when we are talking about civil rights, identity theft, or malicious(怀恶意的) software. But they arisein less exotic(外来的) circumstances. Ifprograms are successful, they affect the lives of thousands or millions ofpeople. That impact can be positive or negative. The program can make theirlives better or worse--even if just in minute(极小的) proportions(比例).
Every time I make a decision abouthow a program behaves, I am really deciding what my users can and cannot do, inways more inflexible than law. There is no appeals court for required fields ormandatory workflow.
Another way to think about it is interms of multipliers. Think back to the last major Internet worm, or when a biggeek movie came out. No doubt, you heard or read a story about how muchproductivity this thing would cost the country. You can always find someanalyst with an estimate of outrageous(可恶的) damages, blamed on anything that takes people away fromtheir desks. The real moral of this story isn't about innumeracy(科学盲) in the press, or self-aggrandizingaccountants. It's about multipliers, and the effect they can have.
Suppose you have a decision to makeabout a particular feature. You can do it the easy way in about a day, or thehard way in about a week. Which way should you do it? Suppose that the easy waymakes four new fields required, whereas doing it the hard way makes the programsmart enough to handle incomplete data. Which way should you do it?
Required fields seem innocuous(无伤大雅的), but they are always an impositionof your will on users. They force users to gather more information beforestarting their jobs. This often means they have to keep their data on Post-Itnotes until they've got everything together at the same time, resulting in lostdata, delays, and general frustration.
As an analogy, suppose I'm putting asign up on my building. Is it OK to mount the sign just six feet up on thewall, forcing pedestrians(步行者) to duck or go around it?It's easier for me to hang the sign if I don't need a ladder and scaffold(脚手架), and the sign wouldn't even blockthe sidewalk(人行道). I get to save an hourinstalling the sign, at the expense of taking two seconds away from everypedestrian passing my store. Over the long run, all of those two seconddiversions are going to add up to many, many times more than the hour that Isaved.
It's not ethical to worsen the livesof others, even a small bit, just to make things easy for yourself. Successfulsoftware affects millions of people. Every decision you make imposes your willon your users. Always be mindful of the impact your decisions have on thosepeople. You should be willing to(乐于) bear large burdens to ease theirs.
By Michael Nygard
This work is licensed under a Creative CommonsAttribution 3
38、Everything will ultimately failv
Hardware is fallible, so we addredundancy. This allows us to survive individual hardware failures, butincreases the likelihood of having at least one failure present at any giventime.
Software is fallible. Ourapplications are made of software, so they're vulnerable to failures. We addmonitoring to tell us when the applications fail, but that monitoring is madeof more software, so it too is fallible.
Humans make mistakes; we arefallible also. So, we automate actions, diagnostics, and processes. Automationremoves the chance for an error of comission, but increases the chance of anerror of omission. No automated system can respond to the same range ofsituations that a human can.
Therefore, we add monitoring to theautomation. More software, more opportunities for failures.
Networks are built out of hardware,software, and very long wires. Therefore, networks are fallible. Even when theywork, they are unpredictable because the state space of a large network is, forall practical purposes, infinite. Individual components may actdeterministically, but still produce essentially chaotic behavior.
Every safety mechanism we employ tomitigate one kind of failure adds new failure modes. We add clustering softwareto move applications from a failed server to a healthy one, but now we risk"split-brain syndrome" if the cluster's network acts up.
It's worth remembering that the Three Mile Island accident was largely caused by apressure relief value---a safety mechanism meant to prevent certain types ofoverpressure failures.
So, faced with the certainty offailure in our systems, what can we do about it?
Accept that, no matter what, yoursystem will have a variety of failure modes. Deny that inevitability, and youlose your power to control and contain them. Once you accept that failures willhappen, you have the ability to design your system's reaction to specificfailures. Just as auto engineers create crumple zones---areas designed toprotect passengers by failing first---you can create safe failure modes thatcontain the damage and protect the rest of the system.
If you do not design your failuremodes, then you will get whatever unpredictable---and usually dangerous---oneshappen to emerge.
By Michael Nygard
This work is licensed under a Creative CommonsAttribution 3
39、Context is King
I feel there is a certain irony intrying to impart something about architectural ideals, when the very premise Iwish to begin with is that effectively there are no ideals. If this isindeed the case, then surely there is nothing to write, I am a contradictionand by doing this I run the risk of the universe imploding or something likethat.
But alas, ceci n'est pas unepipe.
One of the most valuable lessonsthat I have learned as a software architect is that context is king, and simplicityits humble servant. What this means in practical terms is that context is theonly force that trumps simplicity when making architectural decisions.
When I say context, I refer not onlyto high-level, immediate forces such as key business drivers, but also toelements in the periphery, such as emerging technologies and thought leadershipon diverse topics. Indeed, good architects keep track of several fast-movingtargets.
What constitutes good architecture?It is the product of decisions made within a context usually tainted withmultiple competing priorities. Those competing priorities mean that sometimesthe most important decisions are not about what you put in, but rather what youomit. The currency of good architecture is simply astute decision-making (whilethe products are all only about communicating your intent).
Historically, there have been somefascinating examples of the influence that context can have on architecture. Afavorite example involves the database selected to support an ambitious newsoftware system for a modern battlefield tank [1]. (Deciding what database touse is not usually architecturally significant; this example merely serves toillustrate a point).
When it came time to choose thedatabase, the team assessed many. They found that while the tank was movingquickly over undulating terrain while tracking a target, the majority of thedatabases were capable of supporting this maximal throughput required of thenavigation and targeting systems. But they were taken by surprise when theydiscovered that firing the main gun on the tank caused such a strongelectromagnetic pulse that it totally crashed the on-board systems and ofcourse the database along with it! On a modern battlefield, a tank without itssoftware running is quite literally in the dark. In this context, recoverytime was the overwhelming factor in the choice of database, and no databasedid that better at the time than InterBase [2], and that is why it was chosenfor the M1 Abrams tank.
So, while newsgroups rage with theflames of technology debates of X vs Y, it is idle amusement. The reason thesedebates rage is often not because of huge disparities in their technicalmerits, but rather because there are more subtle differences between them, andwhat features individuals value more than others when there is no guiding contextto act as a trump card.
Your team should be free of ideals,reflect on context in the first instance, and reach for the simplest solutionsfrom there.
By Edward Garson
This work is licensed under a Creative CommonsAttribution 3
Footnotes
[1] - A tank, despite its extremelydubious purpose, is still an engineering marvel.
[2] - Interestingly, InterBase hadan architecture that caused disk-writes to leave the database in analways-consistent state. This is one reason that contributes to its ability torecover from hard failures so quickly.
40、It's all about performance
Imagine a personal vehicle that isroomy, comfortable, fuel efficient, inexpensive to produce, and 98% recyclable.You want one? Sure. Everyone does. Just one problem: Its top speed is 6miles/hour (10 km/hour).Still want one? This small example demonstrates that performance is just asimportant as any other criterion.
The reason many designers putperformance at the bottom of their lists might be that computers are so muchfaster at computation than their human counterparts, that they assume that thespeed of the system will be acceptable. And if today's systems aren't fastenough, Moore'sLaw will take care of everything. But hardware speed is only part of thesystem.
Performance is sometimes thought ofas a simple measurement of the time it takes for a system to respond to userinput. But system designers must consider many aspects of performance,including performance of the analysts and programmers who implement the design;performance of the human interactions of the system; and performance of thenon-interactive components.
Performance of the people buildingthe system is often called productivity, and it is important because itdirectly affects the cost and schedule of the project. A team that delivers aproject late and over budget has a lot of 'splainin' to do. Using tools andpre-built components can dramatically affect how quickly the system can bebuilt and start returning value.
Performance of the humaninteractions is critical to acceptance of the system. Many factors of systemdesign contribute to this aspect of performance, response time being perhapsthe most obvious. But response time is not the only factor. Just as importantare intuitiveness of the interface and number of gestures required to achieve agoal, both of which directly affect performance.
More than response time per se, agood system specification will measure task time, defined as the time requiredto complete a domain-specific task, including all human interactions with thesystem. In addition to system response time, this measurement includes operatorthink time and operator data entry time, which are not under the control of thesystem. But including these times gives motivation to the proper design of thehuman interface. Proper attention to the way information is presented and thenumber of gestures required to complete the task will result in better humanoperational performance.
Performance of the non-interactivecomponents is equally important to the success of the system. For example, a "nightly"batch run that takes more than 24 hours to complete will result in an unusablesystem. Performance of the disaster recovery component is also a criticalconsideration. In case of total destruction of one part of the system, howquickly can operational status be restored, in order to allow normal businessto resume?
When considering the implementationand operation of a successful system, architects and designers should alwayspay careful attention to performance.
(RMH Edited 7/2/2008)
By Craig L Russell
This work is licensed under a Creative CommonsAttribution 3
41、Engineer in the white spaces
A system consists of interdependentprograms. We call the arrangement of these programs and their relationships"architecture". When we diagram these systems, we often representindividual programs or servers as simplistic little rectangles, connected byarrows.
One little arrow might mean,"Synchronous request/reply using SOAP-XML over HTTP." That's quite alot of information for one glyph to carry. There's not usually enough room towrite all that, so we label the arrow with either "XML overHTTP"---from an internal perspective---or "SKU Lookup"---for theexternal perspective.
That arrow bridging programs lookslike a direct contact, but it isn't. The white space between the boxes isfilled with hardware and software components. This substrate may contain:
* Network interface cards* Network switches* Firewalls* IDS and IPS* Message queues or brokers* XML transformation engines* FTP servers* "Landing zone" tables* Metro-area SoNET rings* MPLS gateways* Trunk lines* Oceans* Cable-finding fishing trawlers
There will always be four or fivecomputers between program A and B, running their software for packet switching,traffic analysis, routing, threat analysis, and so on. As the architectbridging between those programs, you must consider this substrate.
I saw one arrow labeled"Fulfillment". One server was inside my client's company, the otherserver was in a different one. That arrow, critical to customer satisfaction,unpacked to a chain of events that resembled a game of "Mousetrap"more than a single interface. Messages went to message brokers that dumped tofiles, which were picked up by a periodic FTP job, and so on. That one"interface" had more than twenty steps.
It's essential to understand thatstatic and dynamic loads that arrow must carry. Instead of just "SOAP-XMLover HTTP", that one little arrow should also say, "Expect one queryper HTTP request and send back one response per HTTP reply. Expect up to 100requests per second, and deliver responses in less than 250 milliseconds99.999% of the time."
There's more we need to know aboutthat arrow.
* What if the caller hits it too often? Should the receiver drop requests on the floor, refuse politely, or make the best effort possible?* What should the caller do when replies take more than 250 milliseconds? Should it retry the call? Should it wait until later, or assume the receiver has failed and move on without that function?* What happens when the caller sends a request with version 1.0 of the protocol and gets back a reply in version 1.1? What if it gets back some HTML instead of XML? Or an MP3 file instead of XML?* What happens when one end of the interface disappears for a while?
Answering these questions is theessence of engineering the white spaces.
By Michael Nygard
This work is licensed under a Creative CommonsAttribution 3
42、Talk the Talk
As with any profession, jargon isused so that individuals within that profession can effectively communicatewith one another. Lawyers talk to one another about habeas corpus(人生保护权), voir dire, and venire; Carpenterstalk to one another about butt joints(接头), lap joints, and flux; Software Architects talk to oneanother about ROA, Two Step View, and Layer Supertype. Wait, what was that?
It is imperative(必要的) that software architects,regardless of the platform they are working in, have an effective means ofcommunication between one another. One of those means of communication isthrough architecture and design patterns. To be an effective software architectyou must understand the basic architecture and design patterns, recognize whenthose patterns are being used, know when to apply the patterns, and be able tocommunicate to other architects and developers using them.
Architecture and design patterns canbe classified into four basic categories: Enterprise Architecture Patterns,Application Architecture Patterns, Integration Patterns, and Design Patterns.These categories are generally based on the level of scope within the overallarchitecture. Enterprisearchitecture patterns deal with the high-level architecture, whereas designpatterns deal with how individual components within the architecture arestructured and behave.
Enterprise Architecture Patternsdefine the framework for the high-level architecture. Some of the more commonarchitecture patterns include Event Driven Architecture (EDA), Service OrientedArchitecture (SOA), Resource Oriented Architecture (ROA), and Pipeline(管道) Architecture.
Application Architecture Patternsspecify how applications or subsystems within the scope of a larger enterprisearchitecture should be designed. Some common pattern catalogs in this categoryinclude the well-known J2EE design patterns (e.g., Session Façade and TransferObject) and the application architecture patterns described in Martin Fowler’sbook “Patterns of Enterprise Application Architecture”.
Integration Patterns are importantfor designing and communicating concepts surrounding the sharing of informationand functionality between components, applications, and subsystems. Someexamples of Integration Patterns include file sharing, remote procedure calls,and numerous messaging patterns. You can find these patterns at http://www.enterpriseintegrationpatterns.com/eaipatterns.html.
Knowing the basic design patterns asdescribed by the Gang of Four book “Design Patterns: Elements of ReusableObject-Oriented Software” is a must for any software architect. Although thesepatterns may appear to be too low-level for a software architect, they are partof a standard vocabulary that makes for effective communication betweenarchitects and developers.
It is also important to be aware ofand understand the various anti-patterns as well. Anti-patterns, a term coinedby Andrew Koenig, are repeatable processes that produce ineffective results.Some of the more well-known anti-patterns include Analysis Paralysis, Design ByCommittee, Mushroom Management, and Death March. Knowing these patterns willhelp you avoid the many pitfalls you will most likely experience. You can finda list of the common anti-patterns at http://en.wikipedia.org/wiki/Anti-patterns.
Software architects need the abilityto effectively communicate with one another in a clear, concise, and effectiveway. The patterns are there; it is up to us as software architects to learn andunderstand these patterns so we can “walk the walk and talk the talk”.
By Mark Richards
This work is licensed under a Creative CommonsAttribution 3
43、Heterogeneity Wins
Thenatural evolution of computer technology has brought about important changes with respect to(关于) the tools that architects can use to build software systems. Thesechanges have brought about a resurgence(苏醒) of interest in polyglot(数种语言的) programming, which refers to the use ofmore than one core language in the provision(预备) of a software system.
Polyglot programming is not a new concept: one prominent(显著的) example from the past is front-end Visual Basic clients supportedby COM objects authored in C++ on the back-end. Fundamentally speaking, thisarchitecture leveraged what those languages were good at in their heyday.
So what changes took place to fuel this renewed interest in polyglotprogramming?
The change is that technical standards together with ever-increasing bandwidthand computing resources conspired(凑合起来) tomake text-based protocols viable: gone are the days of arcane(神秘的) binary protocols as a pre-requisite to efficient distributedsystems. Text-based remote interoperability largely began with XML/SOAP-basedweb services and continues to evolve with RESTful architectural styles andother supporting (but no less important) protocols such as Atom and XMPP.
This new breed of technologies creates far broader opportunities forheterogeneous development than ever before, simply because the payloadis formattedtext, which is universally generated and consumed. Heterogeneous developmentaffords using the right tool for the job, and text-based interop has blown thedoors off what was previously possible.
Architects can now combine specific, powerful tools that move the yardstick(衡量标准) from previously being able to employ the right language to nowbeing able to employ the right paradigm. Programming languages supportdifferent paradigms, in that some are object-oriented, while others arefunctional or excel at concurrent programming. Some of these paradigms are aperfect match for particular problems or domains, while others are a poor fit.Today, however, it is possible to 'mash-up' some rather unconventional andseemingly dissonant tools into elegant solutions rather more easily than in thepast.
The effects of this change has begun, and manifests itself as a combinatorialincrease in the architectural topology of modern software systems. This is notjust a reflection of their inherent diversity(多样性), but a testament(遗嘱) to new possibilities.
While choice is not always a good thing, it is 'less worse' than thealternative in the context of modern software architecture. As an industry, weare faced with very serious problems[1] and we need all the interoperability wecan get, particularly as the incumbent(职责所在的) platforms are not well equipped(装备) to resolve them[2].
Yourjob as architect has become even more challenging, because technology silos(粮仓) are crumbling in the face of new possibilities: embrace this, thinkoutside the stack, and leverage the new diversity: heterogeneity wins.
[1]- The impending multicore era may well prove to be the most significant problemyet faced by the software development community.
[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm
By Edward Garson
Thiswork is licensed under a Creative CommonsAttribution 3
44、Dwarves, Elves, Wizards, and Kings
InCryptonomicon, Randy Waterhouse explains his classification system for the differenttypes of people he meets. Dwarves are hard workers, steadily producingbeautiful artifacts in the dark loneliness of their caves. They exert(努力) tremendous forces moving mountains and shaping earth, and arerenowned for their craftsmanship. Elves are elegant, cultured, and spend theirdays creating new and beautiful magical things. They are so gifted they don'teven realize that other races view these things as otherworldly almost. Thewizards are immensely powerful beings almost completely unlike all others, butunlike the Elves, they do know about magic, and its power and nature, and wield(挥) it with supreme(至高的) effect. But there is a fourthtype of character that Waterhouse alludes(间接提到) to but does not mentionspecifically. The Kings are the visionaries who know what must be done with allof these different characters.
AnArchitect is a King of sorts. The Architect must be familiar with all of thesecharacters, and ensure that the architecture has roles for all of thesecharacters. An architecture designed only for one will only attract(吸引) that one character to the project, and even with the best dwarves,or elves, or wizards, the team will be severely limited in its reach if it canonly approach problems in one way.
Agood king will lead all types through a quest, and help them work together tocomplete it. Without the quest, there is no vision for the team, and itultimately becomes a partisan mess. Without all characters, the team can onlysolve one class of problem, and is stopped at the first barrier impassable tothat solution.
Thearchitect creates the quest with all the characters in mind. The architecturethen becomes a guide for finding tasks for the different characters to performwhile learning about each other. When a project encounters difficulty, the teamwill already know how to approach solving it because the architecture gave themthe opportunities to grow into a team.
By:EvanCofsky
Thiswork is licensed under a Creative CommonsAttribution 3
45、Learn from Architects of Buildings
Architecture is a social act and thematerial theater of human activity.”—Spiro Kostof
How many software architects seetheir role as exclusively, or primarily technical? Is it not rather that theyare the conciliators(抚慰者), go–betweens andarbiters of the warring factions among the stake-holders? How many approachtheir work in a purely intellectual spirit, without giving proper weight to thehuman factors of their job?
“A great architect is not made byway of a brain nearly so much as he is made by way of a cultivated, enrichedheart.”—FrankLloyd Wright
What more strongly marks out thearchitects in your organization: raw intellectual horsepower and vast capacityto recall technical minutia, or taste, refinement and generosity of spirit?Under which tendency would you prefer to work?
“A doctor can bury(隐藏) his mistakes but an architect canonly advise his client to plant vines.”—ibid
Is the "maintenance" of"legacy" systems anything more than pruning those vines? Would you,as an architect, have the intestinal fortitude to scrap a piece of work that hadfailed? Or would you cover it up? Wright also said that the architect's bestfriend was the sledgehammer(大钟). What have you demolished(粉碎) recently?
“Architects believe that not only dothey sit at the right hand of God, but that if God ever gets up, they take thechair”—KarenMoyer
For "God" read"customer".
“In architecture as in all otheroperative arts, the end must direct the operation. The end is to build well.Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton
When was the last time you saw apiece of software who's architecture gave you any delight? Do you aim togive delight with your work?
"No person who is not a great sculptor(雕刻家) or painter can be an architect. Ifhe is not a sculptor or painter, he can only be a builder"—John Ruskin
Does artistry play its proper partin your architecture? Is the assemblage of components to make systems informedby a painterly concern for shape and texture, with a sculptural(雕刻般的) sense of balance and impliedmotion, of the importance of negative space?
And finally, no gloss is required onthis comment, a sure remedy for the software architect's most damaging syndrome(综合病症).
"It seems a fantastic(荒谬的) paradox, but it is nevertheless amost important truth, that no architecture can be truly noble which is notimperfect."—ibid
By Keith Braithwaite
This work is licensed under a Creative CommonsAttribution 3
46、Fight repetition
Are your developers performing recurring(重复的) tasks that needs little thinking?Can you find recurring patterns in the code? Can you spot code that's beenwritten copy-paste-modify style? If that's the case, your team is moving slowerthan they should and oddly enough - you may be the cause.
Before explaining why, let's agreeon a couple of truths about software development:
1) Duplication is evil.
2) Repetitive work slows downdevelopment.
As an architect, you set the tone.You've got the best overall grasp of the system and you probably wrote atrend-setting, end-to-end, vertical slice of the system that serves as anexample for the team - an example that has been copied many times by now.Whenever a developer copies anything - be it a few lines of code, an XML-file,or a class - that's a clear indication that something could be made simpler oreven completely abstracted away. Most often, it's not the domain logic that iscopied; it's the infrastructure code that just has to be there to make it work.For that reason, it's crucial that you can envision the effects your exampleshave. Any code and configuration in your examples will be the base for tens,hundreds, or maybe thousands other slices of the system, which means you haveto make sure that your code is clean, intention revealing, and contains nothingexcept what can't be abstracted away - the domain problem itself. As anarchitect, you need to be highly sensitive to any kind of repetitive patterns,since anything you write will (ironically) be repeated.
But that doesn't happen in yoursystem, right? Take a look at that configuration file. What needs to bedifferent if applied on another slice of the system and what will stay thesame? Look at a typical business layer method. Is there a pattern that shows upin other methods as well, containing things like transaction handling, logging,authentication or auditing? How about the data access layer? Any code in therethat will be the same except for names of entities and fields? Look broader.Can you find two or three lines of code that frequently seems to go togetherand even though they operate on different objects, it feels like the samething? These are all examples of repetition. Repetition in code is somethingthat developers eventually learn to filter out and ignore when reading thecode, once they figured out where the interesting variabilities are found, buteven if the developers get used to it - it slows them down. Code like that isclearly written for computers execute, not for developers to read.
Your responsibility is to remove it.To do that, you may need to harvest frameworks, create better abstractions,perhaps ask the toolsmith to setup an aspect framework or write a few smallcode generators, but the repetition won't go away unless someone does somethingabout it.
That someone is you.
(Niclas Nilsson Edited 29/9/2008)
(RMH Edited 7/9/2008)
By Niclas Nilsson
This work is licensed under a Creative CommonsAttribution 3
47、Welcome to the Real World
Engineerslike precision, especially software engineers who live in the realm of ones andzeros. They are used to working with binary decisions, one or zero, true orfalse, yes or no. Everything is clear and consistent, guaranteed by foreign keyconstraints, atomic transactions, and check sums.
Unfortunately, the real world is not quite that binary. Customers place orders,just to cancel them a moment later. Checks bounce, letters are lost, paymentsdelayed, and promises broken. Data entry errors are bound to happen every sooften. Users prefer "shallow" user interfaces, which give them accessto many functions at once without being boxed into a lengthy, one-dimensional "process",which is easier to program and seems more "logical" to manydevelopers. Instead of the call stack controlling the program flow, the user isin charge.
Worse yet, widely distributed systems introduce a whole new set ofinconsistencies into the game. Services may not be reachable, change withoutprior notice, or do not provide transactional guarantees. When you runapplications on thousands of machine, failure is no longer a question of"if", but of "when". These systems are loosely coupled,asynchronous, concurrent, and do not adhere to traditional transactionsemantics. You should have taken the blue pill!
As computer scientists' brave new world is crumbling(粉碎), what are we to do? As so often,awareness is a first important step towards a solution. Say good bye to thegood old predictive call-stack architecture, where you get to define whathappens when and in what order. Instead, be ready to respond to events at anytime in any order, regaining your context as needed. Make asynchronous requestsconcurrently instead of calling methods one by one. Avoid complete chaos bymodeling your application using event-driven process chains or state models. Reconcile(使和解) errors through compensation, retry,or tentative operations.
Sounds scary(引起惊慌的) and more than you bargained for?Luckily, the real world had to deal with the same issues for a long time:delayed letters, broken promises, messages crossing in transit, payments postedto the wrong account -- the examples are countless. Accordingly, people had toresend letters, write off bad orders, or tell you to ignore the paymentreminder in case you already sent a payment. So don't just blame the real worldfor your headaches, but also use it as a place to look for solutions. Afterall, Starbucks does not two-phase commit either [1]. Welcome to the real world.
[1] http://www.eaipatterns.com/ramblings/18_starbucks.html
48、Don't Control, but Observe
[1] MDA = Model Driven Architecture
49、Janus(两面神) the Architect
This work islicensed under a Creative Commons Attribution 3
50、Architects focus is on the boundaries and interfaces
This work is licensed under a Creative CommonsAttribution 3
51、Challenge assumptions - especially your own
· "Open source is notreliable"
· "Bitmap indexes aremore trouble than they're worth"
· "The customer wouldNEVER accept a page that takes 5 seconds to load"
· "The CIO would rejectanything that isn't sold by a major vendor"
This work islicensed under a Creative Commons Attribution 3
52、Record your rationale
This documentation may come in handy in a number of situations:
However, the most importantbenefits that come from this practice are:
This work islicensed under a Creative Commons Attribution 3
53、Empower developers
This work is licensed under a Creative CommonsAttribution 3
54、It is all about the data
This work is licensed under a Creative CommonsAttribution 3
55、Control the data, not just the code
1) Create a list of scripts that need to be run, in order
2) E-mail scripts to special database person
3) Database person copies the scripts to a location where they’re executed by acron job
6) Run validation scripts and spot-check(抽查) the data
7) Regression test(回归测试) the application and seewhat blows up
8) Write scripts to insert missing data and fix blow-ups
This work is licensed under a Creative CommonsAttribution 3
56、Don't Stretch The Architecture Metaphors
Example: We'rebuilding a 'transport system like a ship travelling between a series of docks'.
This work islicensed under a Creative Commons Attribution 3
57、Focus on Application Support and Maintenance
Here are a few of the disadvantages that an administrator faces:
This work is licensed under a Creative CommonsAttribution 3
58、
59、Prefer principles, axioms and analogies to opinion and taste
· implement and adapt thearchitecture;
· extend the architectureinto related domains;
· re-implement thearchitecture using newer technologies;
· work out the detailed edgecases.
This work islicensed under a Creative Commons Attribution 3
60、Start with a Walking Skeleton
Start with a Walking Skeleton, keep it running, and grow it incrementally.
This work is licensed under theCreative Commons, Attribution 3 open source license.
61、Share your knowledge and experiences
This work is licensed under a Creative CommonsAttribution 3
62、Make sure the simple stuff(东西) is simple
This work is licensed under a Creative CommonsAttribution 3
63、If you design it, you should be able to code it.
This work islicensed under a Creative Commons Attribution 3.
64、The ROI(投资回报) variable
Thiswork is licensed under a Creative Commons Attribution 3
65、Your system is legacy(遗产), design for it.
Clarity - it should be obvious what role components and classes perform.
Testability - is your system easy to verify?
Correctness - do things work as designed or as they should? Eliminate quick andnasty fixes.
66、If there is only one solution, get a second opinion
So, the boss asked him, "Whatcan we do to improve the performance?"
My friend had the answer: "Buya bigger machine!"
"Umm... as far as I know,that's it."
My friend was fired on the spot. Ofcourse, the boss was right.
Thiswork is licensed under a Creative Commons Attribution 3
67、Understand the impact of change
Change can manifest(出现) in a variety of forms:
· Functional requirementschange
· System interfaces aremodified
· People in the team comeand go
The architect's roleis not necessarily to manage change, but rather to ensure change is manageable.
Fortunately, thereare many tools and techniques to mitigate the impact of change:
· Make small, incrementalchanges
· Build repeatable testcases - run them often
· Make building test caseseasier
This work islicensed under a Creative Commons Attribution 3.
68、You have to understand Hardware too
This work is licensed under CreativeCommons Attribution 3
69、Shortcuts now are paid back(偿还) with interest later
This work is licensed under a Creative CommonsAttribution 3 licence
70、"Perfect" is the Enemy of "Good Enough"
71、Avoid "Good Ideas"
Here are some key phrases to look for:
· "Wouldn't it be coolif …" Really, any sentence with the word "cool" in it is adanger signal.
· "Hey, they justreleased version XXX of the YYY framework. We ought to upgrade!"
· "You know, we reallyshould re-factor XXX as long as we are working on ZZZ …"
· "That XXX technologyis really powerful! Maybe we could use it on …"
· "Hey,<yournamehere>, I've been thinking about the design and I have anidea!"
72、Great content creates great systems
Analyze allavailable content and assess its value on the following criteria:
- Is there enoughcontent available? If not, how do we attain critical mass?
- Is the contentfresh enough? If not, how do we improve delivery rates?
- Have all possiblecontent channels been explored? RSS feeds, Email, Paper Forms are all channels.
This work islicensed under a Creative Commons Attribution 3
73、The Business Vs. The Angry Architect
This work is licensed under a Creative CommonsAttribution 3
74、Stretch key dimensions to see what breaks
Now take this solution and stretch the key dimensions to see what breaks.
Stretching key dimensions allows an architect to validate a solution by:
This work islicensed under a Creative Commons Attribution 3
75、Before anything, an architect is a developer
76、A rose by any other name will end up as a cabbage
This work is licensed under a Creative CommonsAttribution 3
77、Stable problems get high quality solutions
This work is licensed under a Creative CommonsAttribution 3
78、It Takes Diligence
· Embracing the budget and time constraints ofthe customer
· Performing all the work that makes thearchitect effective, not just the work the architect enjoys.
· Commitment to the process/methodology
1 Gawande, Atul. Better: A Surgeon's Notes on Performance.Metropolitan Books, 2007.
This work islicensed under a Creative Commons Attribution 3
79、Take responsibility for your decisions
How can you become a responsible software architect who makes effectivearchitectural decisions?
This work is licensed under aCreative Commons Attribution 3
80、Don’t Be a Problem Solver
This work is licensed under a Creative Commons Attribution3
81、
82、Your Customer is Not Your Customer
We cannot love our customers so much, love we not their customers more.
This work is licensed under a Creative Commons Attribution 3
83、It will never look like that
This work is licensed under a Creative CommonsAttribution 3
84、Choose Frameworks that play well with others
This work is licensed under a Creative CommonsAttribution 3
85、Make a strong business case
This work islicensed under a Creative Commons Attribution 3
86、Pattern Pathology
This work is licensed under a Creative CommonsAttribution 3
87、Learn a new language
· Eventually the businessperson finishes and looks expectantly at the architect.
This work islicensed under a Creative Commons Attribution 3
88、Don't Be Clever
This work is licensed under a Creative Commons Attribution 3
89、Build Systems to be Zuhanden
This work is licensed under a Creative CommonsAttribution 3
90、Find and retain passionate(充满热情的) problem solvers
This work is licensed under a Creative CommonsAttribution 3
91、Software doesn’t really exist
注:说明了变化是不可避免的,我们可以像创建一个静止对象一样去计划,但是当我们被要求移动对象的时候,不能感到吃惊和没有准备。
This work is licensed under a Creative CommonsAttribution 3
92、Pay down(当场支付) your technical debt(债务)
注:有时必须将变更尽可能快地商用,可能造成设计,文档,测试都很缺乏,一旦商用后,我们回来后要立刻把这些都补上去,争取在下一个发布版本中把债还了。
This work is licensed under a Creative CommonsAttribution 3
93、You can't future-proof(不会过时的技术) solutions
Today's solution is tomorrow’s problem.
注:为当前选择一个好的技术都非常困难,更不要说选择一个适合将来的。难道说架构师就不需要预见性吗?
This work is licensed under a Creative CommonsAttribution 3
94、The User Acceptance Problem
· 2. People fear new (unproven) technology.
· 3. People have cost/budget concerns
· 4. People simply do not like change.
This work islicensed under a Creative Commons Attribution 3
95、The Importance of Consommé
Thiswork is licensed under a Creative CommonsAttribution 3
96、For the end-user, the interface is the system(对终端用户来说,界面就是系统)
注:道理简单,大家都知道。但是具体做起来难,比如我们项目组能招聘界面方面的专家吗,不能,所以我们的界面只能是业余的。
This work islicensed under Creative Commons Attribution License 3
97、Great software is not built, it is grown(好的软件不是一次性构建的,而是采用渐增的方式成长起来的)
注:既不是一个大的设计,又要能进化和适应;既不是砍掉需求,也不是验证一个东西后就丢掉。这也太难把握了!看了几遍how to do this也没明白具体怎么做,呵呵!
Thiswork is licensed under a Creative Commons Attribution3
Website:http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book
《97 Things Every Software Architect Should Know》读书笔记相关推荐
- 读书笔记 | 墨菲定律
1. 有些事,你现在不做,永远也不会去做. 2. 能轻易实现的梦想都不叫梦想. 3.所有的事都会比你预计的时间长.(做事要有耐心,要经得起前期的枯燥.) 4. 当我们的才华还撑不起梦想时,更要耐下心来 ...
- 读书笔记 | 墨菲定律(一)
1. 有些事,你现在不做,永远也不会去做. 2. 能轻易实现的梦想都不叫梦想. 3.所有的事都会比你预计的时间长.(做事要有耐心,要经得起前期的枯燥.) 4. 当我们的才华还撑不起梦想时,更要耐下心来 ...
- 洛克菲勒的38封信pdf下载_《洛克菲勒写给孩子的38封信》读书笔记
<洛克菲勒写给孩子的38封信>读书笔记 洛克菲勒写给孩子的38封信 第1封信:起点不决定终点 人人生而平等,但这种平等是权利与法律意义上的平等,与经济和文化优势无关 第2封信:运气靠策划 ...
- 股神大家了解多少?深度剖析股神巴菲特
股神巴菲特是金融界里的传奇,大家是否都对股神巴菲特感兴趣呢?大家对股神了解多少?小编最近在QR社区发现了<阿尔法狗与巴菲特>,里面记载了许多股神巴菲特的人生经历,今天小编简单说一说关于股神 ...
- 2014巴菲特股东大会及巴菲特创业分享
沃伦·巴菲特,这位传奇人物.在美国,巴菲特被称为"先知".在中国,他更多的被喻为"股神",巴菲特在11岁时第一次购买股票以来,白手起家缔造了一个千亿规模的 ...
- 《成为沃伦·巴菲特》笔记与感想
本文首发于微信公众帐号: 一界码农(The_hard_the_luckier) 无需授权即可转载: 甚至无需保留以上版权声明-- 沃伦·巴菲特传记的纪录片 http://www.bilibili.co ...
- 读书笔记002:托尼.巴赞之快速阅读
读书笔记002:托尼.巴赞之快速阅读 托尼.巴赞是放射性思维与思维导图的提倡者.读完他的<快速阅读>之后,我们就可以可以快速提高阅读速度,保持并改善理解嗯嗯管理,通过增进了解眼睛和大脑功能 ...
- 读书笔记001:托尼.巴赞之开动大脑
读书笔记001:托尼.巴赞之开动大脑 托尼.巴赞是放射性思维与思维导图的提倡者.读完他的<开动大脑>之后,我们就可以对我们的大脑有更多的了解:大脑可以进行比我们预期多得多的工作:我们可以最 ...
- 读书笔记003:托尼.巴赞之思维导图
读书笔记003:托尼.巴赞之思维导图 托尼.巴赞的<思维导图>一书,详细的介绍了思维发展的新概念--放射性思维:如何利用思维导图实施你的放射性思维,实现你的创造性思维,从而给出一种深刻的智 ...
- 产品读书《滚雪球:巴菲特和他的财富人生》
作者简介 艾丽斯.施罗德,曾经担任世界知名投行摩根士丹利的董事总经理,因为撰写研究报告与巴菲特相识.业务上的往来使得施罗德有更多的机会与巴菲特亲密接触,她不仅是巴菲特别的忘年交,她也是第一个向巴菲特建 ...
最新文章
- Spring的一些资源
- 永远不要在 MySQL 中使用“utf8”
- xhtmlConformance mode=Legacy/ 致ajax失效
- 数字图像处理:第三章 灰度直方图
- 回文数的个数、杨辉三角
- 2_6 CompositeMode.cpp 组合模式
- 28行代码AC——Minimum Sum LCM UVA - 10791(最大质因子)
- 无线网的组建与应用习题参考答案
- android 自定义menu背景,Android编程实现自定义系统菜单背景的方法
- 开发们 点广告-赚点BT币
- Vue 切换路由后页面回到页面顶部
- 20150318知识小结
- 集线器,路由器,交换机的作用和区别是什么?如何区分交换机,集线器,路由器?...
- 《南明史》txt版本
- (六)WebRTC手记之WebRtcVideoEngine2模块
- linux 提取重复数据处理,Linux提取命令cut
- HDU-4324 Triangle LOVE 拓扑排序
- 小米路由器r2d_小米路由器R2D刷机变砖维修过程记录
- ROS双线做法(双电信)
- 台式计算机怎么开关网络,怎么用台式电脑开wifi_台式电脑如何开启wifi