308

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


259

There are a few reasons. Nobody reads documentation. Nobody follows the documentation even if they do read it. Nobody updates the documentation even if they do read it and follow it. Writing a list of practices is much less effective than creating a culture. Coding standards are not about what people should do, but are about what they actually do. When ...


245

Even though I use Git on the command line – I have to agree with your colleagues. It is not sensible to squash large changes into a single commit. You are losing history that way, not just making it less visible. The point of source control is to track the history of all changes. When did what change why? To that end, every commit contains pointers to ...


183

Good answers so far, but they don't cover all the bases. In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living. BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...


179

How can I justify and defend the thesis that: The merge button should be enabled by default The code review should be a recommendation , but not mandatory The code author should have the right to merge the code within 6 hours lets say of the pull request creation no matter if there is aproval or not. I don't think you should try and justify any of those, ...


166

You have to be pragmatic. If the error is unlikely to be triggered in the real world and the cost to fix is high, I doubt many people would consider it a good use of resources to fix. On that basis I'd say leave it but ensure the hack is documented for you or your successor in a few months (see last paragraph). That said, you should use this issue as a "...


138

I am a part-time programming teacher at a local community college. The first course that is taught at this college is Java Programming and Algorithms. This is a course that starts with basic loops and conditions, and ends with inheritance, polymorphism and an introduction to collections. All in one semester, to students who have never written a line of ...


131

Don't put your secret information in your code. Put it into a configuration file which is read by your code at startup. Configuration files shouldn't be put on version control, unless they are the "factory defaults", and then they shouldn't have any private information. See also the question Version control and personal configuration file for how to do this ...


128

An iterative process will achieve this nicely, without detailed specifications. Simply create a sketchy prototype, ask for feedback from the customer, make changes based on the feedback, and repeat this process until the application is completed. Whether the customer is patient enough to do it this way is a different question. Some clients and developers ...


116

There's another interpretation. I don't believe it is what Uncle Bob meant, but it is worth considering. Don't capture coding standards in a document. Capture it in code, by having an automated process which verifies the standards are being met. Don't rely on people referencing a document, but at the same time, don't rely on people interpreting the code ...


114

Captain Obvious to the Rescue! I'll be Captain Obvious here and say that there's some middle ground to be found. You do want to build for the future and avoid locking yourself into a technological choice or a bad design. But you don't want to spend 3 months designing something that should be simple, or adding extension points for a quick and dirty app that ...


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


110

I like Amon's answer, but I felt one small part needed a lot more emphasis: You can easily simplify history while viewing logs to meet your needs, but others cannot add history while viewing logs to meet their needs. This is why keeping the history as it occurred is preferable. Here's an example from one of our repositories. We use a pull-request model, ...


106

I've seen this done before, both manually by authors and automatically by scripts and triggers integrated with version control systems to add author, check-in comment, and date information to the file. I think both methods are pretty terrible for two primary reasons. First, it adds clutter and noise to the file, especially as these comments age and become ...


106

"The Mythical Man-Month" came out the year I started college and was, to use the current vernacular, UUUGE! :-) What you need to understand is the difference in how software was developed THEN vs. NOW. Back In The Day (tm) pretty much all coding was done on paper first, was then keypunched onto (you guessed it) punched cards, then was read in, compiled, ...


101

First of all, we have to fundamentally distinguish between Computer Science and Software Engineering. (And maybe to a lesser extent between Software Engineering and Programming or "Coding".) As one of my CS professors put it: if you need a keyboard, you are not doing CS. TDD is very much a Software Engineering practice. It doesn't really have much relation ...


100

This is a very common experience Most people I interact with, and I myself as well, feel like this. From what I can tell one reason for this is that you learn more about the domain and the tools you use as you write your code, which leads you to recognize many opportunities for improvement after you've already written your program. The other reason is ...


99

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


97

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


97

I think it's a little disingenuous to say that good developers never have merge conflicts, but they can surely reduce the number of times it happens. It's also very important to remember that software development is a team activity. Actions of other members of the teams can also increase or decrease the likelihood of merge conflicts. First, it's important ...


91

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


88

There are some aspects of that concept that are sometimes implemented today, there are other aspects that are avoided. Keeping teams small is one of the basic features of Agile Methods, but is also practiced outside of Agile. Cross-functional teams are also a staple of Agile, but common outside of Agile as well. The role of the Program Clerk is largely ...


80

There was a similar bug in Windows 95 that caused computers to crash after 49.7 days. It was only noticed some years after release, since very few Win95 systems stayed up that long anyway. So there's one point: bugs may be rendered irrelevant by other, more important bugs. What you have to do is a risk assessment for the program as a whole and an impact ...


77

A few things stand out to me. The idea that management has that the team commits to a set of work is inconsistent with the latest versions of the Scrum Guide. The word "commit" or "commitment" is only used twice in the most recent (November 2017) version of the Scrum Guide - once when listing the Scrum Values and once to indicate that "people personally ...


76

An attitude of never using third-party libraries is preposterous. Writing everything yourself is a horrible use of your company's time, unless there is a strict business requirement that every line in the codebase was written by an employee of the company -- but that is an unusual scenario, especially for a private-sector firm like you've described. A more ...


73

Imagine if Stack Overflow had a guideline: instead of asking one question, you come and ask, in the same question, whatever comes into your mind, all your issues you had for the last two weeks. What would upvote and downvote mean? What would be the titles of the questions? How to accept the best answer? How to tag the question? Bug tracking system is done to....


70

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


69

People overlook the real purpose of a coding standards document, which is to settle disputes. Most of the decisions in the coding standard will have only a very minor effect on readability and productivity. Especially if you adopt the 'normal' style for the language, and language designers are starting to realise that this should be part of the spec (e.g. ...


59

There are several things you can and should do to prepare for the task: Think about the problem and draw some diagrams. Make sure that you know what the problem is that you are trying to solve. Do research on what you are trying to do. The internet is a valuable source of information. I am not saying ask Stack Overflow -- I am saying do research on how ...


57

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


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