Half A year ago, I joined an entrepreneurial team that had just received A round of funding and was responsible for the iOS project. In those early days, the company didn’t know if it was going to survive or die. It just iterated quickly to get it right. These early, unheralded teams also have no engineering ambitions, just write fast. But want long-term development after affirming direction, cannot savage growth again. Based on my practical experience in this project in the past six months, I would like to share with you.

Code hosting: self-built Gitlab

GitHub is one of the easiest things for early grassroots teams to do. But GitHub becomes expensive as the team grows. The regular group package costs $9 per person per month. Another problem is that GitHub is deployed abroad, and domestic access to the web is often patchy. I heard that the code of a multinational team was hosted on GitHub, and GitHub could not be accessed during an important meeting. What a sudden fatherly love like a mountain. Another disadvantage is that it is not convenient for the server to configure CI services itself. If deployed on your own server, other service scripts are deployed together, giving you a lot of autonomy. After synthesis, the mainstream Gitlab was selected.

Engineers’ time is more expensive than machines

Many short-sighted teams feel that the equipment assigned to engineers is too expensive, so just pick something cheaper. A good computer costs more, but in the long run it saves engineers more compilation time than a machine. In terms of equipment, I suggested to the company that it should be equipped with the latest 15-inch RMBP and a Dell 4K monitor. Behind discovery keyboard mouse also important ah, each person subsidized again 500 key mouse quota. I see a lot of engineers still working on air, and the MAC Mini. I really feel bad for this stupid company. I was on a team that had 4 terminals on the same computer. Every time I compile, I take a walk on Nanjing Road. If you’re going online tonight, you can go see a movie.

As soon as possible for

Recruiting is a very important part of team development. Many early teams underestimate the difficulty and cycle of hiring. Because lesser-known teams have two drawbacks to hiring:

  • Don’t offer too high a salary

    Good people compare salaries in the market. BAT companies that have been famous for a long time will naturally have a salary advantage. Startups have options, but their future is uncertain. Many engineers also worry that the company will soon go out of business.

  • The team has a lot of things to do

    Iterations after a project matures are mostly step-by-step and at a steady pace. Each link has a very specialized staff. Because the early project is still in the growth stage, it is likely to see the popularity of live broadcast on the way, so we add a demand for live broadcast. Or do it and find out that there’s a feature in a competing product that doesn’t matter so much that we’ll use it in the next version. Or the CEO walks by and has an idea and pushes the launch date back.

In addition to the hard metrics of technology, there is also an engineering team culture issue early on. In a project of dozens of people, the motivation of a particular person is not very important to the project. He just does what needs to be done. Not even talking to other people makes little difference. A big project can’t fail just because one person is gone.

But the early team, there were only a few people. When one person’s perception of the team’s mission is inconsistent, there will be a lot of friction in daily behavior.

I’ve been thinking about what a team culture is and how to describe it. Later, I saw a statement that felt quite appropriate. Culture is in the air, everywhere. The company does not require you to respond to user feedback when you see it on social media platforms after work, nor does it stipulate whether you should take it seriously or communicate with people in other departments if you find a problem with products of other departments, or whether you should make a better suggestion to the company. What underpins these behaviors is the culture of the team. The people on the team determine the values.

In summary, if you are lucky enough to find a matching technician, it can take a few days. More often, it can take several weeks. Of course, if you hire someone in a hurry and then leave after a few months, it will do a lot of damage to the morale of the team.

Therefore, considering the future progress of the project, the recruitment plan should be launched in time. Start hiring when you find that your schedule is too tight and you have time to prepare for the interview as well as the project schedule, which can be overwhelming.

The transformation of Swift,

The other three colleagues on the team had no previous experience writing Swift. But given the future, and the type of business we are, it’s not that dynamic. I insisted on Swift programming in my team.

One of the questions I get asked a lot is if you want to use Swift but no one else on the team can, does it make it difficult for the project to move forward? In fact, if someone in the team has the right guidance, help them solve the problems in the process of getting started, and give them a period of transition. Soon they won’t be able to turn back.

Here’s how I migrated from OC to Swift.

Write the network layer library in Swift first. By bridging commonly-used OC Models with Swift objects. Something like this:

 class SwiftUser {
	init(ocUser: OCUser) {
	}
	func convertOCUser() {
	}
}
Copy the code

