Code Lifespan
I feel like some of the earliest advice and an early learning principle was:
- design for reasonable extensions in the future. Is your design modular, will it be easy to add features? Did you solve problems in a generic way that could be re-used for other other solutions? For example, instead of doing a graph traversal, did you solve the problem by first writing a graph traversal library?<p>I don't think it's quite as widespread, I would posit that this has changed to:
- (1) YAGNI, build the simplest solution you can for the problem at hand. That will make it as easy as possible to change when future requirements are presented. (2) Design your code to be replaced, not extended. Design your modules in a way that someone can rewrite one without having to rewrite the whole system.<p>Points (1) & (2) really contradicts the generalized solution approach. The generalized solution tends to be very abstract, hard to understand, and because there are layers - not very modular (which makes it hard to re-write)