13 recommendations for efficient design of building software

I've been rethinking the utilities that have been developed over the years and have thought about ways to design better.

I broadly define the utility as "any project that solves a single or specific problem for a specific scenario or business process."

For example, I wrote a small program in PHP that entered the output from the e-commerce store and converted the data into the format needed for the next specific business process.

How can design be more outstanding?

I usually have a solution to the problem of the idea will be immediately hands-on, open an editor at once to begin to tap the code.

After a while, I found that I needed to copy some functionality from a previously written utility, but when I started reusing the code, I realized that the code I had written was really bad. Usually I don't spend too much time on realistic applications, and the consequence is that most of them have no classes, no namespaces, not even object-oriented. In order to achieve the purpose of even the use of procedural programming!

After this I think it should be more planned, even for small projects.

Now before I start a new project, I will consider the following points:

1) Basic skills are required!

No matter how small the utility program, you have to develop a good programming style! Use the correct source code format, naming specifications and annotations. Make it easy for others to read the code without any difficulty.

Avoid procedural programming as much as possible.

Even if the project is small or is of limited use, I will not write the code carelessly.

2) define the project

Unless the utility has only one function, start writing code before the project is well defined. The definition of a program should include a basic declaration, such as who will invoke it, what the preset input format is, and what the expected output is.

Also define data sources, security issues, and whether future programs will incrementally increase functionality.

Where is the utility hosted?

The more detailed the definition, the easier it will be to pick the right tool and not lose direction when programming. Pay more attention to this when developing software for others!

3) Do you have collaborators?

If you have other programmers involved in development, you need to enrich the documentation and annotations. Using the source version control system, carefully write classes and methods to ensure that there is no error.

If there is no second person to look at your code, the documents and comments simply write enough, do not have to reluctantly. Of course you have to make sure you can read it.

4) Source code version control?

Whether the source code can be hosted in the public library depends on its own background, such as whether it belongs to an organization's internal project. If you can make it public, you need to refine the document, add a readme.md file, add a document block to clarify the ownership of the code, and have the semantics of the version number.

If you have intellectual property concerns, you can add a license to limit it.

5) Is it necessary for long-term maintenance?

If you think the program is promising and you think more programmers will be involved, you'll need to use versioning, complete the documentation, and attach the license.

If the utility belongs to an organization's internal project, you may not be responsible for maintaining it for a long time. So let's take care of all the trivia before the programmers in the future put you in the poor programmer 's list.

If the code is well-documented, you'll even get a recommendation (although you can't take the code out of the company, a letter of recommendation can at least prove you're doing well!) ）。

6) Should I create an API or library?

Although the discussion of APIs and libraries is beyond the scope of this article, this issue still needs to be considered carefully as it affects the way code is written.

Is the utility to be written independent or distributed as a library? Or do you want others to access some features through the API interface?

If you choose an API, you must have a solid control of input and output, data validation, data Transformation, security, HTTP routing, breakpoints, and so on. Encryption and authentication are also important considerations.

7) CMF, backend, configuration?

Does the utility need to bring its own management interface independent of the front-end environment?

Does the utility need to be equipped with a backend so that administrators have the appropriate permissions to control?

The biggest problem is that any Content Management framework (CMF) will most likely plug you into a whole bunch of features you don't even have, and you just have to run a utility. But then again, CMF will give you the appropriate APIs and assistive tools, and may also be quite useful.

Otherwise, all the configuration information is saved in a file, allowing only the administrator access.

Most of the time I will create a config.php file, put all the configuration data in the inside, pure manual editing, do not use any interface.

8) package management?

Package management is very pleasing, but that doesn't mean it's not.

If you only need a few libraries, it's just as easy not to use package management.

If you need more than two or three modules, or the modules are very complex, I will use package management.

If you decide to use the composer module (PHP), then I suggest you follow the composer rules to write the utility, so your project can also be managed by composer. Use PSR-4 spec, folder naming, class naming conventions and things like that.

9) front-end frame?

Users perform multi-step operations such as uploading files, filling out forms, reviewing data, visualizing data, and so on, requiring complex front ends. If the front end becomes overly complex, consider using the front-end framework.

When it comes to frameworks, I'm actually referring to CSS frameworks, such as bootstrap,foundation, or even the larger framework of jquery, including more visualization modules and JavaScript plugins.

I like to write CSS from the beginning, and in case the project grows, I might have to rewrite the CSS on the foundation framework.

10) Do I need a log?

Do you need a history log to document the process of using utilities? You need to record for the audit "who did what, when, where, and how long?"

Also, it is necessary to record a log if it is in the company and the utility is used by many people.

Some good log libraries can be found with package management, another reason to use package management, right?

11) Do I need to strengthen the error handling?

Most of the time I write utility software, I do not consider the problem of error handling. I tend to leave all the error prompts open When I write the code, and once all the work is done and the test doesn't find the problem, I just turn off the error message.

Consider carefully whether you really need complex error handling mechanisms, front-end messages, undo functions, Back button management, AutoSave instead of save buttons, popup windows, and modal windows. Also consider whether to connect with the log system.

It is important to note that logs, audits, and error handling should all be part of the pre-standard. This can help you decide how to use package management and frameworks from the start.

12) need to enhance security?

If the utility uses destructive data management or needs to authenticate users, it is easy to enforce security.

I think so, if you need strong security, then use a high-security framework. You can choose a framework that does not have a management interface such as Laravel, Kohana, Slim, Sliex, and so on. You can also choose an interface framework such as MODX, Processwire, and bolts. As long as the framework meets your security requirements.

It is completely unnecessary to reinvent the wheel. Do not implement logs, security, user authentication, database abstraction, etc. Directly with the frame.

13) Do you want to make it public?

Another big question to consider is whether the utility you write is for internal use only, or is it open to everyone on the Web? If the former, the internal means there will be dozens of, hundreds of colleagues in the organization to use your software?

It is important to ensure that the terminal (endpoint) is strictly defined and that any supporting files and scripts that need protection are protected.

If you are concerned that high access traffic can cause problems, you should consider caching mechanisms, especially where you generate databases or highly dynamic data. We also consider security issues, logging, authentication, and so on.

Let's just say that, in general, if it's a realistic tool for ordinary people, use the usual library, tools, methods, documentation, or simply use the framework.

There's nothing to worry about when it comes to releasing a public version, and it's no problem to use modern, reliable modules and frameworks as long as it's strictly in line with the rules.

What about you?

That's what I need to think about before I open sublime or NetBeans to start a new project.

Perhaps you already have a common set of tools to use as a utility. I want to know what they are, after all, big frameworks like Laravel or full-featured cmf/cms are too big to be used as utilities. Are you using a smaller micro-frame that doesn't have a lot of functionality but is sufficient for practical functions?

Original link: http://www.gbtags.com/gb/share/9424.htm

13 recommendations for efficient design of building software