Development team management (transfer)

Recently, I have heard a lot of stories about "project managers" in the software industry. In fact, they are able to build up several technical frameworks for use; or they can easily say what frameworks they have written, and then talk about how frameworks such as struts2 are slow to fool rookies. So I wrote this article to talk about my ideas.



Taobao uses open source, Microsoft uses its own things, Jinshan uses everything, Google, IBM, ORACLE and JBOSS fully support OpenSource. I will not comment on many companies. From the perspective of the final product operating efficiency, Microsoft is the worst, Windows Live is the worst. The series of products are slow and unpredictable (only slightly improved in recent months), but the open source ones are faster than each other; look at Google and Taobao. So, there is no speed or slowness, it's just how people use it.
Whether it is management or technology, there is a culture infiltrated, and this culture and the operability behind the culture can never be learned and understood without personal experience.



Tell us about our company's software development culture.



The first is the most essential thing. As a software company, what do we pursue? The answer is simple: the first is productivity, the second is maintainability (the so-called maintainability includes scalability), and the third is an elite team.
Explain here why 1, 2, 3 are in this order and not others.
First of all, we are a company. As Jack Welch said, the first goal of any company and enterprise is profit, and we can never deviate from this goal; and this is the foundation of all other cultures. A simple example, for a project of 200,000, the cost difference between 20 person-months and 5 person-months is obviously huge, and our goal is to try to compress this person-month figure in order to maximize profits; and maximized profits also means With the salary space of employees and the rapid growth of enterprises. Maintainability means that when team members move and new people join, there can be seamless succession; or when customer requirements change or architecture upgrades, it can be switched almost painlessly. The third point is that the elite team is not looking for a bunch of top students from Tsinghua University, but a growing, sincere, united and pragmatic team. What we want to do is to let a group of smart young people grow into elites, so that they have practical ability and self-confidence, so as to establish themselves in an industry and be respected by peers and customers. Some people may ask, why not mention users? What I want to say is: any company must respect users, and only an elite team can truly provide customers with high-quality products and services, instead of living in complaints and chaotic project development every day.



So how do we achieve these cultures?


First let's talk about productivity. As myself, I like to study various new technologies, but rarely in-depth; as an "architect", I like to promote this research atmosphere. However, research belongs to research. If it is to be applied to the project, there are still principles, such as: A. If the amount of code cannot be simplified, no need; B. If it is difficult to get started, no need; C. If it is unstable, no need; D. Make your own wheels Yes (lack of sustainable maintenance), no.


Based on these principles, among the current popular technologies, we do not use EXT or Flex, because it violates A and B; do not use ibatis, because it violates A; do not use GWT, because it violates B; basically do not use Microsoft's solution, because many MS The solutions are against C; instead of building the wheels by yourself, try to use the standard Spring/Struts2/Hibernate framework as much as possible, it is in consideration of personnel change and maintenance, for details, please refer to J2EE design and development without EJB; I also regret using Mina, because Lack of continuous maintenance, this aspect is obviously inferior to netty and grizzly.


So what do we use? In order to simplify the amount of code, we use the Springside solution, which provides the most simple and practical CRUD and Web paging and complex query solutions; and further uses Sitemesh, which shields the vast majority of developers and HTML/ Opportunity to deal with CSS; this way you don't have to toss between EXT and FLEX; Struts2's Convention plugin provides a simple enough (I think not the most) Web mapping mechanism, which can greatly reduce configuration; Spring provides declarative things (based on Aspectj Or metadata declaration), automatic assembly of object dependencies, and future extensible (exposed service) framework; and a deep understanding of Hibernate can solve storage problems in most cases; of course, we never engage in absolute, special cases Special treatment, I will never abuse Hibernate when the JDBC is directly operated. In addition, proficient in multi-threaded programming, locking mechanism, networking, and low-level IO has become an advantage for the team to move forward quickly in the project.



Of course how to measure it?
For example, Hibernate, the following questions: 1. What is ThreadLocal, and how does Hibernate combine ThreadLocal? 2. Can you immediately tell the relationship between inverse and cascade, the type of cascade and the difference? 3. Under what circumstances will Hibernate generate inner joins and under what circumstances will outer joins be generated? Can it be forced? Under what schema should one-to-many and table joins be avoided?
If you can quickly answer these questions without checking the information, then I believe that you will never hate Hibernate, and there will never be any common confusion in use. For example, Hibernate combined with Hibenrate search and solr can bring us efficient enterprise-level massive data retrieval with the least amount of code.


In addition, in order to improve productivity, we have also adopted the Scrum development model, combined with XP, and respected TDD. From UnitTest to selenium, they are all indispensable close partners for team work (for so many years, we are really tired of the traditional V-shaped model, and a Heaps of documentation), we encourage writing clean code, code is documentation, and comments are requirements. We use CI tools such as hudson or bamboo; use jira or trac to let each member know the goals in each iteration of the project, considering that we are a young team, the release cycle is generally 2 weeks instead of longer; use maven (Partly combined with ant) ​​to do project life cycle management, use firebug to debug and test various web-related content, although it is rarely mentioned, but we are familiar with Linux and various distributed solutions...

It is true that tools and frameworks are Stacking does not achieve the goal, and these practices and the values ​​contained in them must be deeply rooted in the hearts of the people, so that all this can be powerful. The code values ​​we've been promoting since a very early age, such as prioritizing errors, variable naming rules, rules and techniques for writing code, are almost identical to the ones I've seen recently in the thoughtworks collection; these "best practices" constitute The team's pragmatic development concept.
In conclusion, everything mentioned above, new technologies, agile, process improvement, are really all about "best practices" that can generate productivity.

Of course, empty talk is always difficult to solve problems, and technical pragmatism and effective evaluation and proposal are the kingly way. For example, the struts2 performance problem mentioned at the beginning of the article, as our solution, will be: first evaluate the project scale, evaluate the number of concurrent requests per second, use tools such as ab to evaluate the longest actions, and use tools such as jprofiler To find local bottlenecks and solve them (such as lack of optimization of SQL, performance problems caused by multi-table connections, etc.), use ehcache and do gzip compression to deal with network transmission problems.


So with these, does the team have combat effectiveness? The answer is not "no", but "not sure". A stable and efficient team, united, responsible, honest and diligent, trusting each other but not relying on each other, all kinds of excellent qualities must exist in everyone. There are specialties in surgery, but there can be no difference in character. A newcomer can either assimilate or leave. There is no third choice. This is why we prefer young people with more plasticity. How did all this come about? Our principle is that in China, we believe that corporate culture comes from the boss, from the "leader brother", and words and deeds determine everything; therefore, the promotion of middle-level personnel must be absolutely cautious, which will affect the entire company's values ​​and future direction .