Is there some kind of best practice approach for a project from idea to live deployment?
What is your approach to a project? That is, from the idea to putting the domain live? I have some experience in programming, PHP and Javascript. Lately I have been reading some books that deal with object oriented programming. So I am aware of the HOW of programming and the WHY, think of design patterns and some techniques like dependency injection.
But what I could not find yet. Is there some kind of typical flow of an implementation? Some kind of best practice?
How do you guys do it? Do you just start coding, first class, add some methods, etc....? Does anyone do anything on paper beforehand?
That would be the logical approach for me. But what does that mean exactly? Drawing classes and methods using UML?
What is the best way to start? It's just not clear to me yet. When I have to write a paper for university, I think about the table of contents as a kind of scaffolding and the individual paths are filled with details bit by bit.
When I think about the frontend, I also start with sketches....How do you do that on the backend side?
A few different ways how to approach this. My process is roughly like this:
There's lot of stuff missing here (e.g. writing tests, deciding on a library or writing stuff your own, using a framework etc.) but I hope you get the idea.
The more I plan, design and engineer code, the less I actually have to code and the less I have to refactor later down the road. Hope this helps.
Thank you, this already helps. I'm especially interested in how to layout the classes and its methods. And how they are 'interacting' with each other, in the sense of when to use an interface above or when to use it with abstract class. Stuff like that. What I have in mind is, this should/could be outlined on paper and then 'just translated" into oop code? Or am I a bit naive on this?
If you are at this level of experience I'd recommend that you spend more time reading code, specially popular smaller projects in your preferred languages. Maybe even try to build a few clones yourself, and then compare it to what's already out there.
A simple PHP example would be a wordpress contact form plugin, or a class to send email, since there are gazillons of sample projects to learn from in this area.
Design decisions are often a very subjective matter (depending on personal preference, skill level, time available, etc.). Just because I know the most common design patterns and overall best practices does not mean I am not a lazy coder sometimes :)
Are you using class diagrams, sequence diagrams? Do you use object oriented modeling at all? That's what I wanted to ask but didn't know the right terms ;)
Well, this is not college, so I am definitely not drawing super detailed (and 100% formally correct lol) UML diagrams by hand.
As a 2-man-team we also do not use any kind of software modeling/engineering tool, but focus on way smaller iterative steps. Less waterfall, more kanban. Baby steps, tons of them.
I mainly focus on writing very good user stories & specs (which end up in my product management backlog -> other topic) and only if it is helpful to have a diagram do I add one.
To save time I scribble (what can be identified most of the time as UML) diagrams on paper, then take a pic of my scribble and attach that to the ticket.
I tried a few different methods and this one was by far the simplest & fastest method to communicate with my dev partner. If you ever tried quickly sketching something in Google Slides or similar, you'll understand.
Re the object oriented (OO) modeling: I think that outside of college I have never again done OO modeling from scratch, starting from 0. It was always based on frameworks, usually MVC (model-view-controller) or similar.
Frameworks are the dominating, well, frame in which you develop nowadays. If you are not a pro, and do not have a very good reason, do not develop a serious (side) project without a framework. Pure waste of time. A framework will help you write better, more secure code faster, and with a lot more fun, because you make visible progress faster.
If PHP is your thing, check out Laravel.
The framework you choose and the gazillon of open source projects out there will show you the way how most code is designed and developed.
And...to actually get to finish this comment some time soon...you should also read up on design patterns. https://www.patterns.dev/posts/ is a brand-new ressource and looks very beginner friendly.
You don't need to know all of them, even 2-3 are incredibly helpful in the beginning (e.g. singleton & factory) as these concepts translate across most languages.
It's these design patterns, architectural decisions, and of course some personal style, that differentiates (my opinion) the coder from the experienced software engineer.
To finally answer your question, no, we are not using any serious OO modeling, only scribbled diagrams if we think the situation requires it.
Hey,
5 Software Deployment Best Practices
Keep Separate Clusters for Production and Non-Production.
Apply Resource Limits.
Collect Deployment Metrics.
Implement a Secrets Strategy.
Automate Database Updates.
Regards: https://malloftoys.com/collections/lui
This app describes it step by step and updates lessons regularly: https://play.google.com/store/apps/details?id=co.idearun.startup&hl=en&gl=US
If you're into PHP, check out Laravel. It will help structure your project quickly. This site has a lot of tutorials with a great instructor: laracasts.com
I'd sketch out the basic architecture on paper. Then build an MVP in Laravel + Vue.js. Run it by some potential users. Expect to rebuild it from scratch at least 2 or 3 more times as you begin to understand what you're building and its goals. It's probably better to rebuild something 3 times than to spend too much time in analysis paralysis.
Today I posted this on my Twitter account
SaaS validation "cheat sheet" incoming
Landing page takes a day to build (typedreamHQ, carrd , webflow )
Marketing before coding
3.Collect emails who fit your target persona
4.Engage your waitlist with content
5.Solicit feedback as you build your MVP
Once positive traction, start taking pre-orders
Build main feature of your MVP- delegate everything else (billing, tracking, emails, infra, etc)
Start charging with PriceWell and Stripe
Start doing sales-collect feedback
Return to 7 iterate and fine tune your process