Philosophy when writing code

I'm going to write about what I think during writing code and application architecture in this post.

Rails and Ruby are often referred because I've been working on Rails application for several years.

Code

If we have rules in a project or a team, of course, I'm gonna follow them and ask the reason why a rule is introduced in the project when I don't understand. Rubocop has so many rules, (and that point I really hate it,) and I sometimes or often have to ask the introduction reasons in a new project. This is really time-wasting and I prefer Golang for a team project because it has wonderful gofmt as a language feature. IMO, you should allow many ways of code and throw away rubocop when you adopt Ruby although I understand the reason to introduce rubocop.

I also follow the way of the language even if I don't like it. I believe it's natural when working in a team with a particular programming language.

I always want to re-consider better class/module/database structures when any change happens. (Related to Refactoring Toward Deeper Insight in DDD book.)

Ruby

• Write OOP style code
  • Avoid class methods as much as possible
• Inheritance is once
  • If you have grand parent class of a class, you should re-consider the class structure or the interface.
  • Using module might be better solution.
• Avoid excessive DRY
  • Abstraction can be helful to reduce code, but it can also be confusing to read.

Architecture

Follow the default way in a framework. Write code in MVC2 way not DDD or another way if you use Rails. If the framework's way doesn't match your project or team, change it ASAP and don't introduce or mix the different architecture into it.

Libraries

• Open for introducing defacto libraries
  • New developers of the project soon catch up if you use popular ones.
• Use standard libraries as much as possible
  • Less dependencies, less learning and easier to upgrade

Summary

All of above is what I think in coding.

This will be updated when my mind changes.