Does the software design mean only mean to make modular, reusable, and abstracted code ? or there is other things to care about ?

[abd klaib]

Hello everyone, I'm new  here, I'm working on  graduation project, which is a  simple, fullstack web app  ;  frontend, backend, and I also use some AI framework (LangGraph specifically).

even though  the project is relatively simple,  I don't  just want to ' make  code that works' , but I want to make  ' maintainable, scalable code', because I value code clarity and reusability  so that it will need minimal effort for anyone else to read and understand it, but I wonder is that the only things I must care about ? is that what software design principles or standards  only care about ? .

 

I  just heard about this book,  does this book contain answers to such questions ?

[Jim Lyon]

In my experience (I've been programming for 60 years now), your first job is to figure out what you care about.

If you're building a small app that you intend to run once and throw away, be completely tactical. Your job is to get done, get the results, and move on.

But if you're building something long-lived, or that is bigger than what can fit in your head at once, then you need to start worrying about strategy. Some things are always important: readability and clarity. For a school project, a professor needs to be able to read and understand your work. For a project that will eventually involve other people, they need to be able to read and understand it. If it's going to last a while, when you pick it up a year from now, you need to be able to read and understand it.

Most of the rules in the book become more important as the size of the software system grows. But since you're explicitly in a learning situation, beginning to practice these rules now will only benefit you. At this point, I would suggest that you embrace designing things twice, and embrace writing good interface comments as a part of interface design. I would utterly de-emphasize scalability and portability -- many many projects in the real world require neither. As far as maintainability goes, it's not so much a thing that you can look for as it is an emergent property of clarity and good design.

And my favorite maxim is: When you're done, it should look like you knew what you were doing when you started, even though you didn't. (If it doesn't look that way, you're not done yet.)