There is no need for constraints between like-minded r&d. But rather teach my heart in vain, do not teach silver light to provoke dust. Too much indulgence love freedom, that is gone forever.
This article is a bit of a system of broken words, if there is resonance, clap your hands, oh!
Why do we have norms
Norms are a kind of bondage, the last step of acceleration before take-off. Big companies, free and open source, have complex software that has a very important purpose: to have a say in setting standards for particular solutions; A sign that a technology tends to mature is also the formulation of standards and norms.
Internally, norms keep quality and expectations on track and are the cornerstone of supporting collaboration among multiple people. At the same time, certain conventions have a strange magic that keeps things in order.
Regulation will limit the play of the devil, but will improve the output of mediocrity. The purpose of norms is to make everyone understand normal things with normal minds.
Yes, the norm is to turn you into a nail. Whether you are a grain nail or tapping screw, will use a hammer to knock down! Specification is the emasculation and reordering of functions.
The notorious Ali Tacks, tacks, you see what that means.
You even if again cow force, also give standard press to ground, give the salary also that bear kind! It’s hard to get rich working, I guess that’s why.
Data sources for specification development
The environment
No matter how well designed, it is also waste.
The formulation of norms needs the support of a certain corporate environment, you may be changing the habits of key personnel, there is certainly some resistance. In some companies, there may be a lot of resistance to your specification, and you need to change it slowly. Tokyo doesn’t get hot overnight.
1, are busy demand, no one to regulate. Managers who allow requirements to swell and code to rot are unqualified, both from a software management perspective and for the future of the company. This usually happens in small companies.
**2. During the risk exposure period, fault recovery meetings are held continuously. The first – or second-generation programmers at ** are gone, leaving a hole in their path that becomes your current job. It is difficult to tailor a set of specifications for the system, so consider compatibility.
**3. There are too many vertical departments operating independently. ** Each department thinks its own rules are superior, and you become the ground zero for many quarrel scenarios. Covert observation, malfunction driven.
**4. Outsourcing ** also needs hammer specifications, which are ordered by Party A for you. Don’t ask for the rest and just run.
The data source
Only in-depth business development, qualified for specification formulation. It is not advisable to be self-righteous and insular. No matter how good your ideas are, you may not be able to adapt to another company.
One of the most annoying things about development in a company is that “this is how we do it”. Sorry, our water shallow bastard many, everywhere big brother, don’t eat your this set.
You need to assess the scope of a specification’s impact. For example, if you make a code specification, the object is the lowest level of submissive code farmers, the impact is a little bit less; But if you’re doing a unified specification of the back end, the front end, and the testing, you’re going to have to bear the brunt of all three. So the frog in warm water, not in the name of the specification of the specification, not silicon step without thousands of miles, we have a long time, a long stream.
Entry points for specifications
How to evaluate the implementation of the specification
As a matter of fact, it is better to regulate these things through a top-down coercive measure. Normative review should evolve into a culture, or part of a process. However, the following characteristics should be combined with the specification of the amendment.
**1. Difficulty of implementation. ** If your specification is too complex, hard to remember and implement, and takes up a lot of r&d time.
**2. Number of implementations. ** How many projects are compliant, you need to maintain a general schedule and evaluate the entire implementation cycle.
**3. Objections. Regulation will move some people’s cheese, or the old guard will resist. You need to find a middle ground, not too obfuscating, but accommodating the naysayers. Often, putting their projects last in line for implementation is an easy way to push by percentage.
**4. Effect feedback. In general, specifications advance your work in efficiency, collaboration, and quality. A few “best practices” can encourage the entire evolution process.
Manual review
Organize regular project review meetings to achieve your goals through constant repetition. Identify typical projects in advance and point out constructive improvements to non-compliant code. Be sure to learn about the project in advance. A half-baked review will only lead to doubts about the correctness of the specification.
Automated tool testing
The specification is abstracted into a series of workflows and filtered using supporting tools. Push through through constant negative feedback. For example, collision detection and naming of certain JAR packages can be determined in a continuous integration system. It only takes one or two r&d mistakes, and the deal is pretty much in the back of your mind.
Infrastructure operations and infrastructure are the best places to do these automation tools. That’s why even as an open source solution matures, it needs to encapsulate another layer: you can program against conventions and specifications.
Standardization and promotion of r&d culture
Each specification corresponds to a company culture or represents a different stage of the company.
Companies that tend to be cautious opt for complex processes that restrict the activities of all employees and avoid deviant practices. Such companies will have fewer production accidents, because the battle lines are drawn for a long time, and the work can be completed using the crowd tactics of ordinary employees.
Companies with a lively nature tend to have lightweight process specifications and evolve products by agreeing to conventions through high-quality RESEARCH and development. It is the soil of innovation and responds quickly to new needs.
Valid unions exist as a result of a culture of regulation and r & D.
sample
Example: Publication specification for Feign JAR packages.
SpringCloud makes RPC calls via Feign, and we collaborate by publishing API JARS. But as projects grow, jar package management becomes a significant problem. In order to avoid other online problems caused by version upgrade and change, and to maintain the stability of online environment JAR package, this specification is formulated.
The jar package depends on
Published API JARS should rely as little on other resources as possible. The dependencies section should be as small as possible. Dependencies must be added to the
provided
The name of the JAR package, and what it provides, must be readable: it must be able to guess its function from its literal meaning.
The jar package upgrade
Once a JAR package is released, it must ensure its features of backward compatibility, which are as follows:
** * does not allow the type of a supplied field to be changed from int to String
** * Is not allowed to delete or change fields, such as changing the case of fields
** 3. The service provider needs to deal with the case that some parameters are empty to achieve downward compatibility
** For the changes that cannot be completed by the above restrictions, new interfaces and parameters can be provided to expose the new interfaces. The old interface remains available until it is confirmed that there are no calls
** * Does not allow the use of polymorphic interface extension, please provide a different name!
** Provide clear interface parameters, universal interface is not allowed (old projects can be iterated gradually)
** 7, ** interface changes, must provide wiki documentation
The version number
The project adopts three-stage version management, such as 2.8.15
| Version of the paragraph | meaning |
|---|---|
| 2 | A major release iteration, usually a very important technology upgrade or business refactoring |
| 8 | Major bug fixes and major version iterations |
| 15 | Bug changes in major iterations, in ascending order |
Non-3-paragraph version numbers are not accepted! Jar packages do not accept overwrite distribution, need to upgrade the version number!
The jar package type
Jar package ending with SNAPSHOT
For example, order-api-1.0.1-snapshot. jar, SNAPSHOT is uppercase.
The developer uses the dev account to publish the JAR package, which ends with SNAPSHOT. The jar without SNAPSHOT cannot be published to the private server.
SNAPSHOT is used in offline environment for r&d debugging interface and testing function. Please remove SNAPSHOT before going online and inform SRE to release official JAR package.
The owner of this JAR package has the permission to publish, the dependent project only pulls the latest JAR package, each project member resolves the conflict problem in the development test by himself.
The MVN Dependency :tree command enables you to view all jar packages
Jar package without SNAPSHOT
Such as the order – API – 1.0.1. Jar
If the JAR package ending with SNAPSHOT is used in the online formal environment, the package fails to go online.
Only SRE has permission to distribute this JAR package.
Jar package information maintenance
Because the number of JAR packages is large and their functions are complex, you need to maintain the change information of jar packages.
Currently a wiki is used to maintain upgrade information for JAR packages.
At the end
Regulate this stuff. Don’t move it around. What’s the difference between a small turnbuckle and a big nut?
Hey, I’m talking about you, don’t move the Ali Java development specification, your own code sucks, you really think there is a universal specification.
