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


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


29

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


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


21

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


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

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


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


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

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

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


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


6

This is pretty vague, and the author doesn't give any specific guidance. I'm pretty sure he does not mean coding by implementing one design pattern after another. I think he means that it is often easier to write the general case than the specific case. Here's a recent example from my own work. We are processing data from an external source. There are ...


5

Is such practice common, or it implies I am not competent? Those are not mutually exclusive. The pattern could be common, and you still might be incompetent. Your competence can be determined by measuring your performance against your goals. Are you meeting your goals? Is this pattern common? Unfortunately, yes. Many people dive into projects with no ...


5

It helps to prevent the developers/contributors from wasting their time on issues that nobody cares about. If nobody "has the exact same Wine version, specs, application and manages to reproduce the problem" then it's probably not really an issue. The developers probably don't really care if the problem was fixed, they only care if it still affects anyone. ...


3

Unfortunately, there's not really much you can do about this at the point of code review other than get another cup of coffee. The actual solution for this issue is to address the technical debt you've accumulated: fragile design, lack of tests. Hopefully, you at least have some sort of functional QA. If you don't have that then there's always praying ...


3

If you're not content to ship with buggy/non-functioning software and fix it later, then V&V effort SHOULD be longer than development effort! If existing code is fragile, then a first question is "should you even be changing it?" Management need to make a call on whether the cost/risk of redesigning and reimplementing this code is greater than the cost/...


2

Most programs have patterns of code that will be required several times, possibly with variations. If you can write code to handle the pattern, you greatly simplify development as you don't have to rewrite similar code. Consider these examples: An application reads and writes text files at several points in the execution. You have couple of options: ...


2

Yes, an agile approach could help you get the work done1. At its core, scrum provides a way for a group of motivated individuals working together to deliver a product. Scrum provides a framework for breaking a larger body of work into smaller pieces (epics, stories, tasks) and then working on those smaller pieces. Scrum also provides a framework for the ...


2

Time, budget and scope Every project, whatever life cycle approach it uses, has to cope with the triple constraint of cost, time and scope. In your case time and scope are fixed. You say nothing about cost, but as you've inherited this project from your partner, I fear that there might be a fixed (or at least capped) cost as well. The unexepcetd risks ...


1

The people who are paying decide what happens. If this is an open source project run by volunteer developers the developers decide. If this bug hasn't been reported again then there is nobody who will notice when it's fixed. So it's pointless to waste time trying to fix it. At least nobody's going to waste their time to do what you want.


1

Remove distraction? There are some issues (not necessarily bugs?) that are really minor, and most people simply don't care about it (that's why it existed for such a long time!). In a large list of issues, such minor issues may simply get forgotten. Sometimes it may even have been fixed without anybody noticing. After all you can still reopen it if you think ...


1

You already have some great answers but your question brings a few things to mind that I thought I would try to touch on. As you noted running into changes down the road I'd suggest thinking about how things impacted your project and how you could have minimized the impact with design/coding choices while at the same time generating a mental map of where ...


1

I'd like to add a few pointers 1) I personally found it incredible useful to start with visualizing stuff. Draw boxes, arrows, lines ... Never mind whatever modelling language you use. In the first place you are doing it FOR YOURSELF. It should help your flow of thoughts. 2) Find a sparring partner - grab a coffee and the flipchart/diagram etc from above ...


1

I think its safe to say you're not so far off from a better way of working, and you're not the only one in this boat. What I think you're missing is that, although you determine what you want, you don't stop to do the same process for how you'll do it. This step of stopping and thinking about how to tackle the problem overall is called design, its the step ...


1

From the cited article, an elite developer Writes code for patterns, not specific instances – it’s an intuitive skill that can’t really be learned, in my opinion. You either have it or you don’t. Really talented developers infer the patterns in a system, even before a module or a piece of code is written and they code for those patterns, rather than ...


1

The wording in that article is quite unfortunate, because it could be interpreted to mean "find well-known software patterns, and stitch them together to create a working application." That is an approach commonly used by inexperienced developers, and it works, provided you understand the patterns, how to apply them properly, and what their appropriate use ...


1

I don't know why it hasn't been mentioned yet, but these 2 are the most important pieces: You split up the changelist into multiple smaller changelists, which you then review one after another.* If the review of a changelist doesn't result in a decision that the changelist seems to be good, you obviously reject the change. *Example: You replace library ...


1

From my experience, I would strongly recommend you to cover your code with a fair amount of tests, both unit and integration, BEFORE any changes are made to the system in question. It's important to remember that nowadays there's a very good number of tools for that purpose, doesn't matter the language you're developing with. Also, there's THE tool of all ...



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