An architect with 10 years of Java experience talks about Java and work experience

Engaged in the development of JavaEE applications for nearly ten years, and now is the system architect of alibaba company. In-depth research on distributed service architecture and big data technology, rich experience in B/S architecture development and project combat experience, good at agile development mode. One of the domestic open source software promoter, founder of Smart Framework open source Framework. Love technical exchange, willing to share their own work experience. Author of Architecture Adventures: Writing Java Web Frameworks from Scratch.

My 10-year road to technology

Let me tell you a little bit about my current work.

I am currently engaged in the design and development of distributed service architecture and application development on Ali’s big data platform. Our entire system architecture adopts the idea of “front and back end separation”. The front end focuses on data presentation and the back end focuses on data production. The front and back end are integrated through REST services, so that all applications are stateless and can be extended horizontally. We will split into many “service”, the whole system between services through a unified interface to invoke, each service is through a container technology in isolation, and services can be published to the unified management platform, through this platform to monitor running status of each service and life cycle events, and provides the service the caller’s ability to service discovery, Services can be smoothly upgraded.

Ali has many excellent middleware and basic services, which can quickly help us build application systems. Moreover, all these technologies are open source in Ali, so we can learn a lot of valuable experience through source code and documents. Ali also provides a strong technical atmosphere. Every student is very focused on their own field of work. We are meticulous in our work and cooperate with each other in the same direction.

How did I get into technology?

When I graduated from university in 2006, I left my Alma mater wuhan University of Technology. With the recommendation of the dean Xue Shengjun, I came to Shanghai, a very strange place for me. I was lucky enough to join a start-up company named momentum Software. The boss of this company used to be the CTO of Asiaincia Technology, and he is also the founder and CTO of Puyuan Software. His name is Huang Liuqing, who is also a college classmate of Teacher Xue. So my boss became my teacher, and I used to call him Miss Huang. Other senior colleagues in the company also became my teacher, because I wanted to learn more valuable things from them.

What did I learn about cloud computing when I started? What are SaaS, PaaS, IaaS? We spent three years developing a PaaS platform called ODE that allows users to customize their software and ultimately provide customers with saas-based products. At that time, we were already doing cloud business, but WE didn’t expect that cloud would get such a good market in China. Maybe Teacher Huang was the only one who thought of that.

In 2008, I made my “first bucket of gold” for the company, a milestone in my transition from programmer to project manager. At that time, I led a team to shenzhen to develop the broker management system for Guosen Securities Co., LTD. This project was a supreme asset for me. I began to learn how to deal with people, how to do demand analysis, how to transform demand into technology, and how to lead my team mates to work together. I learned so much, but I still chose to leave Momentum software in my fourth year. When I first joined momentum Software, there were only 5 people in the company (including the boss and the receptionist), and when I left Momentum Software, there were about 200 people in the company. Thanks to Miss Huang! I learned so much from him, and his ideas and attitudes still influence me today.

In my second job, I chose the securities and financial industry that I am most familiar with, which is also a start-up company. In this company, I served as the technical manager and managed the whole technical team. I personally led the team to complete the project from pre-sale to after-sale. Although I only worked in this company for two years, in this short time, I learned how to improve the development efficiency, how to cultivate the technical team, how to select technical personnel, how to establish the corporate culture. But at last, I found a problem. The more I wanted to do well, the more difficult it was to do well. In order to accomplish one thing, I needed to make a lot of attempts, and there was a lack of correct and effective methods to do things.

Looking back on the first six years of my career, I grew up in a startup company. Although I could learn things quickly, it seemed difficult to learn a more standardized way of doing things. Therefore, I chose a new job opportunity and came to TCL Communication, which is a fairly large company. The r&d management process of the company comes from Alicat In France. I worked as a Java architect in the company and was the technical lead of the entire Java team, although the team was not particularly large. I worked in this company for three years and learned how to integrate existing resources, how to do things according to standard procedures, how to design system architecture, how to work in different places, how to work across teams, and how to communicate in English. To be honest, I didn’t have any work pressure, could get to work on time and never worked overtime. I had a lot of free time, but instead of wasting it, I started writing tech blogs, and those tech posts changed the course of my career.

