Intro
When you’re structuring or organizing a larger project, the key factors are maintainability, readability and efficiency. You should primarily be focused on the maintainability and readability parts, they are essential for you to be able to continue developing your game. Efficiency is also important, and you should make sure that your scripts are not poorly written, but maintainability > efficiency. (Personal opinion).
You should create a README file with how you’re structuring your scripts, where you’re placing them and why you’re doing that. Some other info is also great, remember that anything you work on now, literally describes how you’re going to be working with it later. You are setting everything up for your future self, unless you’re not going to work on it anymore 
That’s why it’s important to follow a set of rules that you have to follow strictly.
Thinking “this is so easy I don’t have to follow my rules” will bite you in the future, trust me. If you have properly set up a system, you know what works where, and you don’t have to worry if that function exists or not. I have several times
Some tips when it comes to this:
- Self-explanatory variable naming
- Rules when to use camelCase and PascalCase, don’t mix! For example constants with PascalCase and other logic with camelCase.
- Create independent modules, modules are made to be extensible, so utilize this as much as possible
- Document your code, no over-commenting or other redundant stuff
If you’re more interested please read my comment and not the original post as I don’t agree with what it states. (No offense to the author) A Scripture's Guide To Scripting - #14 by Visualizememe
And if you’re interested in a commonly accepted scripting style Roblox Lua Style guide
Other things to consider
Don’t send clients things they don’t need!
This is probably an obvious point, but how to overcome this issue is probably not that obvious. We all know “ReplicatedStorage” and its usecases, but did you know that anything you put in there automatically replicates to the client? Maybe, maybe not. Don’t replicate stuff that is not needed. Have all the items on the server (more specifically, in ServerStorage). That way, when clients need something, then you can move it to your liking, but otherwise, hands off!
Optimize code, or not…
This is a commonly discussed matter and we’ll never know who wins. Some say “Rules of optimizing: don’t do it.”, others say do it anywhere you can. I think that the second you start optimizing your code, you want to optimize more and more for “nothing”. Yes, maybe you get a millisecond or two faster load times, but who notices? Not me, not the players, nobody else but you. Optimize with a grain of salt. I’m staying on the “don’t do it unless there is a significant improvement if you do” side.
Optimizing code might, or will most likely result in less maintainability and readability, which breaks my predefined rules stated above. Efficiency is not important if you can’t update your game because of it.
Some threads discussing this:
Security
Another interesting topic. Don’t let your clients command your server, let the clients politely ask the server. Have you ever encountered exploiters? I have, most, if not all have experienced some kind of an exploiter in a game. Do you know what’s guaranteed to be common with exploiters? Frustration, annoyance and less players.
If you let exploiters thrive you let your players dive, is that what you want? No, and especially not for a larger game where players might spend more time. Players get a feeling that somebody else can cheat their way to faster stats and that will make them uncomfortable and unpleased. Get rid of common exploits. Speed, fly and those kind of basic exploits break the natural feel of the game. Get rid of that before it becomes a problem.
When you’re coding your game you must always think of what the player can, and can’t do. If you understand that, you will gradually understand what not to do. For example, if you are to let players buy something in your game, you want them to be able to buy the sword, but you don’t want them to buy it for free. Think of all attack surfaces, all the ways an exploiter can harm your game, and fix it.
Remotes
Don’t have one remote, don’t have 1000. Proceed with caution. I don’t remember which topic it was, but there was a discussion where many people argued whether one remote and several remotes were faster. Utilizing several remotes results in better performance. That doesn’t mean you should have one remote for one thing.
Keep them general so they’re easy to maintain.
When it comes to communication between your server and player, this is the point where you actually should be worried about efficiency and bandwidth. The more data you transmit the longer time it will take for input and output to be processed and replicated. Now, don’t go completely bananas, but utilize several methods for compressing data so that your game feels responsive.
Separate client & server stuff, please
I have talked about this so many times, and people who don’t get it, outright called me a noob. So I guess you’ll have to trust me on this one 
The server is the messenger, the client is the computer. Don’t overload the messenger with things that the client can do.
The server exists for the following things:
- Securing your game and filtering/validating input from the client
- Replicating information to all clients
- General things that clients should not be trusted to run (or can’t :p)
The server does not, and again not, did I say “not” twice? Well, I mean it. It does not exist for the following:
- Animating characters
- Rendering stuff in the game (visuals like gun bullets, effects etc…)
- Things that could be done on the client with, aka all things that don’t affect other players.
Yes, you can have the server replicate the animation data, but you can’t have it do the animations.
Yes, you can have the server replicate the visuals (gun bullets) to the other clients, but you can’t have the server do it on its own.
_G, or not
Ever heard about _G? That’s Lua’s version of global variables that Roblox has made accessible for either the client or the server. If you use _G on the client, it’s only accessible on the client. Use it on the server, and it’s only accessible on the server. You can also use it on both sides
Some people say it’s bad to use global variables, and they’re right. It’s actually bad in other programming languages, but on Roblox? Not so much. _G is super easy to use, and it functions just like a regular table with values. If you want to use it in your larger game, please be sure not to make it a complete mess. Some of the reasons why _G is bad on Roblox are the following:
I personally use modules because that’s the way I like it. But don’t worry if you’re using _G on Roblox, just don’t use them in other languages unless they’re declared safe to use.
Summary
Now, I know that I haven’t answered all of your questions, but I hope you at least learned something new from the post. I’m only trying to help you out
If you have any questions and I’ll be happy to answer them. 
