3 ms·

This is a great habit. I wish all projects had a coding style document. Coding philosophy is much more important than tooling and choice of languages IMO. Not h

This is a great habit. I wish all projects had a coding style document. Coding philosophy is much more important than tooling and choice of languages IMO. Not having such style guide is like employing builders on a construction project without letting them see the plan. That said, about this point: - Ensuring consideration of cross-cutting concerns. My answer would be "Avoid cross-cutting concerns because they are a violation of the separation of the concerns principle; a violation of the cross-cutting kind" ;p My observation is that while avoiding cross-cutting concerns can seem challenging at first, creating a code architecture which avoids them leads to much more maintainable and easy to follow code. I've worked on many complex projects; distributed systems, blockchains, P2P messaging systems... but I'm yet to encounter a project which cannot be structured in a way to avoid cross-cutting concerns completely. That said, IMO, aspects mentioned in the article like "security, privacy, observability" aren't really separate 'concerns' but merely desired characteristics of software components.

dpe82 2y ago
Perhaps read the section dedicated to this point: https://www.industrialempathy.com/posts/design-docs-at-google/#cross-cutting-concerns https://www.industrialempathy.com/posts/design-docs-at-googl... Some cross-cutting concerns are about more than just code, but things like "how will you monitor this for reliability?" or "this system reads user-sensitive data, how will those reads be audited?" and so on. Usually the answer is short: "use standard system xyz" - but having it there and ensuring it's followed through on are important.
- jongjong 2y ago
  Fair enough. Definitions can be broad. The term "Cross-cutting concerns" made me think of aspect-oriented software development which has a very specific definition and it tends to favor specific approaches like dependency injection. For example, in aspect-oriented development, they tend to promote injecting a logger into all the components; but other development methodologies might instead make it so that messages and errors bubble up the component tree (e.g. for non-error messages, might use event emitters, message passing, callbacks, or other kinds of channels). But the idea is that the messages for all components are aggregated, handled and logged near the top level in a central place; so you don't need to inject a logger instance into every component; it loosens the coupling of your components with the rest of your application... Also, logging might be just one of things you do with those messages. It's nice to have that logic near the top level of the code. I find it extremely valuable when the important outputs of the system (what the developer or user can physically observe) can be traced starting from a single source file (or at least, as few files as possible).

dpe82 2y ago

Perhaps read the section dedicated to this point: https://www.industrialempathy.com/posts/design-docs-at-google/#cross-cutting-concerns https://www.industrialempathy.com/posts/design-docs-at-googl... Some cross-cutting concerns are about more than just code, but things like "how will you monitor this for reliability?" or "this system reads user-sensitive data, how will those reads be audited?" and so on. Usually the answer is short: "use standard system xyz" - but having it there and ensuring it's followed through on are important.

jongjong 2y ago
Fair enough. Definitions can be broad. The term "Cross-cutting concerns" made me think of aspect-oriented software development which has a very specific definition and it tends to favor specific approaches like dependency injection. For example, in aspect-oriented development, they tend to promote injecting a logger into all the components; but other development methodologies might instead make it so that messages and errors bubble up the component tree (e.g. for non-error messages, might use event emitters, message passing, callbacks, or other kinds of channels). But the idea is that the messages for all components are aggregated, handled and logged near the top level in a central place; so you don't need to inject a logger instance into every component; it loosens the coupling of your components with the rest of your application... Also, logging might be just one of things you do with those messages. It's nice to have that logic near the top level of the code. I find it extremely valuable when the important outputs of the system (what the developer or user can physically observe) can be traced starting from a single source file (or at least, as few files as possible).