in the final analysis, is that you are incompetent and unfamiliar with the language, not the language itself. Bug is inevitable. How to avoid bug, through reasonable design and agreement at the design stage and how to efficiently locate, solve and learn lessons from bug after the emergence of bug, is the most basic accomplishment that a programmer should have, if you don't understand the characteristics of the language at all. Do not know how to improve the operation efficiency, do not design the model well before realization, force to write at will; Today defined a data type, tomorrow according to another type of writing; today this function is this function, tomorrow will change that function; global variables running around, variable name abcd line up, with its own confusion, then you write in any language is a pile of bug. Dynamic languages are fine, you can still run, static languages you can't even compile, and then you have to ask a question: can you change a language that can be compiled except CPP,?
< hr >
it is also recommended that you migrate to typescript, after you are familiar with the language features, including static type checking, but that doesn't mean there will be no bug.
< hr >
I don't know if you've seen it, but I'll post the reply below
.
- will have the idea that you are incompetent, and you need to look at other people's or framework code, learn other people's ideas, and learn the design ideas of the framework.
- bug is acceptable, but there are too many low-level bug (two or three low-level bug in a single page can ruin the user experience), and more lack of consideration will make people feel that you are too careless. To achieve the most thoughtful consideration possible, it can be implemented through abstraction and modularization, which is what various frameworks do for programmers. In addition, it is determined that the single point / single module has no obvious bug, and then it is integrated into its parent module.
- may wish to draw a program block diagram / structure diagram / data flow diagram / state machine before implementation, and then design and implement according to this. The implementation must write comments, do not require every sentence to comment, before each function, each module should have comments to indicate its role, complex modules had better also indicate their ideas, single sentence readability of the coquettish operation should also be annotated.
- it's not js and bug, that you reject, it's the job.
< hr >
answer your comments: just search directly. These things are the concept of software engineering, small projects are optional, large projects usually need these things, of course, if you have a headache in small projects, you can also use these things to help you develop.
give an example of a development method (in fact, there are several software development models summarized by predecessors):
< H2 > Analysis requirements < / H2 >
for you, the requirements should have been analyzed by analysts, and you should be able to get the listed requirements directly, such as what functional modules / partitions are in the main interface, whether users mainly use mobile or PC, and so on. If this part of the work is not independent, then you should do this analysis on your own, and the requirements listed need to be confirmed by Party A to avoid unnecessary trouble caused by misunderstanding.
< H2 > UI and interaction Design < / H2 >
this section can be isolated, but in most cases it seems to be handled by front-end engineers. If you do not have a separate design department, and the entire site is more complex, you need to list the general possible pages first, and then you need to design the general style of these pages (which can be roughly drawn on paper). Never think of adding a page to create a new a.htmlreb. Htmlpaper denglu.htmlzhuce.html, or at least login.html. Of course, it's common to add pages in the middle of development, but it's much better to figure out how to divide them first than to write a few pages together and then separate them from a piece of code.
< H2 > div
ide modules and sub-functions < / H2 >
after the UI is roughly designed, complex functions can be subdivided into sub-functions according to functional modules. If complex data processing is involved, modules need to be divided for data processing functions and interfaces are agreed upon. UI operations are separated from data operations and requests as much as possible. For example, suppose you have a function that collects some data at the click of a button, sends a request to the back end, and then gives feedback to the user based on the response result (assuming that the server has three response results: success, invalid form, temporarily unavailable). If the UI operation is not separated from the data operation, the code for this function might look like this:
$('-sharpsomeButton').on('click', function() {
let name = $('-sharpname').value()
let user = $('-sharpuser').value()
// Some other data
if(!user) {
alert('User must be specified!')
return
}
// Some other checks before sending the request
$.ajax({
url: '/',
method: 'POST',
data: {
name,
user,
...
},
success: data => {
if(data.status != 'success' || !(data.msg)) {
// Exception handling
}
$('someDiv').html(data.msg)
},
error: (xhr, errMsg, err) => {
switch(xhr.response) {
case 'INVALID_FORM': // ...
case 'TEMPORARY_UNAVAILABLE': // ...
default: {
switch(xhr.status) {
case 400: // ...
case 500: // ...
// Exception handling
}
}
}
}
})
})
and separated will look like this
const API_URL = {
someFeature: '/'
}
async function someAPIFunction(name, user, /* ... */) {
let res
try {
res = await post(API_URL.someFeature, { name, user, /* ... */ })
} catch(err) {
throw new Error(err)
}
switch(await res.text()) {
case 'SUCCESS': return
// Some other cases
}
}
$('-sharpsomeButton').on('click', async function() {
let name = $('-sharpname').value()
let user = $('-sharpuser').value()
// Some other data
if(!user) {
alert('User must be specified!')
return
}
// Some other checks before sending the request
try {
await someAPIFunction(name, user)
} catch(err) {
// Some exception handling
}
})
looks much more readable, and the UI is completely separated from the part that calls the back-end API, making it easy to locate the bug and maintain it.
< H2 > implementation module < / H2 >
implement each module according to the previous design, and test each module separately to ensure that each module is correctly implemented before integration, so as to prevent errors existing in a single module from being magnified after integration. If you find that the previous design is not reasonable enough during the implementation, you can modify the previous design.
< H2 > feedback, modification < / H2 >
ask users / testers to try out the product prototype and improve the function according to the feedback.
the above processes can sometimes be performed in parallel.
< hr >
things like structure diagrams, data flow diagrams and block diagrams, Search for Baidu pictures and you will find: fromurl=ippr_z2C%24qAzdH3FAzdH3Fooo_z%26e3Bdvp5_z%26e3Bv54AzdH3FhuAzdH3Fda89abAzdH3Fndb88c_z%26e3Bip4s&gsm=0&rpstart=0&rpnum=0&islist=&querylist=&selected_tags=0 "rel=" nofollow noreferrer "> link 1 , fromurl=ippr_z2C%24qAzdH3FAzdH3Fw6ptvsjf_z%26e3Bj-o56hf_z%26e3Bgjp_z%26e3BvgAzdH3FPLCAzdH3Fw6ptvsj8a0b9a_8_z%26e3Bip4&gsm=0&rpstart=0&rpnum=0&islist=&querylist=&selected_tags=0 "rel=" nofollow noreferrer "> link 2 , fromurl=ippr_z2C%24qAzdH3FAzdH3Fzit1w5_z%26e3Bkwt17_z%26e3Bv54AzdH3Fq7jfpt5gAzdH3F8bnnb0mac0bclc0n0aa_z%26e3Bip4s&gsm=0&rpstart=0&rpnum=0&islist=&querylist=&selected_tags=0 "rel=" nofollow noreferrer "> Link 3
1. The reason why you think the back-end bug is less is that the back-end business logic is only reflected in the data, as long as the data results are right, but there is a lot of uncertainty in the front-end page data display and interaction itself, so for some inexperienced people, bug is mostly positive, and it has nothing to do with js
2. If it's just the grammatical structure of the language itself, there are many alternatives, such as coffee,typescript,. Personal comparison suggests using typescript
without code without bug ~
to be a product manager and leave the problem to programmers
you will lose your job without bug
the so-called perfection has always been a illusion . To put it bluntly, it is the pursuit of perfection. If it is not good, it means that it does not know how to choose.
to do anything, we need to balance costs and benefits. We can only make the most economical choice, but it is difficult to be perfect.
for example, the problem of bug
, if the programs in the world can be developed to such an extent that they are not as perfect as bug
, then they will not need so many programmers. A program without bug
unless nobody uses it. The world written by God has bug
, not to mention that we are a programmer.
I think the core competence of programmers is the ability to solve problems.
as you said, others can easily find a bug
, so why not find out bug
yourself first. Write the unit test yourself first, don't wait for others to find fault.
you say that complexity is not considered fully, this is normal, no one is born with everything, the important thing is to learn, learn and learn, and consider what you can consider. When the later appears and does not take into account, it is the solution. I will remember this lesson next time, and for a more comprehensive consideration, it takes a process to grow up.
The essence of a
program is a problem-solving tool, and the key depends on who is using it.
js does have a lot of flaws. If you think it's a language problem, you can use ts, strong object typing, add a lot of constraints, and develop to avoid a lot of low-level bug;, but in the final analysis, it's your own ability.
the back-end bug is less because the back-end is responsible for less logic, and a lot of things are provided to them by the framework. While the front-end has to consider many aspects of user operation / business logic / data format, which requires a lot of work. Of course, the fact that it is easy to produce bug; does not mean that the front-end ability is weak or the language itself is not good.
I think you should first consider various situations when writing code, and then restrict the format returned when there is no data when docking with the backend, and test more when you write it yourself, and at least run through each process before testing.
another is the development specification, if there is a lot of bug, I think there may be problems with the development process and specification.
this is not a matter of language. If you change the language, you still don't understand the principle of operation and the completeness and complexity of public component encapsulation. This is your problem. It has something to do with the language. If you don't think about it carefully, you can test it by yourself and write a pile of rubbish and have the face to say it here! The most disgusting you write this kind of garbage not to test, but also tm shirk responsibility!
JS is the best language in the world, and there is no one ~
.