An issue came up, a while ago, in the company I work for. The issue was that the development team was expanding. It was expanding because some of the projects got in later and more mature stages of development, which is a natural thing.
The expansion of the teams led to a interesting thing however – using SVN was becoming a pain in the ass. What do I mean by that?
Before the expansion - every project in the company had one developer who was working on it. That meant a linear development of the projects – if someone finishes a functionality, bug or feature, the project easily becomes ready-to-publish. With the introduction of more than one developer on the project - the company was able to build more than one feature per project at the same time. That process however broke the linear progression of the projects. When one person finished their feature – the second person could be half way through his, so if you need to publish the new feature you either have to wait for everyone to end their work, or hide the unfinished functionality.
I want to clarify that the way the company is using SVN is to have a folder for each project and commit your changes to that folder. A feature is a series of commits. It’s pretty standard actually and I think a lot of people use SVN that way.
In this context I began searching for solutions. And I actually found several solutions. The more interesting are:
- Introduction of branches in SVN – when you need to make a big feature – you make a branch and do the feature. Then you merge with the main branch. After a bit of research on the matter however I found that this is not such a good option. Why? Well when merging in SVN, SVN tries to clash the two versions of the file you’re merging and combine them in one. So if someone has changed that file a little bit and you changed it – you get a merge conflict. Now imagine a three or four weeks of work of one man trying to clash in three or four weeks of work of another. Disaster. This leads to the second option.
- Working with no commits. I mean you update frequently and you commit when you’re ready with your feature. However – this means no one would be able to see your progress and no one will be able to help you with the feature. Also if you do something wrong at the end of the feature – you won’t be able to ‘revert’ your mistake. And it feels wrong too.
- Use a Distributed source control system(Git or Mercurial) instead of Subversion. I knew the distributed source control systems were better, but didn’t know why actually. So I began researching on the subject and found some great articles like the one from Joel Spolsky and this question in stackexchange, and a few others.
The big difference between SVN and Git\Mercurial and the solution of our problems was in the way the two source control systems worked. SVN tracks the VERSIONS of files and when merging - tries to unite the two versions you’re merging into one. Distributed source control systems like Git and Mercurial track the CHANGES in your files and when they begin merging they try to apply and combine every change you’ve made in your file with the changes the other people made to the file. That means that in theory – if you move a method and someone else changes the method contents without moving it – the source control should be able to figure that out and give you the result – the method moved and changed – without a conflict. That makes the merging of branches possible with very few conflicts. Nice. And that enables a lot of people working on the same features and changing the same files with a little effort and less pain.
It seems using a distributed source control system means you can SCALE your development very efficiently. Very nice.
I think there may be a fourth solution to the problem – trying to implement a part of Scrum agile methodology – the Sprint. We set a target for a sprint and make changes(commits) throughout that sprint and in the end of the sprint we have a stable version of the system which we publish. However that requires significant change in the processes of the company – of how we work, communicate, estimate and plan etc. It’s a lot more work and a lot more risk associated with this option.
After all we chose to use a distributed source control system – Git and particularly GitHub. It seems to have so much less pain associated with it compared to SVN.
However there is still the price of introducing it to the whole team, importing the source code from SVN and learning how to use Git PROPERLY. After all the source control is just a tool in the toolbox of a developer. And like every tool – if you don’t use it right it could give you a lot of headaches. But I think the whole effort will be well worth it at the end.
Lately as I’ve been developing a lot and trying to remember the key combinations of Visual Studio that I use the most, so I’d make my life easier and I’d be able to increase my productivity. I try to observe – when am I reaching for the mouse? Then I try to find the key combinations which would help me use the mouse less often. In the end – every reach for the mouse wastes time and focus.
I found that a lot of times when I use the mouse I try to reach for this menu:
And naturally I tried to find the key combination to open and use it. Here comes my little disappointment. All the other key combinations I needed to find - I could find on the internet. That’s because I knew what I was looking for – the name of the window/control/functionality to open. I didn’t find the name of that component, although there are no tooltips on the dropdowns. So I thought – let’s look around the keyboard and keyboard shortcuts options in Visual studio - I should be able to find it there. And then I found that:
So much for the user-friendliness.
Anyway after a couple of minutes of googgling I found the name of the dropdown with the class names and names of methods – it’s called a Navigation Bar. Naturally.
The thing that made me sad about it was that the shortcut for it is Ctrl+F2 and shortcut goes to the classes dropdown, so if I want to go to the methods dropdown I need to click also TAB. So the whole combination that I need is Ctrl+F2(which I find a little hard to reach) plus TAB. And clicking the combination resets the ‘methods and properties’ dropdown so it goes to the first element and changes the place of my cursor on the page. It’s not a great experience and not a friendly one at all.
I did this in Visual Studio 2010 some days ago and the day before yesterday I saw Visual studio 2012 with all the shiny new things. Now don’t get me wrong I really like Visual studio – 2010 and even more 2012. I really think that the teams that made them are one of the best developers in the world and I believe Visual studio is the best development environment in the world at the moment. But I was a little disappointed that the shortcuts and the options window for keyboard shortcuts are the same between Visual Studio 2010 and Visual Studio 2012. I really think that that part of Visual Studio could be made batter.
So to be constructive I’m giving several propositions regarding keyboard shortcuts in Visual Studio:
- Create more user-friendly options menu for Keyboard shortcuts. Have links or pictures or at least descriptions with a nice search for each shortcut. I think that it’s going to make more users want to use shortcuts. Which will make users more happy and more productive.
- Make the navigation bar’s “methods and properties” dropdown a ‘first class citizen’ of Visual Studio with an own shortcut. As of now - I cannot target this dropdown directly so I should use Ctrl+F2 plus TAB to get to it.
- The more annoying problem - do not reset the dropdown to the first element when I ‘TAB’ to it. The dropdown should be able to figure out in which method in the page I’m in and not reset my cursor but navigate the dropdown to the method that I’m in.
If I think of something else I’ll update the list.
I don’t think the ideas I’m proposing here are a major change. I hope the guys behind usability in the Visual Studio team would read this post and would love to think and improve on the things I’m proposing.
Or at least that’s what I would expect from a team that’s created such a great product as Visual Studio 2012.
As a .NET developer for a couple of years, I’ve read a lot of blogs and articles on the web. A big part of them were stating how essential for an app or project is to have Unit Tests. Actually they were concordant that the definition of legacy code is code that is not being unit tested.
Imagine my amusement now when I look back at my couple of years of software development and I cannot find a single project that I worked on that has unit tests in it. Not one. I’ve worked for 3 companies on several different projects. From Business process management software to Web sites and CMS to Enterprise applications etc. I would go so far to say that I even don’t know a person who’s working in a company(I have friends who are developers), that uses unit testing in their projects. But enough of that. My purpose is not to rant about how unit testing and automated tests are not widely spread.
I want to explore the field and show the basics of unit testing, how it’s done and why it’s important.
So let’s start with the definition of Unit test.
Unit test is a small, repeatable piece of code that tests one functionality - in most cases one method. It’s not testing how functionalities interact with each other. It’s not testing the environment, database or any other environment variables. (There are other types of tests that test for that.) It’s testing the business logic of the method – “What the method does”. With unit tests all the external or environmental dependencies has to be hidden away - stubbed or mocked.
But what is unit testing as a process?
Unit testing as a process essentially is automating the validation of every piece of business logic in your application through tests.
I’m sure you’re beginning to see the value in it. You can stop being scared of refactoring some bad piece of code –small or big. Also if your piece of code is tightly coupled with some other code – it makes unit testing it very hard. Unit testing is enforcing your code to be well structured. I’m sure there are many other benefits which I’m not able to think of right now, but will come up later.
In this post I’ve made some basic definition of what unit test is and what is the idea of the process of unit testing. In my next post I’ll choose the technologies and frameworks which I’m going to make my unit tests with and I’ll also discuss why did I choose them. After that I’ll continue with some practice – creating some simple unit tests on an MVC web app.