Working with Azure Functions in Visual Studio Code like a boss

So after a while I decided to finally check Azure Functions extensions out in Visual Studio Code. I often want to check something really quickly and being forced to open Visual Studio each time makes me furious. I must say that initially I was a bit skeptical regarding Code functionality, but it turns out to be superb. Let's check what it offers for now.


Installing the extensions is super easy. Just go to the Extensions menu and search for Azure Functions:

Once extensions is installed you can easily disable or uninstall it

For now - that's really all!

Creating a function

With Azure Functions plugin installed you should be able to see available subscriptions in the Explorer area. If not left-click on the status bar where your username is displayed and select the ones you're interested in:

Workspace with only one subscription selected


Installing the extension gives you some more features. Now you're able to work with a project, create a function and publish it. Let's start with a function triggered by a HTTP request. Click on "Create New Project Button":

Now you're able to select a current location or create a new one where your project will be placed. Once you're satisfied you can select a language and... that's all, your workspace is ready to start working on a function.

Empty Functions project ready to rock!

Now let's create a function. You can create in in a similar way as a project. After providing all necessary data(like a name, a type of trigger, security level), a template will be created so you can start modyfing it as you wish.

A template, very similar to the one created in Visual Studio

Running a function

You can easily start testing your function by pressing F5. It'll start runtime and you'll be given an endpoint, which you can call anytime:

Publishing a function

Publishing a function from Visual Studio Code is as easy as other tasks. Once more go to the Azure Functions workspace and select "Deploy to Function App". You'll be asked about many different parameters like a subscription, resource group or storage account. Once everything's configured wait a second(or maybe two) until a function is published. You can start using it!

Function published along with a storage account and consumption plan


In the current shape VS Code will not replace full Visual Studio(at least for me personally), but I found Azure Functions extension extremely helpful in the smaller projects, which are developed fully in Code. If I don't have to switch between IDEs, I'm more than happy. 

Do it only when you need it

Writing good quality code is somehow jumbled and not an easy task to do. To be honest, it's a matter of your experience - the more code you write, the easier is to make it reusable and easy to understand. As a beginner I tended to write many layers of abstraction, which were supposed to separate all the concerns. At least it's something many books and tutorials for "rookies" say - create a lot of abstraction, use this, use that - it will help making your code maintainable. To make a long story short - it's a complete bullshit.

The more abstraction you introduce in your code, the harder it is to understand it. You can divide your 50 LOC method into three different ones, which JIT compiler will inline anyway - but is it something you're doing because you know it's the right thing to do? You can introduce all those builder, singleton, abstract factory patterns - but are there any evidences you're delivering any value to the codebase? In most cases we're doing something because a mysterious man - the author of the most popular C++/C#/Java book - said so. We're building the foundations of our skills basing on fairy tales, which are completely irrelevant in a real world.

Very few people proclaim a very easy and straightforward rule - do it when you need it.

The rules are simple. Don't introduce a pattern if don't need it yet(and never introduce it, if you don't understand it). Don't introduce an abstraction, if you're not sure what your code is going to look like. Don't divide your methods or classes just for a sake of dividing them. Whatever refactoring you're about to do - do it only if you need it.

I believe this is from all the misunderstanding of TDD comes from - people have learned, that they should refactor their code always, no matter how it looks like. They forget, that they should use their intuition rather than blindly following all the rules.