Sencha Inc. | HTML5 Apps

Blog

Creating Development Standards in the Enterprise

March 25, 2013 | Arthur Kay

As a member of the Sencha Professional Services team, I spend most of my time directly interacting with our larger enterprise customers. Our team offers a wide variety of expert services, and in many cases, we spend weeks working side-by-side with a group of developers helping them to create, build and deploy incredible applications using Sencha products.

I recently had an opportunity to work with one of our enterprise clients, helping them define how Sencha should be used within their organization. I wanted to share some lessons and high-level concepts about enterprise architecture with the community that I think will benefit everyone.

Sencha Complete

Working with the Enterprise

Working at the enterprise-level can be both very cool and very frustrating. On the one hand, I get to build really challenging apps; but on the other hand, enterprise applications often target legacy browsers and are prohibited from using cutting-edge technologies.

Having said that, I am starting to see many of our enterprise customers rethinking their development strategies and IT infrastructures: workstations are being upgraded to modern versions of Windows, and workers are being given more choices for a web browser. In some cases support for IE6 and IE7 are being dropped completely!

More importantly, I am noticing that enterprises are standardizing their development platforms to create an ecosystem of applications that can be maintained by a diverse team of developers. Because Sencha tools and frameworks are becoming the preferred development platform in this ecosystem, the Professional Services team has been helping our customers define their internal policies, training procedures and best practices in order to facilitate a transition to this new standard.

Why Development Standards Matter

Why Development Standards Matter

As a consultant, I constantly preach the benefits of having maintainable code:

  • Applications are faster to produce
  • Applications are easier to debug
  • New features are easier to add
  • Code has fewer bugs
  • New developers can be trained quickly

We all know that time equals money, so applications that take less time to create and maintain cost less money. Ultimately this makes managers, executives and shareholders happy. Because enterprise companies have many applications in production (both internal and external), it is critical that each member of the development team be able to jump onto any project in order to deliver on time and stay under budget.

Enterprise development teams often employ many developers distributed across large areas and contain a wide variety of skill sets. By standardizing the training, tools and best practices enterprises hope to decrease development time and costs while increasing the quality and lifespan of their applications.

Sencha as a Standard Platform

Sencha as a Standard Platform

When enterprises decide to make Sencha tools and frameworks a standard for application development, they’re often communicating a need for consistency across their internal and external applications. This consistency usually includes both the UI (styling, widgets, functionality) and the underlying code (architecture, libraries, best practices).

Every company using Sencha tools and frameworks should consider creating a centralized repository of resources and best practices for their development teams. While the specifics of these resources might differ between companies, the following areas should be clearly documented to help developers get started and maintain consistency across projects.

Developer Onboarding and Training

In my experience working in an enterprise, it can be difficult to get the tools you need installed on your machine.

Most enterprise companies have a highly defined IT infrastructure, so new developers are forced to wait while all required hardware and software meets approval. This process can often take days to complete, and afterwards workers remain unsure how to request additional resources. In short, new developers lack access to a clear onboarding roadmap.

For Sencha customers, I recommend that a handful of onboarding procedures be clearly documented to lubricate this process:

  • Required development tools
  • The process for requesting network credentials
  • Standard development workflows
  • How to access the Sencha forums and support portal
  • What Sencha training opportunities are recommended/offered

It’s important to remember that while developers don’t need this information on a frequent basis they need to know how to access it.

Supported Platforms

Supported Platforms

One benefit of working in an enterprise is that developers usually know the exact specifications of the environments they need to support, but historically these environments have been troublesome for web applications.

As enterprises move forward with hardware and software upgrades, it is important that developers deliberately document their current list of supported environments. This list might include things like:

  • Browsers (e.g. IE8, Firefox)
  • Operating Systems (e.g. Windows XP,7)
  • Devices (e.g. Lenovo ThinkPad)

Having this knowledge clearly defined before starting new projects (and while maintaining legacy applications) helps to improve the accuracy of the delivered products. It also allows developers time to request any new hardware/software for testing.

In some cases support for IE6 and IE7 are being dropped completely!

On the other hand, this knowledge also helps to point out potential weaknesses. For example, the latest Firefox versions will auto-update themselves and support a wide variety of modern web standards; IE8 does not. Developers who understand those implications can avoid development practices that might collide with the defined supported platforms.

