shivylp

With microservices pattern, in a medium-big organisation, there are lots of services maintained by lot of different teams. And somewhat regularly, new services are created, old services are deprecated, ownerships change, etc. With all this some challenges emerge:

1. Hard for new team members to make sense of the overall system. 2. Repeated efforts: team A does not know team B has solved a particular challenge already and end up building something again. 3. When deprecating a service/API, no one knows who else is using it and the impact of stopping that service/API.

Within your organization, what documentation tools or practices do you follow to be make it easy to discover existing services/products, product PIC for it, tech PIC for it, etc.?

I love building things in my free time. But usually I build something technical or out of curiosity about a new tech/framework/language etc. Not exactly a targeted solution to a real problem (You can see my projects here: https://github.com/spy16).

For a change, I am looking to find problems that others are facing (that also interest me) and build something that solves those problems. Anything that can help fellow developers, product-managers, etc. in their day-to-day work life (I am also hoping, this thread itself can be a useful collection for others like me who are looking for ideas for their next project).

I have been using golang at work and personally for more than 2 years now. A problem i faced when I started and the problem new gophers even today is how to structure the project. Most (if not all) golang tutorials seem to be very simple and do not describe how to structure a large application. Following project is an attempt to Showcase a manageable project layout for services in golang.

https://github.com/spy16/droplets

This project is far from complete. Would like to hear some feedback from the community before continuing on this.

Go convention is to write comments for every entity in a package that is exposed (starts with an upper case letter). Even linter complains about not commenting. I have heard people argue over this saying some things shouldn't be commented if they're obvious enough.

I agree that obvious things don't really need a comment. But the problem of commenting only certain things as opposed to all things, is inconsistency across codebase. If new developer looks at the code and sees comments only at certain places, it might feel like the comments aren't trustworthy since there is no standard pattern. Also, I believe the term obvious itself is not objective (at the time of writing the code, most of the stuff are obvious)..

What do you all think ?