106
Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least ...
83
Instead of having two code version with a common base you should design your application in a way to make those premium features plug-able and driven by configuration rather than different code bases.
If you are afraid to ship those premium features (disabled by configuration) with the basic version you can still remove that code in a final build/packaging ...
62
One thing I've realized in my career is that there is always time to do it right. Yeah, your manager might be pushing. The client might be pissed. But they don't know how long things take to do. If you (your dev team) don't do it, it's not getting done; you hold all of the leverage.
Because you know what will really cause your manager to push you or your ...
39
I strongly recommend not using branches for this purpose. In general, you should consider branches for things that will be (or might be) merged back together again later (or for release branches, where you eventually stop development of one of the branches). In your case, you will never merge your "basic" and "premium" versions together, and they will both ...
32
From the Git SCM Book:
Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.
Stashing takes ...
30
For many (perhaps most) individual developers working on their own, creating pull requests is probably not worthwhile. However, I can think of at least one potential reason to do it:
Pull requests can be used to keep track of your project history more easily. A pull request has an issue ID which can be referred to from commit messages and in a change-log, ...
30
He's mostly referring to the feature branches side of the model. Feature branches were declared an anti-pattern a long time ago when the branches lasted for months and version control systems couldn't merge to save their life. Feature branches that last a week or two have much fewer issues, especially if you're continually merging from develop into the ...
23
You should certainly consider splitting the product into modules with interface team(s) bringing those constituent modules together into a product. This in turn would mean splitting the repositories to match the module partitioning and hierarchy. If it appears that you can't do this then the project will probably grind to a merge-induced halt considering ...
22
This is a wonderful idea, with one caveat. Don't replace developer written tests with reviewer written tests. Have your reviewers look for corner cases and inputs that will break the code. In other words, have them try to write new tests that the original developer didn't think to write.
Writing characterization tests is an absolutely wonderful way to gain ...
21
This boils down to what I've started thinking of as "The Eternal Conflict" (between business and engineering). I don't have the solution as it's a problem that never goes away but you can do stuff to help mitigate.
Communicate Value
What people often don't realize is that as engineers we're just assuming the problem of "successful business" is always a ...
21
Merging is a funny thing - the less frequently it's done the harder it will be, the harder it is, the more people will be afraid of it, the less frequently they will do it.
Solution is either do not allow branches to deviate too much, or not to use branches.
If people understand this, you will probably have not much problems with merge, if not - may be ...
21
Should I commit the test before writing the class even though the test doesn't even compile? Or should I stub out the minimum amount of code that is needed to get the test to compile before committing?
Of course not. You should finish both the test and the class. Committing something1 that doesn't even compile makes no sense, and will certainly make people ...
19
There is only one solution. Reserve around 10-20% of project/work time for refactoring. If it's difficult to convince the management that it is a justifiable task give them the only real argument: without refactoring the cost of code maintenance will grow exponentially over time. It's good to have a few metrics/articles/research results to back up this ...
18
I don't think the idea is entirely without merit - however, the main benefit of the TDD et al is that problems are found early. The developer is also best placed to spot which corner cases may require specific attention. If this is left until the code review, then there is a risk this knowledge could be lost.
Writing tests during the code review would ...
16
I like the git flow branching model. The master branch is left alone most of the time, it only contains releases. The develop branch should be stable at all times, and the feature branches can be broken.
You can also combine this with continuous integration by merging develop into your feature branch and your feature branch into develop. Of course you ...
15
Correct: a pull-request is linked to a branch in your repository. If you modify the branch, you are then also modifying what you're submitting as a pull-request.
So yes, you do have to create a branch (and pull-request) per bug fix. It might be wise to start with one and see how the maintainer reacts to that one before going on to do the rest. Open source ...
14
I deal with both of your proposed solutions daily. There are two key concepts to handling them well.
Use topic branches. I believe production history should be pristine. As a result I spend a great deal of time making my production branch's history logical, replicable, and debuggable. When using multiple machines, however, you occasionally need to commit ...
14
The idea is actually very nice. Contrary to common workflows, you keep the review directly in code, so technically, you don't need anything but text editor to use this workflow. The support in the IDE is nice too, especially the ability to display the list of reviews in the bottom.
There are still a few drawbacks:
It works fine for very small teams, but ...
14
There might be several issues which are the cause.
Potential root causes
The classes are too generic/too large.
If there is a class Utils, there are chances that it will grow over time. By laziness, everything which doesn't obviously belong to another class would be put in this one. For example, if somebody writes StringToByteArray method, why bothering ...
14
Whenever you have time for doing something right, use it - write the best code you can, and improve it steadily. Don't make your job harder by beeing sloppy and introducing technical debt when there is no need to.
Emergency calls for fixing a severe bug are no things you can control by yourself, when they occur, you have to react ASAP, that's life. Of ...
14
I'd personally go for many small libraries.
Discourages developers from creating dependencies between otherwise unrelated packages.
Smaller more manageable libraries that are much more focused.
Easier to break up and have separate teams manage each library.
Once you have a new requirement that's sufficiently complex, its better to add a new module
rather ...
13
Since it's all new code, I would tend to go with #1 because the commit history of the old project is really irrelevant. But it would be nice to add something to the README along the lines of, "Based on an idea from ....".
I'm a big fan of acknowledging where we (or our algorithms) came from. If you look back into the mists of history, you'll see that we are ...
12
Let the developer who went for a couple of months without merging fix it. Maybe they can get one big chunk of code to merge, maybe they can get a bunch of little chunks to merge one at a time. In any case, they should be doing the legwork to fix the problem, since they caused it.
What is the best way to deal with such a situation where one branch is ...
11
You're some of the way there, but I'd expand your diagram somewhat:
Basically (if your version control will allow it, i.e. if you're on hg/git), you want each developer/dev pair to have their own "personal" branch, which contains a single user story they're working on. When they complete the feature, they need to push into a central branch, the "Release" ...
11
I see my job as providing the best quality software that is possible within the time constraints allowed for the project. If I am concerned that the level of quality will be low, then I will engage the project owner. I describe my concerns and discuss the potential risks of deploying the software in that state. One of 3 things will happen at this point:
...
11
Why don't you use git locally to share your code with your three development machines/environments, and then just use SVN to do the commits that go to the rest of your development team.
This way, you can use git without locally without making the rest of your team use it.
11
The issue might also lie in a too rigid separation of task between back-end and front-end development.
If a front-end developer need a new API, isn't it possible to allow him or her to create a dummy API on the back end (returning always the same value for example) to validate the layout ? Then commit that partial implementation with a stub, and in a ...
10
A simple workflow.
Central Git Repo used by the CI server
People push to a specific branch on that Repo (say Master)
CI Server detects changes in master branch or runs a timed build
CI Server runs unit tests
Depending on your rules, the CI server can
then tag the repository, and a myriad of other things.
There are countless ways to do this, do what ...
10
Pull requests are created so someone can review the work, make comments, suggestions, make or request edits and then merge the code to master.
In your case the someone is you.
As the sole developer you still should review your own work, refactor it and merge it to master when ready.
One approach I use a lot is to try to 'put on another hat', 'try other ...
10
There's no way to accurately do this. For example, who contributes more: someone who commits 1000 lines of code in a month, or someone who spent most of his time thinking really hard, and then committing 100 lines of code that replace the 1000 lines of code? Or how about somebody that goofed off most of the month, then found those same 100 lines of code in a ...
Only top voted, non community-wiki answers of a minimum length are eligible