I clearly remember that on September 1, 2013, I published my first blog post “Smart Framework: Lightweight Java Web Framework” on the website of open Source China (http://oschina.net), which influenced me for the following two years. To be honest, when I first wrote this article, I had no idea. The framework was just an idea based on my own understanding, not even a line of code had been written. My idea is to publish this idea first and let everyone discuss it. I will make a decision and then implement it myself. Finally, I will show the implementation process to everyone through blog posts. The whole open source process is very much aligned with agile thinking, communicating effectively, taking small steps, embracing change, and constantly improving.

It may be that my technical articles have attracted a wide readership, which should include other companies that want to invite me to join them. I left TCL Communication and joined Yi Media in 2014. Why would I want to give up such a comfortable working environment to join a company that is still struggling? In fact, what I see is the development trend of the Internet in the future, the combination of programmatic trading of advertising and big data. The most valuable thing in the future will be data. With such confidence, I joined E-Media as a system architect. At that time, Yi Media was in the early stage of technical transformation and needed to migrate all.NET to Java, which was very challenging for me. My approach is: the first step is to define development norms and processes, the second step is to cultivate core technical personnel, and the third step is to carry out transformation in stages. In just six months, all of our products were successfully migrated to the Java platform, and the results were beyond everyone’s imagination. The company’s market is also very good, the products have been recognized by the industry, the number of orders continue to flow, everyone is very busy every day, but very happy. I am deeply moved by the “Yi Family” corporate culture of Yi Media. No matter the core technical department or other supporting departments, we are like a family, and your business is my business.

Until early 2015, alibaba has established cooperative relations with easy to media, the two companies, has carried on the depth of cooperation, media companies and ali mother group consolidated, new ali mother was born, so I became a member of alibaba, currently responsible for ali mother big brand marketing the system architecture of product data. In the process of the integration of the two companies, I finished first in life “- from scratch to write Java Web framework architecture expedition” this book, the book is the major online bookstores, I sincerely hope that this book will to some want to be the architect of the programmers help, because of my personal level is limited, it is the first time to write a book, Please forgive me for my bad writing.

As mentioned above, I’ve learned a lot from blogging, so I’m going to share with you how tech people blog and how they should approach it.

I think there are a few things that technical people should pay attention to when blogging:

Thinking should be clear, the article should have a clear outline and title.

For actual combat type articles, need to be described step by step.

Use more short sentences, less long sentences, can say it in one sentence, do not use two sentences.

For the difficult to understand the content, it is best to illustrate by analogy.

At the end of the article, there should be a summary, which summarizes the main content of the article in the most incisive language.

Writing a blog is first of all a summary of what one has learned, in addition, it also provides a good tutorial for other readers, and the knowledge is broadcast and passed on.

Technology is a road of no return, chose this road and never gave up the idea.

I have been working on technology for ten years, and I have never given up on it. On the contrary, I love it very much, because I always like learning and hope to learn more. In this way, when I encounter specific technical problems, I can find the best solution from my knowledge base at any time. In addition, although I don’t write much code in the company now, I still use my spare time to write some open source projects or code frameworks.

I have worked for many companies, big and small. What is the most valuable thing in a company?

I think it’s the programmers who actually do the work.

Although their salary is not high, they sit at their desks and type code every day, they are called “diaosi” or “homebody” in the eyes of many people, but I think it is these people who are the most valuable people in the company.

• They have their own ideals, hope to be able to through their own efforts, from which a little bit of the so-called sense of achievement;
• They need to understand what the product manager is really trying to do, to turn the idea into reality, to get the product off the ground;
• They have a better grasp of the details that often determine the fate and success of a product;
• Their sudden job-hopping has a direct impact on our project delivery;
• The atmosphere in which they work together reflects the culture and heritage of the technology company.

From this point of view, it is quite necessary to pay attention to programmers, we need to care about the career development of every programmer, so that they can give full play to their abilities in the team.

We also need to pay more attention to them. We need to find competent, hard-working, responsible people and give them more opportunities to become technology leaders.

Internet technology companies need a lot of these programmers:

• They are people who believe in technology, they are people who love programming, they are people who can’t sleep well without solving problems;
• They’re not handymen, they’re not outsourcers, they’re not tools;
• They don’t like being fooled, they don’t like being left out, they don’t like being driven;
• They need respect, they need cultivation, and they need passion!

Tell me specifically what qualities a programmer needs.

Here’s what I personally know about real programmers:

1. I love technology. If I don’t write code for a day, my hands will itch. I like the sense of accomplishment.
2. I can sleep and forget about a problem, sometimes I can write code in my dreams.
3. Code cleanliness freaks, who love elegant code and write code like poetry;
4. Good at analyzing problems, can quickly see the nature of the problem, and start to solve it;
5. Like to study excellent source code, master’s masterpiece, good at induction and summary;
6. Have your own open source project or technical blog, like to learn, more like to share;
7. I will pay attention to the news trends in the technical circle and often participate in the offline technical salon;
8. Knowing that software development is not a one-man operation, but a team effort;
9. Keep a good and healthy attitude and embrace change with a positive heart.

Ten years of career is not easy to adhere to, share my experience of “IT career”.

Time flies, and the first decade of my career is over. In this decade, let me gain a lot, share with you some of my personal experience in the IT workplace, not necessarily practical for everyone, please only for reference.

Since everyone is doing technology, then we might as well start from the topic of technology. The first lesson I want to share with you is this:

1. Use technology as a tool

Technology is not a mystery at all. It’s just a tool that helps us solve real problems. It’s as simple as that.

We are facing technology every day, and there are many technologies in the market. There is really no need to take all these technologies and learn them, and then try to find a scene to apply it. If it does, it just means that technology is not a tool, it’s a toy, and that’s not how technology works.

We should look at technology from another Angle, might as well set out from their actual working environment, what we need now, we learn what, rather than aimlessly pursue some new technology. Of course, we still need to pay attention to the new technology, at least we need to know what this new technology is for, and we should be good at summarizing, collecting valuable technology for future use, and then conducting in-depth research when we need to use it.

Human energy is limited, human life is also short, to be good at using their own time, reasonable learning technology.

Don’t take technology so seriously, don’t take it seriously, take it as a tool, it is like the pen that we write with, a pencil can write, a pen can write.

As a technician, in addition to learning and applying technology, I also need to make a correct career plan for myself and have a clear understanding of what kind of technical personnel I belong to, whether I am a technical expert or a technical management type. What’s the way to go? You need to make your own decisions.

In our career path, the most important person is the boss (I can refer to the boss can be the big boss of the company, or my immediate boss). I also have some experience with my boss:

2. Treat your boss like a lover

We should be very clear that lovers need romance, romance needs surprise. Bosses, like lovers, need surprises. As subordinates, we need to know how to find the right opportunity to surprise the boss. We love our lover, which is a good way of communication, but don’t ignore the boss “love”, we need to keep good communication with the boss, this communication is not just curry favor.

Tell a true story. I remember once having a colleague of mine who was very skilled and quick in making things with high quality. His colleagues all thought he was an excellent person, but he never knew how to show himself in front of the boss. The boss just thought he was capable of doing things, but he was often not given priority in promotion and salary increase.

The inevitable question is: How do you present yourself to your boss? In fact, there are many methods, due to the limited space, I will provide three tips:

• The first trick: when giving the boss a program demonstration, not just a simple demonstration, might as well use a PPT first, simply express their solutions, and then do a demonstration, so the effect will be much better. Your boss thinks you’ve put some thought into doing things better.
• The second idea: keep a brief record of your daily work, summarize it once a week, and send it to your boss in the form of an email, so that your boss knows what you are doing every day. Write a monthly summary of your work for the current month and a plan for the next month. Also send an email to your boss. Write a year-end review at the end of the year, print it out, and quietly leave it on your boss’s desk.
• Third recruit: borrow report work for reason, invite boss to go out to have a meal regularly, manufacture face to face alone communication opportunity. During the conversation, emphasize your willingness to help your boss lighten the workload. “> < p style =” max-width: 100%; clear: both; min-height: 1em; Your career will take off when your boss takes care of it. But don’t forget about the other group of people, they may be your team mates, they may be your competitors, yes! They are colleagues. How to deal with colleagues? Here are my experiences:

3. Treat your co-workers like children

Dealing with colleagues is actually a little more complicated than dealing with the boss, because colleagues can be many things, they can be teammates, they can be rivals. If people are working on the same project together, they are teammates; If in order to compete for a project, post, or resource, there is competition among colleagues at the same level, then such colleagues are rivals.

For teammates, we should learn to take the initiative to help them, so that we can experience the atmosphere of teamwork, learn together, grow together, and share together. You can have a dinner with everyone and buy snacks for everyone to enjoy.

Teammates are often easier to deal with, the key is to really know how to share. Many technical personnel, the most reluctant is to share, because they worry that they spent a lot of energy to learn the knowledge, minutes will be learned by others, they lose their advantages. This mentality is best not to develop in the team, this will only make you become more and more isolated, smaller and smaller, teammates will gradually marginalize you.

For the opponent, to find a way to make himself his brother, tell him that we are brothers, should help each other. If you have the opportunity, compliment your opponent in front of your boss and your opponent. Do such behavior, in fact, will not let the boss feel inferior to the opponent, but will let the boss think that they are trying to accommodate the opponent. We work together, is a kind of fate, are working with the boss, there is really no need to make unpleasant.

In fact, colleagues are their own partners, might as well treat them as simple and lovely children, with their own heart to “buy” them.

Bosses and colleagues, they’re all inside the company, so after all, we’re all in the same boat, and we can close the door and have a fight, as long as it’s resolved. But for our clients, it takes a different approach. Here’s what I think:

4. Treat customers like patients

Customers have needs, but they don’t have the technology, and we have the technology, the experience and the product to help them fulfill their needs, so that they can work more efficiently, so that customers will be willing to put money into our pockets. Therefore, in front of customers, we should show superb professionalism, do not be led by our nose by customers, we are the technical authority in front of customers, we need such confidence. Be professional in everything from clothes to words and deeds to emails and documents.

When we are going to sell our products to customers, we should not talk about our products at the beginning, which often makes customers feel bored. We might as well tell customers that they have been “sick”, and very sick, if not timely medication, the consequences will be unimaginable. In other words, we need to make the customer aware of the dilemma they are facing, make the customer nervous, and then tell them that the “medicine” is ready to take when they are thinking about how to deal with it.

To let customers have a sense of help, so that is right, they will take the initiative to understand our products. To do all this, we must spend our energy analysing the state of the industry and wondering what our clients’ bosses are thinking on a daily basis. If you have the opportunity to work in a client’s company for a period of time, I believe my feelings will be more in-depth.

Java will be mainstream for a long time

Why is Java Web development all about frameworks?

Personally, I think frameworks have the following functions:

1. Make development more efficient, shield the underlying technical details and let developers focus on the specific business.
2. A framework is actually a specification that allows every developer to maintain the same coding style.
3. Developers who can use mainstream frameworks are more readily available in the job market.

What frameworks are used for Java Web development today?

Commonly used such as Spring MVC, Struts2, etc., domestic JFinal, Nutz, etc., is also good, of course, Smart is also a good choice.

If you have some experience with Web front-end development, a lot of people will think, “Wow, those frameworks guys are awesome. When am I going to write my own framework?” Sometimes I look at other people’s framework code and feel it is very complicated. I have some suggestions for this and what is the basis for beginners to learn? Share some good tips.

For those who have not been exposed to Java for a long time, it is recommended to follow the following steps to learn:

1. Learn basic Java syntax and core technologies, including Servlet, JSP, JDBC, etc.
2. Familiar with popular open source frameworks, including Spring, MyBatis, etc.
3. Study the source code of open source framework and absorb the excellent architecture.

In addition, in the process of learning, it is recommended to take study notes, the best way to record their own harvest through the blog.

What are the advantages and disadvantages of developing Web applications in scripting languages such as Python, Perl, PHP, and Ruby compared to developing Web applications in Java?

The former is a dynamic language, without compilation, it can be run by interpretation, and Java needs to be compiled first, the source file into bytecode, and loaded into the Java VIRTUAL machine to run. Relatively speaking, Java has higher requirements for the environment, but Java has stronger object-oriented capability. In addition, Java has a wide open source community and popular open source middleware. Therefore, if you are building a large system, it is recommended to use Java for development rather than those scripting languages.

What is the best future for the Web, Java, PHP, Python,.net?

I think Java has a long way to go in the future. It needs to be more lightweight in the language itself, with minimal code to achieve the desired functionality. PHP is relatively smooth, it has great features, it is fast and easy to develop Web projects; Python still won’t have a large user base; .NET was late to the open source community and doesn’t have much of an advantage over Java, so it could go downhill.

There are many design patterns in software development, and some are very cold. Let me talk about my understanding of software design and keeping some design principles grounded.

Those of you who understand design patterns have probably heard of the “Six Principles of design”. In fact, the most classic 23 design patterns use these design principles more or less, that is, design patterns stand on the basis of design principles. So it’s important to understand these design principles before studying design patterns.

GoF (Gang of Four), the legendary four gods, they worked out a set of design mode, can be called OOD (object-oriented design) classic! Shook up the software development world. But these four old guys are very strange, always like to show some advanced theories, sometimes even silent, very confusing.

In addition to the six most classic design principles, there are a few other design principles that are also very important. I’ll explain these arcane theories as best I can, hopefully leaving you with a little more understanding of these design principles. If there are incorrect places, please correct!

• Six Design principles

Here’s a picture:

The picture clearly expresses six design principles, but only by their names. What do they mean? Below, I will elaborate from the four aspects of original text, translation, understanding and application respectively.

1. Single Responsibility Principle – SRP

译 文 : There should never be more than one reason for a class to change. There should never be more than one reason to change a class. Understanding: There should be only one reason for a class to change. In plain English, different classes have different responsibilities, each with its own responsibilities. This is like a team, everyone division of labor and cooperation, without influence, each do their own things. Application: When designing a system, if you find a class that has two responsibilities, ask yourself a question: Can you split this class into two classes? If it’s really necessary, let it go. Never let a class do too much!

2. Open Closed principle-OCP

原文 : Software entities like classes, modules and functions should be open for extension but closed for modifications. Software entities, such as classes, modules, and functions, should be open to extension but closed to modification. Understanding: In short, open to extension, closed to modification. In other words, extend the class, but don’t modify it.

Application: When requirements change and you need to modify the code, you should try to extend the functionality of the class by inheritance or composition rather than directly modifying the code. Of course, there is no need to make things complicated if you can ensure that there is no impact on the overall architecture. Just change the class.

3. Liskov Substitution principle-LSP

The original: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 原 文 : A function that uses a pointer or reference to a base class must be an object that can use a derived class without knowing it. Understanding: A parent class can replace a child class, but a child class may not replace a parent class. That is, you can replace all of your parent classes with subclasses in code without any errors or exceptions at runtime, but the reverse is not necessarily true. Application: When inheriting a class, be sure to Override all methods in the parent class, especially the protected methods of the parent class (which are often overridden). Subclasses should try not to expose their public methods to external calls.

This principle was developed by Barbara Liskov of THE Massachusetts Institute of Technology, the first woman in the United States to receive a PhD in computer science and a Turing award winner.

4. Least Knowledge Principle – LKP

原文 : Only talk to you immediate friends. Only communicate with your immediate friends. Understanding: Minimize interaction between objects to reduce coupling between classes. In short, it must be: low coupling, high cohesion. Application: when doing system design, do not let a class depend on too many other classes, need to minimize dependencies, otherwise, you will not know how to die.

This principle, also known as the Law of Demeter, was developed by Ian Holland. This person is reluctant to talk to strangers and only communicates with friends who are closest to him.

5. Interface Segregation Principle – ISP

译 文 : The dependency of one class to another one should depend on The smallest possible interface. 原 文 : Dependencies between one class and another should depend on the smallest possible interface. Understanding: Do not expose interfaces that have no real meaning. In other words, the interface is for others to call, so don’t make it difficult for others, and keep the interface as practical as possible. She’s fine, I’m fine. Application: When you need to expose the interface, you need to think twice, if there is really no need to provide external, just delete it. Once you provide it, it means that you have one more thing to do in the future, so why bother to find something to do for yourself?

6. Dependence Inversion princip-dip

The original: High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. High-level modules should not depend on low-level modules, they should depend on abstractions. Abstraction should not depend on details, details should depend on abstractions. Understanding: You should program for interfaces, not implementation classes. Implementation-oriented programming is equivalent to talking about things, which is positive dependence (normal thinking); Programming for interfaces is the equivalent of looking at things from the outside, which is reverse dependency, or dependency inversion (programmer thinking). Application: This is not to say that every class should have an interface, but to say that if there are interfaces, use them to program as much as possible.

When the first letters of these six principles are put together, they form SOLID, so they are also called the SOLID Principle.

Only by meeting these six principles can a stable software architecture be designed! But after all, they are only principles, just the gang of four to give us advice, sometimes we still have to learn to be flexible, do not copy mechanically, otherwise it will only complicate simple problems, remember!

• Supplementary design principles

1. Composition/Aggregation Reuse Principle – CARP

When extending the functionality of a class, use composition over inheritance. This principle is frequently used in 23 classic design patterns, such as the proxy pattern, the decorator pattern, and the adapter pattern. Visible river’s lake position is very high!

2. Acyclic Dependencies

Cyclic dependencies occur when module A depends on module B, module B depends on module C, and module C depends on module A. This problem should be avoided in your design and can be solved by introducing the “mediator pattern.”

3. Common Closure Principle – CCP

Mutable classes should be placed in the same package to isolate changes. This principle is an extension of the “open-closure principle”.

4. Common Reuse Principle – CRP

If you reuse one of the classes in the package, you’re reusing all of the classes in the package, so keep the package size as small as possible.

5. Hollywood Principle-HP

Hollywood agents are usually very busy. They Don’t want to be disturbed. They often say: Don’t call me, I’ll call you. Don’t contact me. I’ll contact you. For software design, the most famous is “inversion of control” (or “dependency injection”), where we don’t need to actively create objects in the code, but rather let the container create and manage them for us.

• Other Design Principles

1. Don’t repeat yourself (DRY)

Don’t have duplicate code lying around, make it reusable enough, so encapsulate it as much as possible.

2. Keep it simple and stupid-kiss

Don’t let the system become complex, simple interface, functional practical, easy to operate, to make it simple enough, enough fool.

3. High Cohesion and Low coupling-HCLC

High cohesion should be achieved inside the module and low coupling degree should be achieved between modules.

4. Convention over Configuration-COC

Try to use conventions to minimize configuration, so that development is more efficient and “zero configuration” is possible. Many development frameworks do this.

5. Command Query Separation (CQS)

When you define an interface, try to define what is a command and what is a query, and try to separate them, not lump them together.

6. Separation of concert-soc

A complex problem is solved by breaking it down into simple problems and then solving those simple problems one by one. The difficulty is how to separate.

7. Design by contract-DBC

Interactions between modules or systems are contract-based (interfaces or abstractions), not implementation-dependent. This principle suggests contract oriented programming.

8. You don’t need it.

Don’t start with a complex system and don’t fall into the trap of “over-design.” The challenge is to keep the system simple, yet extensible.

A successful project is inseparable from everyone’s efforts. Please share my experience in project management.

Here are 10 suggestions and goals:

1. On the first day of the Sprint, goals need to be clearly defined and made known to everyone on the team to “ensure consistent and clear goals are established”;
2. In case of any change in requirements, it will be prioritized to the next iteration. In special cases, special treatment is required to “ensure the completion of this iteration on time”;
3. The Scrum Master breaks down the requirements in the iteration into tasks, with only one task leader per task and no more than one person per day “to ensure that the daily tasks are evaluable”;
4. Have the Product Owner identify requirements directly with relevant developers, and the Scrum Master be involved in “ensuring that requirements and implementation do not deviate”;
5. The duration of the daily timed station meeting should not exceed 15 minutes and the scale should not be too large. “To ensure that the task is completed in accordance with the plan”;
6. Conduct a code review once a day, with the Scrum Master in charge, and inform the relevant developers of the review the next day to “ensure code quality does not deteriorate”;
7. Each team’s Scrum Master communicates once a day for no more than 15 minutes “to ensure project management is not at risk”;
8. At the end of each iteration, give everyone a break and offer some group activities, such as dinner to “make sure the team is more cohesive”;
9. The Scrum Master needs to “make sure the team is more passionate” with promises such as project bonuses or special benefits;
10. For employees with emotional abnormalities, the Scrum Master should communicate with them “to ensure that one person’s emotional state does not affect the whole team”;

In addition, as a project manager, you need to constantly reinforce the following five cultures in your team:

1. In the same direction
2. Face to face communication
3. Full engagement
4. Fully trust
5. No sooner said than done

True open source is not just open source code, but open source ideas

Talk about my view of “open source”, how is the domestic open source now, compared with foreign countries?

In my opinion, the real open source is not just the open source of code, but the open source of ideas. Before working on an open source project, it is advisable to share your ideas rather than keep them to yourself. I have no objection to “reinventing the wheel”, because we need better wheels and better wheels to make cars go faster. Wherever there are advantages and disadvantages, we should not blindly choose open source technology, because it is not suitable for others, but according to their own needs, choose the most suitable open source technology, to build an appropriate architecture.

There are a lot of new technology, the first thing I will go to pay attention to it, to know what it is, what can solve the problem, but I never go to further study of it at the beginning, more won’t go to look at its source, because once met this aspect demand scenarios, I will be from the “knowledge base” to find the best solution, if still can’t find the most suitable open source technology, I’ll try to do it myself.

The way home for the techies

What’s the way back from technology? Whether to transition and how to choose?

At least several routes can be taken, such as: in-depth technology, transformation into products, transformation into management, etc., need to choose according to their own strengths and personality, do what you like.

From technology to management, I have high requirements on myself. To be specific, I need to look at my emotional intelligence, experience in dealing with people and communication skills. I also need to be open-minded enough to tolerate some things and have enough personality charm to attract others and make them willing to work with me. Some things about management are hard to learn from books, but some classic management theories must be learned.

It’s easier to move on to technology or from technology to product, because a lot of the time you don’t have to deal with people.

An architect with 10 years of Java experience talks about Java and work experience – CSDN blog