After this transformation, a new module can be written entirely in Swift. I must have written Swift code with OC thinking at the beginning. However, after being familiar with Swift grammar, we can gradually suggest that a more Swift writing method can be used in the review process. Some functions require OC and Swift to call each other, which is really cumbersome. It must be daunting for someone with no Swift experience to solve these problems. So allocate some time during the project to rewrite the old OC code. Fortunately, the original code was messy and needed to be rewritten. Thus, as the business progresses, the proportion of Swift becomes higher and higher.

After a month or two, you’ll get familiar with Swift, and then you’ll move on to frameworks like RxSwift.

Streamline the development workflow

Early on in the project, there were thousands of requirements. How many features should be developed in an iteration? Product managers instinctively pat themselves on the head. A page of requirements indicates that this is the version. Programmers tend to be optimistic about the time, doing half a month has passed. The requirements for the next iteration, UI design, and pre-delivery testing were all a mess.

Later, an iteration cycle of two weeks was determined after discussion. A requirement that can’t be completed in this iteration is moved to the next iteration. It’s pretty clear what to do in each phase of the cycle. Two weeks or so is a good pace to launch with reference to user feedback.

The emphasis here is on preparation at the beginning of the development process. This mainly refers to requirements and UI diagrams. Most requirements are designed around a requirement, but there is a lot of peripheral work that needs to be done to integrate the requirement into the existing system. For example, the product suggested that users should be able to tag their profiles. So I made a sketch with labels in it. For him this need may be clearly described, but when it comes down to it, there is other work to be done. For example, how to delete tags? Is there a word limit on the label? What if the label is duplicated? If these problems are not clearly expressed in the early design of the product, they can only be communicated back and forth in the development process. Having an experienced developer to participate in requirements discussions and ask questions early on can be a big help in later development.

A designer who doesn’t use Sketch is not a good designer

I see a lot of designers following the tradition and using Photoshop all the time. However, the use of the vector design tool Skecth is actually quite common in the industry. Now mobile phone screen size is more different, if the design time is not vector map, but bitmap, do responsive layout design will be very inconvenient. In fact, mobile UI design with Sketch is a huge productivity boost. But like most people, many designers are comfortable with Photoshop, not Sketch. In fact, a leader has the obligation to promote some people and make good things happen.

In the team I worked in before, I kept hinting that only weak designers use PS. After a few weeks of stimulation, he said that he could also use Sketch now. Gradually, he couldn’t return even after the project Symbol had completed PS.

Of course there are very old school designers, and this only puts pressure on them to change passively. We had a forty-something designer on our team, and we were in a tough spot. I thought, well, next month if you can’t Sketch it out you can find a new job. Of course as a team you can’t just give instructions and walk away. Designers who are skilled in using Sketch will pay special attention to their learning status and give timely guidance. It also worked out well for him in the end, as he found Sketch actually worked better after being forced to change.

Amway also has a great software for exporting design drawings: Zeplin. It would be very rigid to annotate the design directly. Programmers can view all the source information of the design drawing by themselves in the process of viewing, which will greatly improve the efficiency.

Access to the CI

Many teams change the macros in the code to differentiate the environment in the app, changing the macros before each submission. You can’t walk along the river without getting your shoes wet. I’ve actually had people forget to change the environment macro when submitting the App Store, and the App is connected to the test environment. The point here is not to double-check before Posting, but that this should not happen.

Actually manual submission via Xcode packaging is a risky process. From time to time, a few lines of code will be changed locally, and the local code will be submitted as well. With unknown risks.

I configure scheme and target in Xcode to differentiate the environment. Use Fastlane to automate package uploads. Combined with Gitlab’s CI, Gitlab Runner was configured and packaged with a click of a button. Reduces the manual risk of publishing.

Our component uses Cocoapods to manage dependencies. With Gitlab Runner configured, component version updates also work remotely, not locally. After webhook is configured, the slack channel receives messages every time a job is completed.

Use Testflight well and focus on beta feedback

Early business changes frequently, there is no automated testing, can only rely on manual testing to ensure stability. Initially, the team chose to release the enterprise version of the package for testing. Of course, enterprise edition users can easily download and install, but there are many disadvantages. The biggest drawback is that this package and the App Store package are two different packages, with different bundle IDS. Some functions associated with package binding cannot be tested normally, such as wechat login and jump after payment.

