http://www.bitnative.com/2014/01/24/where-should-a-software-architect-begin/

Where Should an Architect Begin?

Posted on?January 24, 2014?by?Cory House

Imagine you’re dropped in a new position with no one there to help provide a smooth knowledge transition. It’s like being dropped right out of the sky. That’s exactly how a new software architect felt who reached out to me with this question:

You are brought on board as a software architect in a company with products in a totally foreign business domain (to you). You are told you are responsible for working with product lines X, Y, Z. Btw, here is the code base (TFS url). Kthxbai.

Ouch. That’s an intimidating place to start. Time to figure out how to eat the elephant a bite at a time.

One obvious starting point is documentation. Well, assuming the existing documentation that isn’t horribly out of date. But properly updated documentation is rarely the case. Much like out of date comments, stale documentation can tell dangerous lies and lead you in the wrong direction altogether. So?avoid spending time reviewing any documentation alone. Having others there to vet existing documentation as you review it kills two birds with one stone. If it’s accurate, it shouldn’t take long to confirm. And if it’s a dusty mess, now’s the time to have the conversations necessary to get the house in order.

I would move on by reviewing the codebase at a high level. Where is it stored? What technologies are utilized? What skeletons are in the closet that are immediately obvious? But don’t spend too much time exploring on your own just yet. There’s a more profitable and enjoyable option:?buy chicken wings and beer. Get your fellow geeks and business folk out of the office and start picking their brains in a casual atmosphere. Bring some paper so you can sketch down notes as you strive to understand and document the system.

To help drive your initial goals, consider the areas of the application that you seek to manage and improve as an architect:

Security

Reuse

Duplication

Separation of concerns

Code quality

Test coverage

Build process

Consistency

Performance and scalability

What do people love? Hate?

Prioritizing these areas will focus your conversations, questions, and any documentation you decide to generate. Sure, the problem is feeling like the domain you need to learn is too big. Having a standardized list of questions to ask helps drive discovery. However,?consider exactly what actions you plan to take based on the answers. This will cut the fat on your list of questions and maximize the signal to noise ratio in conversations. Having a finite set of areas you seek to improve initially will focus conversations and lessen the pain of your initial learning curve.

There’s no easy answers when you’re trying to bootstrap in a situation like this. But organization and clear short-term goals combined with out of the office time to help gain the necessary candor can help make the transition process more profitable and enjoyable for all.

轉載于:https://www.cnblogs.com/davidwang456/p/3535550.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Where Should an Architect Begin?--reference的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。