From a performance/maintenance point of view, is it better to write my custom modules with netsuite all as one big JS, or multiple segmented script files.
If you compare it with a server side javascript language, say - Node.js the most popular, every module is written into separate file.
I generally take the approach of Object oriented javascript and put each class in a separate file which helps to organise the code.
One of the approach you can take is in development keep separate files and finally merge all files using js minifier tool like Google closure compiler when you deploy your code for production usage which can give you best of both worlds, if you are really bothered about every nano/mini seconds of performance.
If you see SuiteScript 2.0 architecture, it encourages module architecture which is easier to manage as load only those modules that you need, and it is easier to maintain multiple code files i.e. one per module considering future enhancements, bug fixes and code reuse.
Performance can never be judge by the line count of your module. We generally maintain modules for maintaining the readability and simplicity of the code. It is a good practice to put all generic functionalities in to an Utility script and use it as a library across all the modules. Again it depends on your code logic and programming style. So if you want to create multiple segments of your js file for more readability I dont think its a bad idea.
Related
Please tell me which option is better ?
Option 1: All these methods will be in Track module
getTrendingTracks
getMyFavoriteTracks
likeTrack
unlikeTrack
getMyPlayedTracks
playTrack
getArtistTracks
Option 2: These methods will be in separate modules
Track module
getTrendingTracks
Like module
getMyFavoriteTracks
likeTrack
unlikeTrack
ListeningHistory module
getMyPlayedTracks
playTrack
Artist module
getArtistTracks
It depends on the size and the future development of the application.
If the project is small and you don't expect to have a lot of new functionality option 1 is a good choice. It will keep all things close to one another and you will be able to find and modify them easily.
For projects with a lot of functionality and longer lifespans option 2 is better. This way you will be able to create smaller and more cohesive modules. These modules will depend on other modules, so you can create a module dependency map. This way you can manage the dependencies in your application better so you don't end up with spaghetti code.
When you want to add new functionality you will have to do one of several things:
Add a new module. This is the coolest thing in options 2. You just add a completely new thing to get new functionality.
Extend an already existing module. Having smaller modules makes this a lot easier.
Extend a small number of modules. Having smaller cohesive modules makes this a lot easier too
I highly recommend taking a look at Unreal Engine. It has a very good modular architecture. It has a huge codebase, so in order for it to be manageable, they split the Engine into modules. You can check it here
I'm new to cucumber as a testing suite. I notice that as I build out feature and write steps. Lets say as a bad example (since I'm working backwards) I write a bunch of stuff for creating posts that require a User.
I end up writing a bunch of User based steps (log in process etc) in a feature set mainly dedicated to Post features.
Is it best practice to later move steps into the appropriate feature set as tests get more complicated and features get added?
You have two parts to consider here.
Organize scenarios so they make sense. That is to place them in the proper feature files.
Organize the implementation of the steps so they make sense. That is, implement the steps in the proper source code files.
Your question boils down to "What makes sense in my context?".
It depends on your stakeholders, do they want all user facing scenarios in the same feature file or are they more interested in business facing scenarios that sometimes involve users? Organize the scenarios so your stakeholders are happy.
How should you organize the steps then? It depends on your developers and your ability to share state between step definitions that are implemented in different source code files.
My approach would probably be to start out small and let the suite grow. This would initially not involve sharing state between different classes during runtime. When the suite feels to large to handle, divide it in two parts that are as coherent as you can make them. When this gets to large, repeat the division again. You will, hopefully, end up with something that works well in your context.
Remember that your context and your product is unique. It probably deserves a unique solution that your team feel they can maintain.
Understandability and therefore manintainability is the most important property I can think of regarding the executable specification you are building.
I'm using snippets to break up long templates into more manageable chunks, is this bad practice and should I only use snippets for reusable code?
Thanks
Lee
It depends of what you are doing in your templates.
It is indeed generally a good practice to reuse part of templates in smaller chunks, but it's recommended to avoid the usage of embeds because of underlying performance issues.
Snippet are cool as soon as you don't have to pass variables to your sub-templates.
Maybe a good approach for you if your templates are not already totally coded is to use the 'template partial' technique. See the following tutorials here under.
Template Partials using Stash
Homegrown plugin to create template “partials” for ExpressionEngine
You should look at using an add-on, I use either Low Variables or Republic Variables (free), where you can store snippets and parse them early or late. They can also be saved as files which is handy.
You can find them on http://devot-ee.com
I'm using mocha to test my node.js application.
I notice that my spec files getting bigger and bigger over time. Are there any pattern to organize the test files (e.g. one specs file per test)? Or are there other frameworks on top of mocha to help me structure the tests? Or do you prefere other test frameworks for that reason?
Large test/spec files tend to mean the code under test might be doing too much. This is not always the case though, often your test code will always out weigh the code under test, but if you are finding them hard to manage this might be a sign.
I tend to group tests based on functionality. Imagine if we have example.js, I would expect example.tests.js to begin with.
Rather than one spec called ExampleSpec I tend to have many specs/tests based around different contexts. For example I might have EmptyExample, ErrorExample, and DefaultExample which have different pre-condidtions. If these become too large, you either have missing abstractions, or should then think about splitting the files out. So you could end up with a directory structure such as:
specs/
Example/
EmptyExample.js
ErrorExample.js
DefaultExample.js
To begin with though, one test/spec file per production file should be the starting point. Only separate if needs be.
Often when beginning a new project, I start out with what I believe to be the best of intentions in terms of how to structure the codebase. I love the idea of numerous small modules that do one thing well, are de-coupled from other parts of the codebase, and could potentially be reused by myself in other (similar) projects or open sourced for others to take advantage of.
However, come crunch week when I'm actually trying to get something into production, there's been more than one occasion where the complexity of managing all these different modules has proved too much of an overhead (despite good documentation and deploy methodology). On those times I've simply changed tack and bundled all the modules into one repository and managed it all as one codebase, meaning I can track everything together through different branches, deploying to staging and test environments, etc...
What are the advantages and disadvantages of these different approaches, and how do you manage working in one way or the other?
Advantages of one monolithic codebase:
Easy to deploy
Easy to rollback
Easy to branch/manage all changes together
No (or less) potentially complex dependencies to document and manage
Advantages of modular dependencies:
Reusability
Clean architecture (one module does one thing well)
I do not see the opposites as much as you do. Taking a .NET experience as an example, I can ensure parts of my code are geared towards well-defined responsibilities, I can structure my codebase into namespaces, ensuring that the touching points of the namespaces are well defined and that classes within the same namespace really do belong together.
However, all this can happen within a single unit of deployment, single project, branch, what have you. If you stick to that, units of code that may become reusable in the context of the projects you do will crystallize and that would be the point where you may decide to introduce a new unit of code, with its own deployment artefact, source control branch, etc.
Here is a talk from Google explaining (a little bit) how they handle their gigantic monolithic code repository. And why they have one.
By the way, I don't think it has to be opposed to a well defined set of dependencies. I would even say that to handle a monolithic codebase, you have to be super careful with the dependency graph and the responsibilities. Because with this kind of organisation, it is easy to add a lot of more or less useful deps…