Technical debt may be the way it comes

A friend of my technical blog may have noticed that a series of articles related to CEF, PPAPI and Skia have recently been updated. In the process of studying them, there are some interesting experiences, very typical, can explain the origin of " technical debt " from one aspect.

Next I will talk about this experience, and then start to see the reasons for the formation of technical debt and coping strategies.

Choose an easy alternative strategy

Because of the business need, I have to show another module (existing modules, based on C + + code completion) in the PPAPI plugin to pass over the image data. The data provided by that module, the image format is RGBA32, I compiled the Skia library on the Intel Pentium host, the default color type is Kbgra_8888_skcolortype (Kn32_skcolortype), This results in the conversion of the data received into the RGBA32 format to Bgra before drawing with Skia, otherwise nothing will be drawn. The conversion is feasible, I tried, but when the image resolution is high, time will increase significantly. Because pixel conversions are required, a pixel conversion requires at least three assignments and two index operations, and millions of pixels of images need to be manipulated in thousands of times.

When I finished converting the pixel format, I was greatly relieved to see that the normal color data was displayed in CEF. At this point I have two ideas:

1. In this way, the function is realized, the PPAPI plugin process will show the image is not doing anything else, slow not much impact
2. Study Skia To see why Skcanvas failed to draw in the RGBA format Skbitmap for the back end

That day 28, immediately to the new year, the first choice of the job is simply to find reasons to persuade themselves, to persuade the leadership. It's easy, and our programmers are always doing this, aren't they?

The second choice will be difficult, you have to do experiments, you have to bite the bullet to see the source of Skia ... This and do not say, did not have to work hard to solve, perhaps delayed the time and progress, and finally have to go back to the first choice. Anyway, I find myself a little bit rejected, and can find various reasons to give up this relatively difficult choice. Have you ever met this situation?

Oh, what am I supposed to do with the cake?

After a few years, I went to work on Valentine's Day number No. 2.14. Most people are still out of work, and I think it is necessary to study the question of the 2nd choice-sometimes slow is the biggest flaw. So I did the following things:

• ColorType and Alphatype of combined transform Skbitmap
• The color format of the ppb_imagedata used by the graphics 2D in the transform Ppapi
• How transform Skcanvas are created
• Change the way Skcanvas uses ImageData created by Ppapi
• Conversion of Rgba to Bgra with Skia images module for improved performance

In short, toss a day, did not find the reason! At this time again want to just so forget ...

Choose the easy way, the idea seems to be difficult to avoid, often inadvertently comes out. To really solve the problem, you need to muster up the courage to try to convince yourself.

The next day I think research skcanvas exactly how to use Skbitmap to draw, spent a large half a day to do experiments, read Skia source code, and finally found Skcanvas based on Skbitmap drawing will create a skbitmapdevice, And Skbitmapdevice will be based on Kn32_skcolortype to branch operations, and the Intel Pentium host is a small-endian, Skia the default compilation options compiled by the library Kn32_skcolortype is Bgra, So when I pass the Skbitmap ColorType set to Krgba_8888_skcolortype, and then pass this skbitmap to Skcanvas, Skcanvas build Skbitmapdevice as a drawing backend, doomed to failure!

The reason is clear, I have another two options:

1. Think this is Skia's limit, and that's it.
2. Study the Skia compiler system to see how to compile a library with the default RGBA on a small-endian host

The first choice, the work is over, can also be explained to the leaders and small partners.

The second option is to study Skia's build system, as well as the macro definitions that control the color type, as well as how skbitmapdevice and Skbitmap use the color type ... It is not yet known whether the compiled library has other side effects (the results prove to be there, something) ...

I've been working on this for a while, and this is the day off.

The next day, I took the courage to choose the research Skia, hey, don't say, after the Ninja Script, config header file and Skimageinfo related class library research, I really understand how to compile the default use Rgba library, and before work compiled out OH. Wow, I did the experiment when the small demo, using this new version of the library, Rgba bitmap used as a correct after the normal!

The next day, I modified the PPAPI plug-in code framework, made great progress: the received data can be normal display without conversion!

I was very happy: I overcame my own expediency idea.

However, the problem is that when loading images from a local picture file, the red and blue channels are reversed, the icons used look weird and the effects are all wrong ... Toss three ways to load local images, not all. But the memory of the drawing is correct drop ...

Again came the crossroads, faced with a few options:

1. No Skia loading pictures, using other, decoding into RGBA
2. Use Skia, get image data after loading, Exchange R and B (the icon is not big, performance loss is acceptable)
3. Study Skia The process of loading and decoding pictures from disk, figuring out where the problem is

Which do you think I choose?

2nd, the front has been done, is to copy a bit of code, the workload is very small, very attractive.

1th, bitmap with Windows Api,png, JPEG also have decoding library, before also used other image library, decoded the data is also RGBA, it seems there is no difficulty, is more work.

3rd one, full of unknowns and resistance. To see someone's code is always a headache, especially want to skia this excellent open source Library, the code is very good and clever, the interface between the module design is very concise, a lot of things are abstract, encapsulated, to understand the need for a lot of time ... Also, the lack of documentation (well, the code is the best document, will never encounter the document and the implementation of disjointed issues) ...