It is also important to document the specific products or platforms being used in the development process. This list might include:

  • Frameworks (e.g. Ext JS 4.1.x, ASP.NET MVC 4)
  • 3rd party libraries or components (e.g. other charting packages)
  • Supporting technologies (e.g. SASS)
  • Workarounds (e.g. using JSONP)

This supplementary list is not only helpful in defining what products or platforms are required for development, but it can also define the skill sets necessary for employee acquisition and training.

Internal Best Practices

Development teams should also decide on a list of best practices, so all developers can contribute code without compromising maintainability.

The list of best practices can be short and high-level or long and detailed; the choice often depends on the size of your team and how the developer roles are organized.

For example, some high-level best practices might include:

  • Overall architectural decisions (e.g. namespacing, file structure)
  • Security implementations
  • Error handling
  • Shared libraries and custom components (UX)
  • Documentation
  • Testing, builds and deployment

...while some low-level best practices might include:

  • Whitespace usage
  • Commit practices
  • Console usage
  • Browser Strict vs quirks mode

In my experience, enforcing the low-level best practices is difficult to do without mandatory code reviews. While code reviews are a fantastic way to teach junior developers, maintain code quality and stimulate creativity, it’s not something typically done in most enterprises.

What are your thoughts?

This article highlights some ideas for implementing development standards in large organizations but is far from a comprehensive plan. The Sencha Professional Services team provides a variety of services including high-level architectural reviews, deep analysis of application performance, custom UX development and everything in-between, and we can tailor an engagement to fit each customer’s specific needs. The concepts above are a good start and should translate easily into any business.

If your company has implemented a set of development standards, please share your thoughts and experiences!

There are 4 responses. Add yours.

Corky Wicks

2 years ago

Best Practice for Automation Question Feedback Request:
As we develop better tools for producing “end-user friendly” applications, what can I do as QTP automation specialist to provide the best automation tools for my team? We have found that both Selenium and QTP have trouble consistently locating dynamic html id tagged items. There is power in being able to automate testing, but many techniques use to speed up development negatively impacts our ability to automate effectively.

Do you have any “best practice” options for automated testing?

Arthur Kay

2 years ago

Corky - you might look into a tool named “Siesta” made by Bryntum. It automates integration tests in a similar manner to Selenium, but it works much better with the Sencha frameworks for specifically the reasons you mention.

In terms of “best practices” for automated testing, the first thing you need to do is decide what your goals are. Testing can accomplish many things - but I always warn that automated tests should never completely replace physical QA testing.

Holger Schäfer

2 years ago

We are currently developing UIs for SAP Software using ExtJs and Touch. For that reason we have implemented ExtDirect inside SAP (Application Server ABAP) because there is no such implementation in the forum/marketplace.

Beside the new Soap Proxies that are addressing the enterprise we only use soap inside misddleware. The problem is to store user data and passwords for the connection inside client side javascript.Do you have best practises to workaround this need inside javascript?

Currently SAP is heavily focusing on Microsofts oData standard, so this would be a very useful proxy inside the Ext Framework.

Since Ext 4 it is more easy to use jquery beside Ext Core. Maybe for future needs i have to research how to create Ext wrapper components that render jquery widgets but can be used the Ext way including initialisation and desctruction. I did not found any deeper example except Loaine’s example.

One of the most pros for Ext is using Architect for designing views. Currently there is no designer for the SAPUI5 framework. I am thinking about using SA for SAP view design via a post ant task to search/replace library differences, because there are a lot of things in common. (items:.. will be Content: ..., xtype will be ClassName, etc).

Concerning Theming Ext 4.2 did a great step into the right direction using the new packages, but i think something like the Twitter Bootstrap Famework would be also a great starting point for custom designs.

Sometimes it is good to be different, but a shared wider open approach for theming like Bootstrap would make theming much more efficient and easy.

If you have any best practises or updates on addressed topics, please let me know.

Kazuhiro Kotsutsumi

2 years ago

I translated it into Japanese.

http://www.xenophy.com/extjsblog/6687

Provision: Japan Sencha User Group
http://www.meetup.com/Japan-Sencha-User-Group/about/

Comments are Gravatar enabled. Your email address will not be shown.

Fields marked with * are required.