Regardless of the topic, I personally know some very talented developers who can create great software with ease. It is these talented people that make laymen full of high expectations for our industry. But the sad fact I want to say is: not everyone is a ninja/master/star developer.
I am not these shining new stars, I am just a mediocre developer. If you are not a genius player, then this article will guide you how to survive in this industry.
The simplest thing-just google
I can't remember many things. Functions and methods in the standard library, parameter locations, package names, boilerplate codes, etc. are all beyond my brain.
So, I have to use google search. I do this every day. I have also been reusing code from old projects. Sometimes I even copy and paste answers from StackOverflow or Github. Yes, my development can actually be called: StackOverflow-driven development.
But I am not alone. Many other developers do the same. There is a wide-reaching twitter discussion started by the creators of Ruby on Rails.
So why did you think this behavior was bad in the first place? Because it has several disadvantages:
- Will cause you to copy bad design decisions or code that is vulnerable to others
- Will form a mentality of dependence: if we can’t google the content, then we can only ask for help
- Can't work without internet
However, I don't think these are big problems. It can even be your secret weapon. I have some suggestions to reduce its negative effects.
Survival guide:
Use the IDE to get auto-completion and suggestions, so you don’t have to google the basics of the programming language;
remember where you have solved this problem (not how). This way you can find a solution there at any time;
all the code pasted into the project should be analyzed, refactored and reviewed later. In this way, we provide solutions quickly without damaging the project.
Keep everything simple and clear
The machine does what we say. Even if it is wrong, they do not hesitate. Therefore, the main problem in software development is not the machine, but the mental abilities of the developers. The room for improvement of this thing is very limited. Therefore, we — as mediocre developers — cannot waste our limited brain power on creating complex abstractions, fuzzy algorithms, or unreadable long code blocks. You need to keep everything simple and clear.
But how do we determine whether the code is simple or complex? We use WTFs / Minute method to measure code quality.
This principle is easy to understand. Whenever you find something in the code that you don't understand-oh, it's too complicated. How to do it
- Rewrite to make the design cleaner
- Provide documentation
- Add notes to the trickiest part. But remember, the comment should describe the code itself
How to keep it simple and clear from scratch:
- Use correct names for variables, functions, and classes
- Make sure that each part of the program only does one thing
- Pure functions are better than regular functions
- Regular function is better than class
- Use classes only in strong demand
I'm not confident
Some developers will prove that they can provide high-quality code. Just look at the lady in the picture: Margaret Hamilton, the chief software engineer of the Apollo moon landing program. Then what is almost as tall as hers? Well, that's the code she wrote for the moon mission:
However, whenever I write any code-I am not confident. Even the simplest part of the project, I can mess things up. Reasons for messing up include:
- Language error
- logical error
- Design error
- Style error
- Security error
- WTF error (my always favorite!)
There is no magic book about "learning how to write code without bugs". Because all software has bugs-except for this framework. We should deal with bugs when we encounter them.
The key point is: everyone writes code without obvious errors. Yes, at least, we should work towards this goal. But how do I protect my project from my destruction? There are many ways.
Survival guide:
- Write tests. Write a lot of tests. From integration testing to unit testing. Run the test in CI before each pull request. This can avoid some logic errors;
- Use static typing or optional static typing. For example, we use mypy in python and flow in javascript. Positive effects: cleaner design and "compile time" checks;
- Use automatic style checking. There are many style checkers for each language;
- Use quality checks. Some tools run some complex heuristic algorithms on your code base to detect different problems. For example, there is too much logic in this code line, this class is not needed, and this function is too complicated;
- Review your code. Review them before merging into master. And some time after the merger;
- Pay for someone else to review your code. This method can have a huge positive impact! Because if unfamiliar developers come to view your code, they are more likely to find inconsistencies and bad design decisions.
Not only for me
About ten years ago, when my team developed our first large-scale software project, we released it as a java source file. However, it cannot be compiled on the target server. This is only a few hours before it needs to be submitted to the customer. This is a huge failure! In the end, we exhausted all the means to finally be able to get up and running, but it is undeniable that this is really an unforgettable experience.
This happens because of the numerous configurations and complexities in the build pipeline. And we cannot properly manage the complexity of this system. So, from that day on, in order to reduce this complexity, I tried to package my program in an isolated environment. And test them in this environment before actual deployment happens.
In the recent years of the rise of docker (and usually containers), things have become simpler. Docker allows you to run development, testing, and production in the same isolated environment. So, you will never miss anything important.
So what would you do? Talking about myself, I always forget something when creating a server, initial configuration or connection. Because there are so many things to remember! Fortunately, we can all automate these. There are many different tools to automate the deployment process. These tools are very powerful, such as: terraform, ansible and packer. Read the tool information to find out which one is actually needed for the task.
I also try to build CI/CD as soon as possible. This way, if my build fails during testing or deployment, a report will be sent to me.
Survival guide:
- Automate any content used for deployment;
- Use docker for application development, testing and deployment;
- Use deployment tools.
After the application is deployed, I am still not confident
Finally, my application has entered the production stage. It can work now. I can rest, and there shouldn't be any problems. Wait, no! Everything fell apart. Yes, I am not wrong: everything.
In fact, there are some tools that make finding and solving existing problems easier.
- Sentry. When any of your users make an error-you will be notified. Almost all programming languages are bound;
- Use different services and tools to collect logs from multiple processes and servers in one place;
- Server monitoring. This is where you can configure the display for CPU, disk, network and memory. You can even discover the time that needs to be added before users actually disrupt your service
In short, we need to monitor applications in production. We sometimes use all these tools, sometimes only the most needed parts.
Life-long learning
The things to learn are endless. If we want to write good software, then we need to constantly learn how to do it. There are no shortcuts and no magic. Make a little progress every day and you will get better and better.
In short, we need to understand two basic things:
- Everyone has problems. The key is that we have to be prepared for these issues;
- We can control the source of the problem to some acceptable level.
These have nothing to do with your mental capacity or mentality.
The above are some video resources I collected, which helped me a lot in this process. If you don't want to experience the feeling that you can't find the information during self-study, no one answers your questions, and insists on giving up after a few days, you can join our deduction group [313782132], which has various software testing resources and technical discussions.
Recommend good articles:
How do automated testing practitioners choose jobs? What is the future career development?
The basics of automated testing, everything you know and not know is here!
A pack of sad spicy strips to share-top ten best automated testing tools
About software testing! Everything you want to know is here, Xiaobai must see!
What you need to know before doing automated testing
10 years of software testing engineers' perceptions-to friends who are still confused
What kind of person is suitable for software testing?
Knowledge to understand python automated testing(3)
Which is more suitable for automated testing, Python or Java?
The daily work of software testers
Play with Python+Selenium automated testing in 10 minutes, and teach you a quick start!
Here I recommend an architecture learning exchange group to everyone. Communication learning group number: 313782132 Some video recordings recorded by senior architects will be shared: Spring, MyBatis, Netty source code analysis, principles of high concurrency, high performance, distributed, microservice architecture, JVM performance optimization, distributed architecture, etc. These become the necessary knowledge systems for architects.