Based on the general suggestions you're making, no. What you're suggesting is referred to as Nested Views. It's a common code smell that leads to quite a few problems. The principle issue being that a view is just a query. It's not a materialization of the data or anything like that. So you'd be taking a potentially complex query, putting it into a view, then combining that complex query with other complex queries in other views. The query optimizer basically gets overwhelmed trying to sort out all the pertinent objects and you end up with really poor performance because of bad choices by the optimizer.

The better choice is to write each query as itself without attempting to reuse code through views. As much as that seems like how things ought to be done, it just isn't how it works best within SQL Server (or Oracle or MySQL and I suspect, but don't know, Postgres).

To identify slow running procedures, the best approach is to use extended events to capture the query metrics. You can use the output from there to group queries by execution count, resource use, run-time, etc. to identify which ones are the worst performers. If you have individual statements you need to identify within a given query, again, extended events is the way to go. Once you identify the query in question, you look the code and the structures, statistics and execution plans, to understand what to do to fix it.