Hot answers tagged

276

The premise of the question is, frankly, astounding. We suppose that there is a large change to fragile, complex code, and that there is simply not enough time to review it properly. This is the very last code you should be spending less time on reviewing! This question indicates that you have structural problems not only in your code itself, but in your ...


96

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


91

One of the primary goal of a code review is to increase quality and deliver robust code. Robust, because 4 eyes usually spot more problems than 2. And the reviewer who has not written the additional code is more likely to challenge (potentially wrong) assumptions. Avoiding peer reviews would in your case only contribute to increase fragility of your code....


68

The cycle you describe is normal. The way to improve things is not to avoid this cycle, but to streamline it. The first step is to accept that: It's near impossible to know everything on day one of a project. Even if you do somehow know everything, by the time you've finished the project then something (the client's requirements, the market they're in, the ...


30

Welcome to the world of legacy software development. You have 100s of thousands, millions, 10s of millions of lines of code. These lines of code are valuable, in that they produce a revenue stream and replacing them is infeasiable. Your business model is based off of leveraging that code base. So your team is small, the code base is large. Adding ...


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


25

The goal of Repl>it is to write and share short snippets of code. For instance, you may use it to illustrate your point when discussing a particular aspect of your favorite programming language with other programmers, or you may use it to sketch some code in a few minutes. Repl>it is not intended to actually write and maintain codebase of any size, not even ...


24

Solve the larger problems that are causing code review to be too hard. The ones that I've spotted so far: No unit test suite Complex code merges that could be avoided by more sensible code structure and delegation of coding duties An apparent lack of rudimentary architecture


22

If you have fixed scope, and a fixed deadline, then the only thing you have left to play with is cost. You can throw more people at the problem (which doesn't really work), you can buy premade software, or you can sacrifice quality. ...Or you can change peoples' minds about the fixed scope or fixed deadline thing. That's not an agile problem, that's a ...


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

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


17

This is clearly a misunderstanding, the author does not mean "pattern" in the sense of "GOF design pattern". He does not even talk about "patterns in your code", but patterns in the problems you are going to solve with your code. So to express his recommendation in other words: one should try to write code which solves a whole category of problems instead ...


14

In this situation, the amount of time it would take to verify the safety of the changes, absence of regression, etc. is excessive. Code reviews shouldn't be primarily aimed at correctness. They are here to improve code readability, maintainability and adherence to team standards. Finding correctness bugs during a code review is a nice byproduct of ...


14

This is normal. You can take one of two approaches: Welcome Change If you assume that you will get it wrong, you must build a code base that is open to change. Mostly this involves taking the code at the end of a book on refactoring, and building your code that way from the start (decomposability, good test coverage, ...). Avoid Change In this case ...


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


11

There is nothing that can guarantee that the code is compatible with a platform other than building it, running it, and testing it there. Therefore, the approach of all sane people is to build, run and test their application on every platform that they project it will need to be built, run, and test on. Continuous Integration (CI) can ease this burden a ...


11

Creating portable code can be very challenging. First some obvious language related advices: use standard C++ and avoid carefully any undefined behavior rely primarily on standard library (and portable libraries such as boost) always include all expected headers. Do not assume that you don't need a header because it's included in another one (i.e.on ...


11

You can send the code review back and tell the developer to break it up into smaller, more incremental changesets, and submit a smaller code review. You can still check for code smells, patterns and anti-patterns, code formatting standards, SOLID principles, etc. without necessarily going through every detail of the code. You can still perform tactical code ...


11

If you think that the code review is too hard, because it changed brittle code that is near impossible to change without breaking it, then you have a problem. But the problem is not with the code review. The problem is also not with unit tests, because brittle code cannot be unit tested! If your code was unit testable then it would have been split up into ...


11

Software development has been described as a series of inherently "wicked" problems. Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it*. This paradox implies, essentially, that you have to "solve" the problem once in order to clearly define it and then solve it ...


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


8

Yes, this is common, except maybe for the "rewrite most of the code" part. You'll never get all requirements right from the beginning, so it's important to deal with change well. That's what the concept of "code maintainability" is all about. Of course it also helps to spend some more time on getting the requirements and design right. First, think of what ...


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


7

If you are asking for "development processes" and you primary development platform is Windows with Visual Studio then I would suggest to try building your project without "windows.h" included. You will get a lot of compilation errors that will point you to many places where you'll need to refactor your code. For example, 'DWORD' won't be #defined and you'll ...



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