Chapter 10. Other Techniques 3. Team development

on

This chapter explains some development methods and terms used in large-scale development in Rails.

Waterfall

This method divides each process (requirements definition, design, implementation, and testing) into individual steps and manages them separately. If it frequently go back to the previous step, it can be said that you are not proceeding in an appropriate manner.

I've joined a waterfall Rails projects before, but one of the difficulties with the waterfall approach in Rails is that if the system designer does not understand enough about standard web browsers behavior, suitable table structure and SQL for Rails, development efficiency will drop significantly, and it can be easy to become difficult to use and maintain.

Agile

In contrast to waterfall, agile is a more fluid approach, returning to the previous step as needed. Although it is often used in Rails, it tends just to be a not-well-planed way of proceeding. The skill to organize and communicate accurately such information to other members is important in Agile (team development).

As the measures for the problems in Agile, using project management tools and methods (such as Github Issues/Projects, TDD and SDD) are important.

Project management tools

Task management (e.g. Github Issues)

Even in Agile, the following should be listed into a issue before starting implementation.

  • What is needed.
    • And what is the purpose, reason, and background of the needed.
    • What NOT to do in the issue; clarify the issue scope
  • When is needed.
    • Or how much time should be spent on it.
    • And are there any features for this next step.
  • What kind of implementation methods, table structures, or gems to be expected (if any).

It is also important to know that issues are not just for the implementation. It can be kept as a work log, making it easier to reconfirm why the change was necessary and whether the requirement is still necessary after some time has passed.

If the issue creator is not an engineer, you should create the format what you want to know in advance.

Project management (e.g. Github Projects)

Manages multiple issues to list the status of each issue and each member.

Test-Driven Development (TDD)

It is a important method to be considered in Rails and agile.

See the Chapter 13 for a explanation.

Schema-driven development(SDD)

It is also a important method to be considered in Rails. First, decide the APIs format then development begins. There is a way to use tools swagger and committee.

  • swagger is a tool for defining API formats in yaml.
  • committee is a gem that allows specs to ensure that swagger matches the API format.

By using these, compared to other ways, there are fewer omissions in definitions, and Git management makes it easier to check for updates.

Github - committee-rails

There are some ways to use swagger, but it would be good to have a local environment where you can edit yaml by the Swagger Editor and check it by Swagger UI.

Domain Driven Design (DDD)

Since it does not seems to be Rails standard, it can be said to be a hobbyist or challenging method, so I will not explain it here.

If you are interested, please Google it.

Git Flow, Github Flow

  • Git Flow is a branch management method that goes through multiple stages such as develop, release, and main
  • Github Flow is a simple way to manage branches with one main branch (+ feature branch)

No problem with this recognition. In reality, branch management method is often arranged somewhat for each project.

Code Review

Often occur in code reviews include the following problems.

  • Huge PR(Pull Request), no explanation with complex content, or no purpose, reason and background.
    • As a result, reviewers need a longer time to read or to ask questions to the reviewee.
  • Review comments are intimidating, hostile or offensive, and the reviewee's mentality is damaged.
    • Should confront to the issue, not the colleague.
  • PR cannot be merged due to a many review comments and discussions like the following comments.
  • That can't be said which is better.
  • That are pointed out many trivial things.
  • That are not directly related to the PR.

To these problems, both reviewees and reviewers should be aware of the following, for example

  • Reviewees should
    • Divide some PRs if they are large.
    • Comment on points that seem difficult to understand in advance.
  • Reviewers should
    • Use a softer tone comments or use Emoji (Even if it is correct, reviewers may feel uncomfortable).
    • Positive comments should be also made (e.g., "fast", "nice" or "LGTM").
    • Use "IMO" (In my opinion).
    • Use "nits" that means trivial.
  • Both should create new issues for content not directly related to PR.
  • CI should automatically detect problems as much as possible.
    • The policies should be defined using gems such as rubocop and danger to reduce the manual checks.
    • The rules that cannot be detected automatically should be reduced in the first place.

Anyway, we should be respectful to each other in code reviews.

Microservices in Rails

Microservices are recently often considered in order to avoid including too much functions into one service(repository) and to improve scalability and maintainability. On the other hand, it is also important to avoid separating too much.

Some patterns microservices in Rails are the following.

  • Build the back-end as API mode and separate it from the frontend.
  • Build the frontend as BFF(Backend For Frontend).
  • Build an individual Admin (internal management system).
  • Build an individual authentication(login) system.

Monolithic

Means normal Rails that has MVC, is not in API mode, and does not consist of multiple systems.

In contrast to microservices, monolithic system is not separated each function; all is one service. It does not mean monolithic == no frontend Framework so it is necessary to clarify how the frontend is built.

Modular Monolith

This section is a bit of a digression, so you can skip it if not interested.

Modular monolith likely is a monolith that is built for future microservicing.

Since it is too costly to proceed with microservices from the service start, proceed as a monolith with scalability in mind for future microservices. The core of the concept is likely infrastructure configuration and how to build the frontend.

Some web articles say the use of DDD (Domain Driven Design) which is not the normal MVC, but I think it is a bit too challenging, so it is better to think of it as "even when building with a monolith, it is important to select platform and build for future microservicing (scalability) in mind".

Design Patterns

It is not needed to think about what it is as a design pattern (for example, in JAVA, "let's design this as the XX pattern") in Rails. Of course, it is better than not knowing, but it is not always directly useful.

Metaprogramming, Duck typing, Polymorphic associations

It may not be good to describe them all together, but one thing can be said is that it should not be used as much as possible to improve readability in team development .

In rare case that it is better to use them, it is better to make the code as small as possible, and to hide it from the outside so that it can be used without much awareness or with minimal implementation policies.

Other things to keep in mind in team development

  • Make a common understanding
  • Don't arrange implementations in own style too much such as service classes.
  • Don't include too many gems.
  • It is good to propose improvement ideas to team.
    • Consider it whether the content is suitable for your team and system.
    • Even if there are gems or implementation policies that you like, it may not be agreed upon depending on the member's technical level and preference. In such case, you should prepare sample code that may convince the members, but sometimes you may have to abandon the idea.
  • Make it easy for others to debug it with the rails console.
  • Make it easy for others to understand.
    • The code should be understandable for yourself even if it 3 months later
    • In the case of requirements-based implementations, it is better to have comments because it is difficult to figure out the intent from the code.