First of all, I want to make it clear that you don’t have to dig a hole to make a bad project. This is a big project that requires teamwork
If the title uses the word “bad,” what is bad?
“Bad” is just as hard to measure and define as “good” in your project, and you’ll hear about “bad” projects more often than “good” projects in most people’s careers.
When you are in front of a maintenance project, you spit out 10,000 grass horses while Coding on it, and finally deliver the maintenance task on time, can you call that a “bad” project?
I’ve never had a project that was too “rotten” to maintain, because I was the one who let it rot.
Maybe the evidence for a “bad” project isn’t as easy to list as how to Write Unmaintainable Code, so you don’t think it’s bad at all.
Recognizing that a project “stinks” is as basic a quality for a good developer as smelling bad code.
However, when I say “bad” in this article, I only look at the project from the programmer’s point of view, and it has nothing to do with the creativity of the project itself or its strategic significance at the company level.
tool
When I started out (circa 2006), the Java ecosystem was already pretty strong, but the companies I worked for right out of school didn’t use much automation in their project deployment.
One company even compiled a Java file locally and uploaded the class file to an online server. Even though there were advanced tools like ANT, we were still apes. It didn’t evolve. You know, the use of tools is an important marker of human origin.
We are in the best of times, Maven is the standard for Java building and Gradle is the new kid on the block. Please take building high availability automation toolchains to the same level as developing high availability systems.
If you use a tool in your project, it is fragile: too dependent on the environment, dependent on complex configuration, and sometimes buggy.
If your project doesn’t have a one-click command build, package.
If your test environment and online environment application deployment time is out of control.
…
Then your project, it’s going to rot because it’s inefficient. If you want to learn Java engineering, high performance and distributed, simple. Micro services, Spring, MyBatis, Netty source analysis of friends can add my Java advanced group: 591240817, there are cattle live in the group to explain technology, as well as Java large Internet technology video free to share to you
The framework
Yes, you’ve heard this word since you started looking for a job. If you were a studious guy in school, you’ve heard this word before. In the Java world, you don’t know how to use several frameworks, and you don’t want to hang out. Proficient in the Spring, Hibernate, Struts, Mybatis… One company I worked for even had a Demo code learning session for the company framework.
So, when you come to the company for the first time, I think at least one of the frameworks mentioned above will appear in your project. Let’s take a look at the use of frameworks in the project I met:
-
The framework was used, but the version was last century and still running online
-
Relying on the same third-party open source toolkit with multiple versions
-
Some places use annotation configuration of the framework, others use XML configuration files
-
A project that was supposed to take tens of thousands of code to fix ended up packing framework dependencies together, at least tens of millions
-
Can’t see why this project needs this framework
-
…
The word framework originally comes from architecture. In the software industry, I understand framework as an abstract implementation to solve a particular scenario problem. In the spirit of entertainment, there is no introduction of too written words, easy to cause disgust.
If your project, like mine, meets more than two of the above, I believe it will continue to deteriorate as long as it continues, probably for the following reasons:
-
You’re a young man with a vision. You want to smash a mechanical keyboard in the face of your ex-ex-colleague who has left the company for no one knows how long, and then shout out “I need to rebuild”, but the boss says: Yes, you need to fulfill these requirements first.
-
In the end, the boss agreed, “Go ahead and refactor, but would you dare to replace a running online framework with the latest version?” (Your project uses more than one framework, and there are dependencies between frameworks, so you can’t just upgrade one of them.)
-
Thinking of this, I would like to look around the colleagues of Coding. Some of them have worked for several years, and some of them have just joined the job. Do they have the same ideal and pursuit as you
-
…
If you have studied PMP, these questions can be summarized as risk and cost.
With the introduction of the framework, have project members done enough to build on it? If it’s just up to the point of use, can you fix it in as little time as possible because of the problems the framework raises?
Otherwise, the framework becomes the shackle of the project, and it won’t make the project better, if not worse.
The domain model
Yes, no problem. It’s great to use Spring in our project. Spring advocates interface oriented programming, we have a complete Service interface layer.
Yes, as mentioned above, I have learned the Demo code of the company’s framework, in which modules are divided into Domain, Dao, Manager (used to manage transactions at the Dao layer), Service and Web. In fact, in a Service, one Service interface corresponds to one Dao (most of the time, this is the case). If you have a few tables, there are probably as many Service interfaces as there are tables. If a new Service comes in, add a table, and create another Service interface,Service, Daos basically serve the DATABASE CRUD.
There have never been more than one implementation of an interface class since its inception in the project, when interfaces were defined only to comply with interface-oriented programming.
In the years of confusion, I found out the truth that I had misunderstood the term. “DDD” has two meanings, one is data-driven Design and the other is domain-driven Design
A project without a domain model abstraction is bound to rot sooner or later.
code
Frameworks and models allow you to look at the project from a higher perspective, and ultimately get back to the code. Good projects (teams, I should say) are bound to find a set of specifications (currently known as “catch-22”). Each team may have different specifications, but they still find a lot of commonalities.
-
Code specification (Checkstyle, method name, class name specification, comment specification, code format specification…)
-
Engineering specifications (build process, release…)
-
Design specifications (design complexity control, module dependency…)
-
Database table design specification, SQL specification
-
…
In my experience over the years, when it comes to specifications, the focus is on getting project members to understand and agree with them, and ultimately implementation, and many project members’ resistance to specifications stems from the superficial belief that specifications only allow them to spend time on non-functional requirements.
Norms are a form of identity, but to build a better one for project members, sometimes you have to use charisma (if you have it) or bitter experience (veteran drivers certainly have it).
Look up at your project and see if you can find a mandatory specification. If not, jump out of the article.
If you’re aware of it, and you just go on the Internet and pile it all up in a project, it still doesn’t work.
Specifications don’t make your code any better. The specification simply prevents code from being filled with the emotions of a single, loser programmer (ape), avoiding obvious errors.
With specifications, do you have code reviews?
You can search all over the web for “how XX team values code review,XX team developed a code review tool for code quality”, but you can hardly find out how XX team does code review, so figuring out how code review works is more important than code review itself.
In short, there is a trade-off between a code review as a political mission and a convention, and if you smell something bad in the code review atmosphere, you should stop.
A project with good code specification and code review will not go bad easily.
test
When I learned programming in college, it seems that the teacher did not teach me what testing is. When I wrote TC, the teacher only said that the computer was used to execute it. In retrospect, it seems that the textbook at that time did not specifically talk about testing. (Maybe I didn’t learn)
From a project code point of view, the most basic is unit testing.
Your project may have unit tests, but they are either outdated (not evolving with the code being tested) or do not meet coverage requirements at all.
When you want to write a unit test for a feature, it’s harder to write the unit test than it is to implement the feature, and you do just that.
The purpose of testing is to find as many defects as possible and ensure quality as possible.
However, many projects do not clearly define quality boundaries at all, or even complete functional testing.
Make a list of the tests in your project and list them in categories. If the tests could be written on a single piece of paper, the project itself is bad, and doesn’t need to rot.
Again, without adequate testing (what is adequate testing?) The project was already rotten.
demand
All business needs should be met
Business is the fundamental driver of a project, so to speak, no project exists without requirements.
For a developing project, however, it is possible that the requirements are slowly decaying it.
Because I’ve seen too many requests come from project controllers (leaders), rather than from actual users, who say “I’m one of the users,” and most developers are basically at the bottom of the food chain. So when it comes to the above situation, there is basically no solution (excluding those companies that truly implement the engineer culture).
The requirements of most projects will correspond to a system function, and the system function will have a life cycle, but the code in the project often grows along with the requirements. For the outdated function code, no one dares to delete it, and then it becomes bloated.
Another situation is when a requirement transcends the domain model, such as an ATM machine that lets you build in video playback capabilities (which are in real life), and you sometimes don’t recognize such a requirement, and then implement it beautifully.
Congratulations, your project is at risk of rotting.
Negative emotions
It may sound far-fetched, but the relationship between negative emotions and “bad” in a project is a bit like a chicken and egg, but this is only one aspect. If you look at the negative emotions in a project, they come from all aspects.
Some developers get angry when they encounter the problems mentioned in How to Write Unmaintainable Code, and then complain that there is no uniform code formatting tool, no canonical directory structure, and even different log output formats…
If you hear this kind of abuse a lot in your projects, then your projects aren’t going to rot so fast.
Dissatisfaction with reality and trying to change it is a basic quality of a good programmer, but you have to stop and think about whether there are more people around you who are dissatisfied or trying to change it.
I personally enjoy working with developers who are discontented and emotional, and fear those who just complain and stay silent when it comes to making changes.
Emotions are contagious. Some emotions can have a negative effect on a team, while others can be motivation, depending on the team’s self-awareness.
How do you identify negative emotions you encounter on a project?
-
Small A recently often while writing code, while browsing recruitment websites
-
Small B often tell you that the salary of such and such company is higher, full MAC environment development, 23 inch monitor…
-
Little “C” tells you, little “A” and “B” code sucks
-
Little D complained about not being able to improve his skills
-
…
Rest assured, if you’re in a leadership role on a project, you won’t hear much of this list of complaints. If you’re just a regular developer, buy a copy of Programmer Self-Cultivation and turn your negative feelings into positive ones.
The status quo
An old programmer told me proudly that a program he wrote had been running online for almost 10 years and never moved.
I just smiled and said, awesome
If I wrote a program that printed Hello World, deployed it on a solar-powered Linux machine, and put it in outer space, who knows how long it would run.
In some of my projects, I have used third-party tools that are at least five years old since their latest release.
My colleagues told me why upgrade when it was so stable.
You know, how often is the JDK released now? What bugs were fixed each time? What are the performance improvements? The third-party package you are using was developed under the JDK 5 years ago, and the developer is probably dead.
Note that we are not talking about escalation, we are talking about change.
Maintaining the status quo is an inert mindset that has paralyzed developers’ assessment of the risks associated with project change.
If you compare a project to a car, it just keeps running without regular maintenance. (The point is that you don’t know which parts to maintain.)
Don’t let the status quo mentality erode the project and allow it to slowly deteriorate.
Finally remember:
In an era of teamwork, you’re not alone in digging holes.
You can also follow our wechat official account
