Hot answers tagged

112

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 ...


95

So I don't waste much time on writing super clean code at that point because I never know how long something lasts. Not knowing how long something lasts should never be an excuse for sloppiness - quite the opposite. The cleanest code is IMHO the one which does not come into your way when you have to change something. So my recommendation is: always try ...


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 ...


51

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. ...


21

You have two separate problems, both with the same symptom (sloppy code): Problem #1: Insufficient requirements control I don't mean that your stakeholders change your requirements too frequently, I mean that you're allowing requirements changes during a bugfix/test cycle. Even the agile methodologies don't support that; you build, you test, you deliver, ...


20

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 ...


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 ...


20

It is a common problem - especially when crafting what is essentially a software trial balloon as it were. There are a number of approaches that can help. Firstly TDD approach can help to reduce the code base to that which is strictly required. If your tests go hand in hand with your code, then you can at least have some confidence that your code behaves ...


18

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 ...


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 ...


14

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 ...


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. ...


11

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 ...


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 ...


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

The problem seems to be to me that you have a single QA branch. For each release, make a separate QA branch from the primary development trunk/master. Then merge in only fixes for bugs for features on that branch - never new features. Have QA test that branch. This way, the "freeze" is quite evident- it's in the branch name. You could use something like, I ...


9

Continuously Speed of development is the main reason to write clean, readable and testable code; it's not done for beauty, nor other abstract values. Why would I deny that to myself and only do it afterwards for some future programmer? Sure there might be changes that are mostly cosmetic and therefore not essential; I'd argue that it's far more useful to ...


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. ...


7

You are one person working on internal software and don't follow any specific formal process yet. There isn't really a name for that other than "programming", in my view. If you want to work more professionally (because stakeholders want to know when things are done, for instance), the first things that should be in place are: Source control. Use it for ...


6

What's the worst that could happen? Do you have backups that are good enough so that a bug modifying random records in your database can be fixed by restoring an old version? Let's say you have a bug where you use a record id, and by mistake the amount of a bill in cents is stored in a variable used for the record id. So if I pay $12.34 then the record ...


6

React is using a functional approach for creating interfaces: given some state, it produces rendered page fragments using only pure functions. Aside from technical details (like its virtual DOM), there's nothing special about that. In languages like Haskell it's the most natural way to do that, and it's just about that time when guys from JS community ...



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