Our business has a chat function, chat records are local only. And we believe that an account can only be logged in on one device on the same platform. This causes users to log out of the App Store version during testing, and the chat history is lost. Enthusiastic users were willing to try out our beta, but at a cost they shouldn’t have. With this in mind, at my direction we abandoned the enterprise version of the package testing approach. Instead, use TestFlight.

Testflight has a high barrier to use, requiring users to collect their email addresses and then type in an Apple invitation code into Testflight to start testing. Many users are too bothered to quit, the operation thinks this will bring great inconvenience to the test. But things aren’t that bad after all. People who are really interested in the product won’t give up just because they need to fill in an email. Those who lose are regular users. After users use Testflight, subsequent releases of test packages will receive updates. We won’t have to manually tell users that we have a new test pack like the enterprise version. There will be a qualitative change when beta users exceed 100. These are active heavy users, and a bunch of heavy users using your new version for a few days can at least ensure that the core business logic is flawless.

Before, someone asked us whether there would be a lot of problems if we could not dynamically fix serious online bugs when we use Swift. In fact, there are very few serious accidents because of the beta testing. One incident was when we upgraded to Swift 4.0, and an enumeration turned out to be incompatible with iOS 8 devices (Xcode didn’t tell us, Apple’s pot). That version also happened to be the last to support iOS 8. None of our test users happened to be using iOS 8.

It is also important to allow users to give feedback on problems during Beta testing. If I have a problem with you, it depends on the app version, it depends on which page it is on, and it also needs to say my userID. Users are also good-natured. We have integrated the function of “shake back bug” in the app. All the effective information, such as operation steps, network requests and device information, will be collected together. You can easily see it in the background. Tell the user to shake and describe the problem. After the user feedback, we will receive emails, timely feedback to users and users are very involved.

The shake feature is not available to all users, but to certain users we can contact. After all, every feedback engineer needs to follow up, and if it were open to all users, we would receive too many invalid messages. It’s common to see engineers discussing where the portals for these developer features should be hidden, whether it’s typing a particular character in a text box or clicking a few times in a corner. The developer panel entry I chose to configure in Universal Link. In this way, the user will not reach any place in the app by mistake, only through the link we tell him to jump to reach.

Adhere to Code Review and enhance technical communication

Code Review is an amazing thing. All qualified engineers think code review is good. As far as we know, many excellent IT enterprises in foreign countries attach great importance to code review, but in China, IT is rare to see a team implementing code review. Or code review is rarely seen on smaller teams.

But I value code review very much. From the perspective of feelings, it is a kind of inheritance of engineers’ skills. If a method is poorly named, the project will also work from the company’s point of view. But from an engineer’s point of view, if you can, why not help people who are just starting to code?

As a leader, helping members grow during review and just checking whether the code can complete the function will lead to different results. Read a very touching sentence, now many leaders know that they need to manage others in their work, but they ignore the need for lead.

To be honest, there was a lot of resistance to push forward code Review. There are people in the team and people outside the team. The perception outside the team is that code review slows down the project. As a core developer, I spend over 20% of my day with no visible work output. Sometimes I had to fix something that someone else had written, and a feature that was already done took hours longer. The problem within the team was that many members did not understand the value behind the work. It’s easy to feel like I’m just sitting there in the morning with no idea what I’m looking at. I don’t have much code to commit. I ended up winning the team’s “least code produced” award.

Personally, I would definitely feel more relaxed without review. I’m sure I can control all the details of this feature, but it’s just not good, it’s not impossible. I don’t have to explain to them why it’s bad to write this way. Just get them to follow my comments.

But what is thankless persistence for?

When I first started working, I met a college professor on a trip. I asked you a question. In ancient Chinese shoes, flowers would be embroidered on the sole. No one else can see the soles, so what’s the point? He replied, “We don’t do things for others to see, and ultimately we have to go through our own hearts.” Flowers embroidered in the sole, others can not see, you know.

Welcome to my micro blog: @Zhuo who has no story

Nuggets blog: juejin.cn/user/192600…

If you want to talk to me more closely, you can also join my little secret circle: The Programmer’s Survival Guide