As someone who maintains a multi-MLOC application in fpc (using emacs and lazarus): discipline.
You don't grow an application to that size by simply building on what might be suitable for a 30kloc application. It requires discipline, experience, trial and error and ability to invest time in properly maintaining the codebase.
Disciplined code review by people very familiar with the codebase is vital.
My personal approach is to create a unit to contain the classes for the "thing" i am working with (e.g. for a 3D world editor, i create a unit that was a TWorld inside, perhaps with TEntity and other classes). Then create another unit for the global stuff (lately i've taken a liking to use a TDataModule which can be edited visually even though it is a non-visual thing - it allows me to place non-visual components in an IDE surface which helps assign event handlers and properties from the editor without writing code for that). Then from the GUI side i just make calls to the global unit/datamodule and/or to methods in the classes i work with.
Of course it all depends on what i'm making, for simple stuff i just throw everything in the form code directly. For more complex stuff i use the method above.
Here is an image showing an example of the approach:
The "GlobalState" window is an IDE window that represents a TDataModule (the name sucks and probably is for Delphi compatibility, it doesn't have anything to do with "Data" and because of that i ignored it for years) that contains the "SimpleViewportRenderer1" and "ViewportManager1" non-visual components - instances of the TSimpleViewportRenderer and TViewportManager component classes. This is in its own unit and can be accessed by other units, essentially providing global state (note that a data module is really a class - much like forms - but you can have a global variable with a single instance of it - again like forms). The neat thing with this approach is that it can also be seen by the IDE: the Viewport1, Viewport2, Viewport3 and Viewport4 components in the Form1 form have a property that accepts an optional TViewportRenderer component. This is presented as a combobox in the Object Inspector window and when you pull it down, one of the options is "GlobalState.SimpleViewportRenderer1" - so you can wire together components 100% visually.
That's an interesting question. Lazarus is an IDE like Visual Studio or the JetBrains ones, and it has nothing to do if you write spaghetti code or not, try google "SOLID" instead on that subject.
