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 ...
81
Split work into separate commits. You've probably many times opened a file to write a single-line fix, but at the same time you spotted that the formatting was wrong, some documentation could be improved, or some other unrelated fix. With other RCSs you'd have to write that down or commit it to memory, finish the fix you came for, commit that, and then ...
65
One of the benefits for me is the ability to "add" files progressively. Before committing I review each file. Once the file is reviewed, I add it. When I git status or git diff, git shows me only the files that have been modified and have not been added yet. When I have reviewed all the files and added them, then I can commit.
So yes, I find the staging ...
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 ...
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 ...
30
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 ...
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 ...
26
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
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-...
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
The benefit is quite simple: it gives you full control over which files you want to commit when. For that matter, you can use git add -p to control which lines you want to commit.
21
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. ...
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 ...
20
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 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 ...
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
I use a combination of Git for git repositories and Unison for everything else. I have several unison profiles so I can sync specific things, and one that syncs everything. I also have a bash script that goes through and syncs all the things unison syncs then goes through and updates all my git repositories.
Unison is the best thing in my mind when it ...
15
Dropbox
For syncing files, it is as easy as working on them within a folder that DropBox knows about. The video on the main page does most of the description, which is why I didn't comment on the features. Simply modify a versioned file and DropBox will upload it automatically, then all other machines with DropBox will automatically download the latest ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
