Fast, low-cost completion of the development of innovative companies how to do

As a software engineer, the past few years have been dedicated to web development. In innovative companies, speed saves time, money, and money to ask more engineers to make the whole development faster. The school does not teach many "software engineering" methods, or how to be a good programmer. These things do not exist in the Taiwan industry, we are doing side touch, learn from experience. I've learned a lot from books and the internet about ways to make the team more productive, because I believe I have to do it first in the new team, in a way that the industry recognizes as fast and as fast as it can. Here is a share of my experience.

1. Let the whole team use a mature development framework and environment:

My specialty is Ruby on Rails. I don't have a preference for referrals. If you are using PHP or. NET or JAVA, you must import the new framework regardless of cost. Like I don't really like hard to import Scala or node.js. They can be added to the place where they are used, but they must not be the subject. The truth is simple, I don't think they are ripe enough for all the members to get started and not reinvent the wheel.

The general team likes to use PHP. Because the PHP engineer is easy to find, the Rails engineer is not looking. But as I walked down the experience, I thought it was a "false proposition". Because in the human market and the actual operation of the company, you will find this proposition is not very reliable. Yes, you are looking for a PHP engineer, but I'm sorry, a lot of people write code is not used (more accurate is write only) of the majority. (I don't mean to offend PHP developers)

Because the development of PHP is not too many of the rules of consistency, basically is how to write love how to write. This leads to the lack of usefulness even if you have a very powerful developer in your team. Because everyone job style is different, and even the structure of the site is not the same. Complement people almost no way to play to add to the role, we can only write their own, even if the explosion and almost only the original author can repair.

This is a great waste of team fighting in my eyes.

Does rails have a situation like this? This is where I find the rails advantage, it's a very popular Framework (only in Taiwan you may not feel like he's hot). Because this is a set of frameworks, that is, it itself has a strong binding, at least the MVC and routing rules, generally, even if the novice is not too outrageous. There are some unspoken rules for writing code.

