Simple thing--just Google a little bit.
Incoming group: 125240963 to get dozens of sets of PDFs Oh!
I can't remember a lot of things. Functions and methods in the standard library, parameter locations, package names, boilerplate code, and so on, are all outside of my brain capacity.
So, I have to use Google search. I do it every day. I've also been reusing code for old projects. Sometimes I even copy and paste answers from StackOverflow or GitHub. Yes, my development is actually called: StackOverflow Drive development.
But I'm not alone. Many other developers do the same. One of the most popular Twitter discussions was initiated by the creator of Ruby on Rails.
So why do you think this is bad at first? Because it has several drawbacks:
- Code that can cause you to replicate to poor design decisions or vulnerable to other people's attacks
- Will form a dependency mentality: if we can't get Google to the content, then we can only ask people for help.
- I can't work without a net.
But I don't think these are big problems. It can even be used as a secret weapon for you. I have some suggestions that can be used to reduce their negative effects.
Survival Guide:
- Use the IDE to get AutoComplete and suggestions, so you don't have to base your Google programming language;
- Remember where you have solved the problem (not how to solve it). So you can always find a solution there;
- All the code pasted into the project you should analyze, refactor, and review later. This allows us to quickly deliver solutions without damaging the project.
Keep things simple and clear
What we say is what the machine does. Even if they are wrong, they do not hesitate. So, the main problem in software development is not the machine, but the mental capacity of the developer. And the space for this thing to ascend is very limited. So, we-as mediocre developers-can't waste a limited amount of brainpower on creating complex abstractions, fuzzy algorithms, or long blocks of unreadable code. You need to keep everything simple and clear.
But how do we determine if the code is simple or complex? We use the Wtfs/minute method to measure the quality of the code.
This principle is easy to understand. Whenever you find something in your code that you don't understand--oh, it's too complicated. How do you do it?
- Rewrite to make the design cleaner
- Provide documentation
- Add comments to the toughest parts. But keep in mind that comments should describe the code itself
How to keep it simple and clear from the beginning:
- Use the correct name for variables, functions, and classes
- Make sure that every part of the program does one thing
- Pure function is better than regular function
- The regular function is better than the class
- Use the class only in case of strong demand
I'm not confident.
Some developers will prove that they can provide high-quality code. Look at this woman in the picture: Margaret Hamilton, Chief software engineer for the Apollo moon program. What's that almost as tall as her? Well, that's exactly the code she wrote for the moon Mission:
But whenever I write any code--I don't feel confident. Even the simplest part of the project, I can make a mess of things. Reasons for the mess include:
- Language error
- Logic error
- Design Error
- Style error
- Security error
- WTF error (I always like the most!) )
There is no magic book on "Learning how to write code without bugs." Because all software has bug--in addition to this framework. We should get rid of the bug when we meet it.
The key point is that code written by everyone should not have obvious errors. Right, at least, we should do this. But how do I protect my project from my own cruelty? 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 avoids some logic errors;
- Use a static type or an optional static type. For example, we use Mypy in Python to use flow in JavaScript. Positive effects: Cleaner design and "compile-time" checks;
- Use automatic style checking. There are a lot of style checker in each language;
- Use quality checks. Some tools run complex heuristics on your code base to detect different problems, such as too much logic in this line of code, which is not needed, and this function is too complex;
- Review your code. Review it before merging to master. And a certain time after the merger;
- Pay for someone else to review your code. This means can have a huge positive impact! Because if you're unfamiliar with developers looking at your code, they're more likely to find inconsistencies and poor design decisions.
Not only applies to me
About 10 years ago, when my team developed our first large software project, we published it as a Java source file. However, it cannot be compiled on the target server. This distance needs to be submitted to the customer for only a few hours. This is a huge failure! Finally we can finally start and run, but it is undeniable that this is really an unforgettable experience.
This happens because there is a lot of configuration and complexity in the build pipeline. And we can't manage the complexity of the system properly. So, from that day onwards, to reduce this complexity, I tried to package my program in an isolated environment. and test them in this environment before the actual deployment occurs.
In recent years, when Docker (and usually the container) has risen, things have become easier. Docker allows you to run development, testing, and production in the same isolated environment. So, you will never miss any important things.
So what are you going to do? To talk 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 automate all of this. There are a number of different tools to automate the deployment process, such as terraform,ansible and Packer, which are extremely powerful. 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 in the test or deployment, then there will be a report sent to me.
Survival Guide:
- Automate any content that is used for deployment;
- Use Docker for application development, testing, and deployment;
- Use the deployment tool.
After application deployment, I still don't feel confident
Finally, my application has entered the product phase. It's ready to work. I can have a rest and there should be no problem. Wait, no! It all collapsed. Yes, I did not say wrong: everything.
In fact, there are tools that make it easier to find and solve existing problems.
- Sentry. When any of your users have an error-you will receive a notification. 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 monitor for CPU, disk, network and memory. You can even find that you need to increase the time before the user actually destroys your service.
In short, we need to monitor the application in production. We sometimes use all of these tools, sometimes using only the ones that are most needed.
Learning
The things that need to be learned 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. A little progress every day, it will be better.
In short, we need to understand two basic things:
- Everyone will have problems. The point is that we have to be prepared for these problems;
- We can control the source of the problem to some acceptable level.
These have nothing to do with your mental abilities or mentality.
A senior Python programmer experience, the programmer benefited from life, I regard it as a survival guide!