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 ...
90
Is there a point at which the process gets in the way and becomes an end unto itself?
Heavy processes are common, unfortunately. Some people - especially management - religiously imagine that processes produce products. So they overdo the processes and forget that it's really a handful of hard-working, smart people who actually create the products. For ...
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 ...
31
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
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 ...
28
The idea of VERSION CONTROL (misnomer: source control) is to allow you to roll back through history, recover the effect of changes, see changes and why made. This is a range of requirements, some of which need binary thingies, some of which don't.
Example: For embedded firmware work, you will normally have a complete toolchain: either a proprietary compiler ...
27
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, ...
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
A workflow engine is useful when you need to go from a start to a finish but there are many different paths/logic/rules to get there.
For example, let's say I write a program that publishes content. So, in my case, the publishing goes through a review process, legal, and then final approval. I write up the program implementing my process logic and steps. ...
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
Companies typically suffer from what I'd like to call the Control-Flexibility dilemma. The less rules, structures and bureaucratic overhead the easier and faster it is to accomplish things (it's also more fun). However, it is equally easy to do "bad" things as "good" things. That means you're only fine when you have skilled employees which make few non-...
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
I know you asked for use cases, but it's easier to list the advantages than to imagine all possible use cases. The advantages of course depend on the engine and language you are comparing, but in general:
Keeping rules as data instead of code means you don't have to recompile, so you can test changes quickly, change at run time, etc. Not much of an ...
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
Neal Ford argues in The Productive Programmer that you should keep binaries in source control:
Why keep binaries? Projects today depend on a swath of external tools
and libraries. Let’s say you are using one of the popular logging
frameworks (like Log4J or Log4Net). If you don’t build the binaries
for that logging library as part of your build ...
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 ...
17
There is only one valid reason for such style of development: the software developed is absolutely mission-critical and must not, under any circumstances, contain any bugs. Think jet engine fuel injection firmware in passenger planes, or heart pacemaker firmware, or nuclear missile launch system.
In all other situations the cost overhead will kill the ...
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
This question really contains two questions, which need to be addressed separately:
Why do some teams have a strict development process?
The simple answer is because if they don't, mistakes happen. Costly mistakes. This is true for development and it is true for the rest of the IT field as well (sysadmins, DBAs, etc.).
This is very hard for a lot of ...
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
With distributed SCMs like git or mercurial (which is what bitbucket uses), branching is still possible but often unnecessary. What you do instead is (basic workflow):
Set up a repository in a location that is accessible for all developers (a network share, a server that people can ssh into, a third-party service like github or bitbucket). This will be your ...
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 ...
13
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 ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