When anything happens in development, developers can almost use Google to find any possible cause of the plateau, repair completed. And this is almost not the general self-built framework can be compared to the place, if you build a framework for the company, basically any problems, and finally almost have to bother with the original design of the Architect. (This is also a waste of money, because Architect's salary is very expensive).

The learning curve is too high, and I don't think it really exists. Rails pros are hard to find, but the productivity of rails with low hands is amazing, as long as they're properly trained. So as long as the focus on how to help the general want to get started, you can quickly overcome the entry of the threshold (to deal with the development environment, Restful,plugin,debug,deploy), the rest can rely on the Internet teaching materials and combat training. That's the reason I invented Rails 101.

I designed this set of textbooks to get all the new developers in the longest two weeks to learn basic Linux instructions, Git, Rails, all the basics of knowledge, the department, Scss writing, and so on, within one months to go to the battlefield with us to develop new Web site features. Is this a very dramatic progress? No, no exaggeration. Every developer here has this level, and some of them will not even be able to write in Rails. Can you believe that even the PM and ART of the T-state can they write Rails? (No kidding)

How do you write code rules? My colleagues and I have absorbed a lot of best practices from the community, and we've sorted them out into novice guides, best-practice, even gems and generator, and the less advanced developers will be able to catch up with seniors, In a short time, their work can be as advanced as the predecessor of the best practices. I've also been writing another book recently Essential Rails for beginners

Rails itself has plenty of ecosystem, and the default architecture best practices are not to mention.

The new team resources are few, the personnel budget is not so sufficient, but the ingenious use of natural resources and let the group combat force *3.

2. function design for the current use, consider a certain degree of extensibility:

I do not believe that anyone in the new team can predict the future, even if many things seem to expand in that direction in the future. For me, I do not overthinking in the design function, even I forbid colleague overthinking. Because the highest plateau in the project is get things done,not.

But this does not mean that there is no need to stay in the design of a certain degree of expansion, in the internal workflow is usually the last one has refactor to clean up space. At this point colleagues will put the messy code, back to the original rules must be written. If this is a common feature, it must be sorted into a Library, or schema pattern, repeatedly. One but pattern, the expansion is left.

After the new project, you can take the previous case and use it repeatedly. Even finally have the Event generator this kind of thing ... (Authenication, Rails Admin, SEO, ... etc).

3. The program itself is registered

In general, software practice itself is not in favor of writing a solution. But to encourage the program itself to be able to express its own behavior. If you write a messy program that people can not understand, into the review will be back to ham. The programs that our team can be accepted with are awkward to write, but every colleague can read it. Because clumsy but understandable, other seniors have time to refactor. But after writing, no one can move.

4. Try to write down all the documentation

No one in the world can write a complete system architecture book to describe in detail what is really going on on the system today. But a good issue tracking system and write commit log can help you understand why the system is now designed to do so, and why the decision was made so that the program had to be designed.

During the new training period, I usually train new recruits to have the habit of having any detail and status detail on the ticket. While completing the entire project or a prototype of the technical architecture, take notes on these ticket.

This will have a very strong positive effect on the extent of the team's leap. At the same time, when people flow (new or quit, the shock will be very very small.)

Because at least a lot of "basic" education costs, in this part will be nearly 0. All the way through the practice of startup, I understand one thing very early, the flow of people is almost inevitable, so it is important to make the impact of people flow less.

It is also expensive to invest in a new technology for colleagues in the venture. Therefore, if you want to learn, we must all be able to, otherwise it will always be very expensive.

This is the value that documentation can bring.

5. Test environment and policy

What I learned from the expensive lessons is that there must be a test environment and policy. It's not difficult to cut your environment into several pieces in Rails. And there must be a test environment (staging), because everyone developed a different environment, in the current focus on their own computer, many of the design will not consider so much. You will know that blowing up a large or configured is extremely bad when you leave remote server. It's all about hurting business credit or screwing up a deal (say you're talking to a client about a hundreds of thousands of ad for tomorrow on file, but tomorrow because of a human error), who would you like to move the queue to him? Who wants to do business with you?

As for policy, it's more important.

A lot of overtime is actually unnecessary. For example, when the mind is not sober, wrote a bad code commit up. To clean up the mud when you wake up. Before eating or before work deploy the latest version of the code, the result of noon back station for several hours, the Yuan Ben can work, 10 points will not go.

But writing a good thing does not directly commit master and not immediately deploy makes RD very itchy. I can't survivors this disease.

But the commercial web site is not a fire all the way, the team or someone to defend the overall situation. So in the end, we have to implement this rule:

Write function on feature branch

Must use staging server before the line, apply feature branch to test round

Absolutely not at 11 o'clock noon-12:00 deploy, absolutely not after 17:00 deploy.

Deploy processes must be automated with tools to rollback.

After executing such rule, almost no one needs to fix bugs on an empty stomach, and in the middle of the night, I jump up and work overtime because of software problems.

Because I am convinced that a long time in the fire/fire environment, will quickly reduce the strength of a team.

The devotion of blood is usually a false impression, the higher the working hours I devote, the better the results will be. In fact this is a complete pseudo proposition. and entrepreneurial initial instability, busy, fire, more so you will have as long as I work overtime, all the illusion of improvement. Adrenaline can only hold you for three months, and then everything will be shattered. To make a website to be able to play, everyone is longer than life, not Startup weekend champion.

6. PM words to listen to when the reference is good, but to communicate well

In many cases, PM may be planning a scenario a that takes 10 hours. But you know you can change it to plan B, it only takes 3 hours. But the premise is, you have to be good to ask, why he will make A design case. There is no denying that Taiwan has a professional quality of the PM extremely rare, can meet one is to burn incense. So to a large extent, it may be a person who will only copy the composition of other Web sites, or sales of advertising, but it does not matter. The important thing is that you ask why this is so designed, because his layman's level may let him estimate a company to make a serious loss of the actual crime, you did not stop him. Or the case structure is a reasonable company direction, but you have misunderstood the design of the yuan is not modified without authorization:

A design will be so designed behind the plateau because there are many, may be:

PM on the road casually copy

PM likes to do that.

ART Requirements

Customer Requirements

This is key feature, must do this, otherwise lose this system meaning

So you can't be yourself like B on B. The development of a system must have "cost", "expected revenue", and the implementation of the scheme to find the balance between the two. This is by communication and communication ...

7. To write a certain level of code

To use CSS architecture to design Web pages, do not misuse ORM, do not reinvent the wheel, do not write code that will be on business, these are basic development knowledge. A lot of new websites write the first edition quickly, but then fell into the development of the mud, can not cooperate with the business model rapid adjustment, almost 90% of the yuan because the first version of the original code rotten to the beginning of the developers themselves are not too moving, the result is the subsequent adjustment of the framework for small revision will consume more time, become an oversized fatal injury.

8. To pursue a certain amount of web page efficiency, tune on the Edge

Not pursuing efficiency is a very strange word.

There is no denying the fact that some developer performance and Fancy technology are going too far, such as even writing the entire site with backbone, or using Node.js to write the site from beginning to end. It's all about writing a mobile Web service to mobile phone for a start. Because of the 3G latency is too large, to try to compress bandwidth usage and the pursuit of page response time.

But the implementation of a Desktop version of the site is completely unnecessary. And in website configured tuning, priority is also frontend configured, because the c/p value is much higher, compressed CSS may be saved 3 seconds. DB or programming language tune may only save 0.1 seconds.

And the site's indicators and User Experinece is not said to open a good taxi. For example, the speed of the site will directly affect Search Engine and Alexa rankings, do not know how many people know? There are general users of blog/album and video can endure response time is different, video we can endure a 5 seconds is not open to accept, but albums and blog open a page to 5 seconds This is probably no one to use it ...

The effectiveness of the adjustment of this matter, too and less than are bad things.

9. Less use of Fancy things, before the implementation of the first estimate of costs and benefits

As a developer, there are a lot of new good things coming out of the world every day, and it's itch to not play. But in fact, every introduction will have a certain cost, and the benefit/cost ratio is not necessarily what you thought.

For example, keep track of the new version of Rails, replace the performance of a good Ruby 1.9.2, instead of Scss to write CSS, instead of Coffeescript to write JavaScript. Apply the newly invented Asset Pipeline architecture. These are all very new and wonderful things. (T guest states have, the structure from the earliest 2.3.2 has been upgrade to 3.1.3, the inner pedestrian only know how big the project)

But the truth with other things is the same, new things have new risks. And usually the introduction of these things, not a person to enjoy the good, is what everyone needs to use.

So usually I do this: First branch a version, or I'll ask senior RD to go down and do the whole thing or evaluate it, and make sure it's workable and then put it into a workable SOP. .

If it's a new idea, try it on an event or a small page.

Good things are good. But don't gamble.

Comprehensive above, I want to say is: In the early development, any point of warfare is very valuable, so there is no reason to throw code, do not implement a certain rule and cause fire everywhere. Always doing a repetitive white work.

Any move, the best thing to do is to try to put the cost to almost low, but the benefits are very high.

The above I said above these things are not my pioneering, in fact almost all Rapid Development, Agile Development, there are many UB blogs are often talking about such topics.

I find that many engineer friends often have the inclination to do what they think is best for themselves. The normal state of the United States is not suitable for use in Taiwan, where the external approach is "absolutely" unsuitable for its own team. But in fact the world is really very big, say really there is no reason to tie their growth rate in their own horizons, a lot of principle in different industries in different countries are applicable. If you look at what other people are doing, you'll be amazed at how amazing these methods are, and how much you can add to your career.