Hot answers tagged

113

Automation. When you are developing, only in the most simple projects will the default "build" button do everything you need it to do; you may need to create WS out of APIs, generate docs, link with external resources, deploy the changes to a server, etc. Some IDEs allow you to customize the build process by adding extra steps or builders, but that only ...


85

You need a proper Quality Assurance (QA) process. In a professional software development team, you don't push from development right to production. You have at least three separate environments: development, staging and production. When you think that you got something working in your development environment, you push to staging first, where each commit is ...


50

You will probably want to get a dev server, and preferably a staging environment too. Nobody should ever be pushing from local to production except for their own personal website. Your deploy process should only support dev->staging->prod. You probably want someone responsible for signing off new releases - depending on the organisation, this can be a ...


32

Like code, a build script is executed by the computer. Computers are exceptionally good at following a set of instructions. In fact, (outside of self-modifying code), computers will execute the same sequence of instructions exactly the same way, given the same input. This delivers a level of consistency that, well, only a computer can match. By contrast, ...


28

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team ...


27

It sounds like you're already doing due diligence. But ... At the most practical level, always include a good handful of both "full-loop" integration tests in your suite for your own code, and write more assertions than you think you need. In particular, you should have a handful of tests that perform a full create-read-[do_stuff]-validate cycle. ...


20

As noted in the comments, size of the binary could be very important for some embedded systems - especially old ones. However, as you've noted in the update to the question There is no customer or product driven arguments for it. It is a big server that is installed as singleton of a dedicated machine, where the executable size is completely ignorable ...


19

At work, we avoid this by using Gerrit. Gerrit is a code review system that acts as a gate to your main/production Git branch which is conventionally called "master". You have code reviews, right? It sounds like you personally do them exceptionally. With Gerrit, you push to a sort of staging branch which, after you and your coworker have executed the code ...


16

For a team of 3-4 devs, you're proposing WAY too many branches. Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost. Keep in mind that the only real benefit to a branch is code isolation. ...


16

Here's an example that uses Java. It's been a while since I've used log4j, but from what I remember, the whole log4j logging tool would initialize from an XML file. The XML file itself could contain multiple loggers with different configurations(where you write to, what levels are written, etc). So, in this case you would have logger objects rather than ...


16

I see this as a largely human problem - the process is there and the tools are there, but the process is just not being followed. I agree with what others have said here, about the possibility that it's quite possible the developer in question is just stuck in an SVN mindset, and may well think that he is following the process. I find that the best way to ...


15

If all you ever want to do is <compiler> **/*.<extension>, build scripts serve little purpose (though one can argue that if you see a Makefile in the project you know you can build it with make). The thing is - non-trivial projects usually require more than that - at the very least, you'll usually need to add libraries and (as the project ...


14

Git tags are what you really want to use to designate releases. The reason is that they have meaning to you and can be used to quickly recognize the linkage between the state deployed code and any information that the build server may have (such as build number). While that is the answer you are looking for, it only solves half the problem. The other is ...


13

Many IDEs simply package up the commands used to build something and then generate a script and call it! For example, in Visual Studio, you can see the command-line parameters for a C++ compile in the 'command line' box. If you look closely at the build output you'll see the temporary file that contains the build script that was used to run the compile. ...


12

Your concerns are extremely valid. Especially the first two points about Team A not having the time to add features or fix bugs that impact Team B. I've seen this happen at my own job quite a few times. This might be a good idea if: It is known that Team A will be working on the projects that require new features in the database, while Team B's goal is ...


11

One basic rule of source control is that you need only to put manual written artifacts into the repo (the original source files), everything which can be "compiled" or "generated" does not need to be stored there, because it will produce redundancy. One can (optionally) store intermediate outputs/parts of a build process in a repo (sometimes also called ...


11

Short answer: It's hard. You're probably feeling like there are no good answers, and that's because there are no easy answers. Long answer: Like @ptyx says, you need system tests and integration tests as well as unit tests: Unit tests are fast and easy to run. They catch bugs in individual sections of code and use mocks to make running them possible. By ...


10

This is not uncommon, particularly in small teams. Don't make a big deal about it, but make an informal rule: Break the build, bring in donuts. Either 1) You'll get donuts twice a week or 2) they will adhere to the standard. Bring it up in a meeting. Not accusingly, don't mention anyone by name, but something similar to, "Since we introduced version ...


9

I think your summary have over-simplified the blog post somewhat. :p I'm going to pick out three sentences, which I think is crucial as to explaining why code became... lava. The code gen system had somewhat broken down after Bruce had left. None of the remaining team really understood how it worked, so it was easier just to modify the code by hand. ...


9

make is a lot easier to remember and type than gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h And projects can have very complex compilation commands. A build script also has the ability to only recompile the things that changed. If you want to do a clean build, ...


9

There are a few problems floating around in this that are causing issues that you are experiencing. The first is the long running QA branch. Having a long running branch that is parallel to the development mainline may as a source of confusion because there are different efforts that need to be replicated in both the QA branch and the mainline. This means ...


7

You mean, aside from the whole "giant production bugs leads to QA people getting fired" invested? At least in some companies I've worked, QA served as second tier technical support. They would get called alongside (or before) developers if an issue appeared in the field, since they often had a better grasp on the quirks of the shipped product than ...


7

and don't want to ask the individuals doing the work to manually record things like how long it takes them to perform a given task Here's the problem. You basically want to create meaningful metrics, without measuring the only thing that matters. Nearly all of your users won't care about how fast the code itself is unless it causes a noticeable impact ...


7

Now, how can I force them... Instead of forcing your colleagues, try making them see things from your perspective. This will make things much easier for everyone. Which leads me into... I want this behavior to be punished in some way or make it unpleasant as much as possible. Why is it a pain for you with problems on the live server, but not for ...


7

I updated the version of the library … which … caused timestamps (which the third party library returns as long), to be changed from milliseconds after the epoch to nanoseconds after the epoch. … This is not a bug in the library I strongly disagree with you here. It is a bug in the library, a rather insidious one in fact. ...


6

Short answer: No. Longer answer: If your refactorings are truly improvements, then you're engaging in Codependent behaviour - you're supporting your collaborator's bad habits & not giving him/her the opportunity to improve. If your refactorings are trivial, then you're probably wasting your time and/or risking the possibility of falling into an edit ...


6

This is very Android/Gradle specific but you could define the keys in your global gradle.properties file located in user home/.gradle/. This is also useful as you can use different properties depending on buildType or flavour i.e API for dev and different one for release. gradle.properties MY_PRIVATE_API_KEY=12356abcefg build.gradle buildTypes { ...


6

Several ideas. Although I am not very sure how generally applicable they are. First, in a lot of articles that reference this anti-pattern, the first advice is to resist the urge. One way to resist the urge is to understand the Dunning Kruger effect, and to spend time exploring whether the urge to refactor could have been influenced by the lack of ...


6

When releasing a new version of a program is it better to include the full changelog since the beginning of the project or just the part since the last release? Neither. Only provide the relevant, bigger changes that an end user is going to care about. No one cares about the fact that you refactored class Foo so that it can be re-used a bit more ...



Only top voted, non community-wiki answers of a minimum length are eligible