Find the will image library, what freeimage, Cximage, see will Skia source, ... The ideological struggle to work is not decided, recorded in the book, the next day to choose it.

I came home to ponder the question: Why do I always want to choose the easy way ?

Yes, why is it always nianqingpachong?

At this point in my mind I think back to the previous work history, which can run the results of the code was forced to refactor, which temporary policies caused the technical debt caused a bad impact ...

Then I decided to choose 3!

Now the problem is solved!

The programmer's Instinct for (I do not represent all programmers) is to save things, to choose the easy way, the high certainty of the road, it is no good to criticize-if the easy way to solve the problem, it is the best choice.

However, in order to get rid of the pressure, the use of easy-to-do, expediency, temporary technical solutions, most of the time will bring technical debt .

How does technical debt come about?

As you can see, I encountered a problem when I used Skia to draw the RGBA image data passed by another module in the Ppapi plugin, and in the process of solving the problem, I experienced three choices, each time faced with the easy compromise scheme and the difficult, uncertain but real solution to the problem. I have been inclined to choose an easy, small, and short-time solution for these three moments.

This is not just my personal situation, but the customary behavior that most programmers choose from multiple alternative solutions to a problem. This habitual behavior, on the one hand, is a human instinct--people always give up the challenge and choose the easy way without hesitation. Because challenges are accompanied by uncertainty and self-control, the easiest way to get there is faster. In the case of a child, you put two sugars in front of him, telling him that if he eats it tomorrow he can get two more sugars and now it's gone, and he's probably going to grab the two sugars after a little hesitation.

we tend to be immediate gratification, and delayed gratification is a thought and behavior habit that needs to be practiced to form . This is an important reason for programmers to choose a solution that is easy to handle.

It is natural to avoid trouble and annoyance, so even without outside pressure, we tend to choose a solution that looks more provincial. But that's not all the reason programmers make this choice. Programmers do this, and there are other reasons too:

• Pressure of delivery time
• Better cultural orientation For more performance per unit of time
• Insufficient capacity
• It's a matter of mind.

Expand it a little bit.

• 1. Pressure of delivery time

This is the most common and straightforward reason for choosing a simple and rude solution.

Back to the question I said earlier, is actually a small problem, on such a small problem to spend nearly a week, in the case of tight delivery time is difficult to be allowed (I was just after the spring festival this buffer period can be calmly to solve it), I do not allow leadership and not allowed. When you perceive the strong pressure of delivery time, the result is often realized first, then time to optimize . However, this is the biggest and most popular lie that programmers have said, the realization of those things, often so, until it is a problem by the user and the leadership of the time-limited changes, only to start a new round of circulation.

• 2. More is a good performance-oriented

Many companies Drum (PO) Qiang to do more work, if you can more parallel working, faster delivery, complete more versions, performance will be better. In this direction (System), we will pay more attention to quantity and speed, neglect of quality and maintainability, the immediate problem on the muddle, slowly formed just to pull the crap regardless of the development habit of wiping the buttocks.

Not only is the programmer, the programmer's leadership performance is often such a guide, so the front-line managers will often accept the middle-level, senior executives unreasonable delivery requirements, turn around will give the programmer more urgent delivery time to transfer the pressure down.

• 3. Insufficient capacity

This is also an important reason, sometimes the programmer encountered problems he can not solve at the moment, only to whitewash the past or detour-to solve it from the gener took too long, no one can accept (refer to the previous two points).

• 4. There's something wrong.

This is also a lot of programmers in the common mentality of childhood: can run on the first run, no problem on the first so, want so much to do, out of the problem, anyway, do not finish the work .

This is the typical work mentality .

When I had dinner with my old boss during the new year, he said something that impressed me: If a company can't let employees feel that they are working for themselves, the company will be finished sooner or later . This is actually about the cause of the mentality.

Do you think you are working or doing business, whether you are doing it for yourself or for the company, to a large extent determines how you do it.

How to avoid technical debt

Looking back at my previous experience, there are two points that need special attention:

1. I never thought I'd run into this problem (accidents always exist)
2. When time is loose, I have a chance to solve the problem completely (time permitting programmers to challenge challenges)

Ok, this is also a very important two points to be consulted in the software development process to avoid piling up technical debt.

About these two points, has been developed for two years have experience. However, people who have a deep understanding often do not have the right to decide, so we have to let management and bosses realize the following points:

1. In terms of software development, no road is duplicated. People have walked the road we have to walk, still may not go well, have been verified by others, we can still encounter a variety of problems when used. Even if we do our best assessment before we start, there are problems that we can't think of that we can jump over and crush.
2. Software development is a craft job and must be left with enough time for the programmer to be patient and polished to make good things.

Only when we realize this, the technical atmosphere and performance orientation will change, which can help to form a culture of "no" to technical debt.

For more articles, please follow my subscription number " program Horizon " or column "talking about programmers".

Technical debt may be the way it comes