I don't have any tutorials on tap for general Unity approaches. Most of the tutorials I've found pertain to specific functionality. I can provide you a few pointers from my own experience, however.
Unity is component-based. A lot of programmers come from a procedural or object-oriented background. (or some combination of both) The component methodology is simply an extension of those earlier coding disciplines. But it requires you to think about how you handle code differently.
In Unity, all the objects are GameObjects. That's the class that pretty much everything extends from. When you create anything in the editor, it's an instance of GameObject. This is important to remember. No matter how an object in your Unity project comes to be, it's going to be a GameObject.
Components in Unity are all derived from the MonoBehaviour class. Any script you want to attach to a GameObject will have to extend from the MonoBehavior class. It is possible to write your own custom classes that aren't extended from MonoBehavior in any way. But in order to attach code to GameObjects, a MonoBehavior script will at some point be needed.
All of Unity is based around creating game objects, and augmenting their abilities by adding components to them. Don't ever bother trying to make a script that encompasses all of the functionality of a particular object. The script components you code should all be focused on providing little snippets of functionality.
Take the concept of health. You might be tempted to incorporate health-related code into a "Player" class. This is not how Unity works. It's much better to simply create a script that encompasses all the functionality of health. Then you apply that script as a component to whatever game object represents your player. Because of the way it is structured, you can then apply that exact same script to any enemy objects that also need to have "health."
All scripting code in Unity works this way, right down to all of the built-in object types. If you create a Sprite in the Unity editor, you're just creating a game object with the "SpriteRenderer" component applied to it. You can remove that component any time you want, and alter that game object's functionality. Using this, you can easily change a 2D sprite into a 3D model, all on the fly. Components can all be accessed and altered at run-time, allowing the user a lot of flexibility.
Remember, everything is a game object. Components simply extend the functionality of game objects, they never define what a game object is. If you create a Player script and apply it to a game object, that game object does not become a player. It is simply a game object with the functionality of a player applied to it. Thinking of things in these terms will help you to understand the strengths of the Unity engine.