Since a view is a definition of a query, but is not the actual query that is run when the view is accessed, tuning a view is quite difficult. For example, Let's say you have a view that accesses five tables. You run a query against the view that pulls columns from only two of those tables. The optimizer does a thing it calls simplification. It tosses the tables it doesn't need to satisfy a query, so if you look at the execution plan for the query, you'll see that only the two tables needed are accessed (just an example, it could have to access three of the tables, depending on the foreign keys, etc., you get the idea).
The single most important thing you can do for views is do not, DO NOT, nest them, meaning, put views inside of views. Also, do not, DO NOT, join views, meaning, treat views as tables and start joining them together. These two common code smells lead to all sorts of major performance issues because you're demanding the optimizer to unpack increasingly complex queries (the five tables of this view, the five tables of that view, and the five tables of the third view, some of which overlap, some don't, some are being accessed, some aren't, etc., etc.).
Remember, above all when dealing with views, views are just a query. They do not define data storage. That's what tables are. Further, the view definition is not necessarily how the optimizer is going to see things.