My team is on the receiving end of extensibility requests. We are getting many quality requests, that we approve immediately – and deliver rapidly, typically in the next monthly update. However; we are also getting many requests that are not actionable. These we reject – asking for more details. We also observe some organizations bulk logging non-actionable requests. In these situations, we will also bulk reject them. The Japanese have a word for this: Muda.
This post describes good practices when logging extensibility requests, to ensure they are approved first time.
1. Don’t log requests until you are ready
If all you have is an overlayered 7.x version – then you are not ready to log requests, yet. There is not a 1:1 between overlayered code and extension requests. Typically, overlayerings can be refactored to extensions without any additional support. Our data shows that 80-90% of overlayering are already supported, and thus don’t require any extension request to be logged.
Read more: Migrate from overlayering to extensions.
2. Don’t requests things that are already supported
We are providing extensibility requests by the hundreds every month. If you are looking at an old code base like 7.3 – you are looking the wrong place. Do upgrade to the latest monthly update on latest version.
Read more: What’s new
3. Understand the platform’s extensibility features
The platform provides an immensely rich feature set for building extensions. Dive in, leverage them.
Read more: Creating extensions and X++ the most extensible language on the planet
4. Understand what extension points are
As part of migrating your solution to extensions; you should locally implement the extension points you need. You should iterate, test, refine, experiment in the process. The result should be crisp extension points that you can request.
Read more: Write extensible code and Relax model restrictions to refactor overlayering into extensions.
5. Don’t request Replaceable methods
Replaceable is tolerable in small doses; but otherwise poisonous. Not much different from sugar and caffeine. Replaceable has the same semantics as overlayering, just without the tooling. We try to avoid it whenever possible. If you request a large method to be replaceable, the request will be rejected. Instead propose a method extraction refactoring that crisply solves your requirements.
Read more: Hookable, Wrappable and Replaceable and Intrusive customizations.
6. Think twice before requesting additional parameters to existing methods
For backwards compatibility reasons we cannot do this. Yes, that is also true for optional parameters. In many cases, you can solve the requirements without the parameters using these techniques. If not, please log the request with proper explanation why – and we’ll consider obsoleting the existing method and introduce a new method.
Read more: Method signatures and Breaking changes.
7. Describe the business scenario
We are looking for what the end-user will experience with the request. A good template to follow is this: “In the <vertical industry> it is required for the <persona> to be able to <detailed description of task>, to support this we enable <detailed description of how the persona will do this, i.e. where to click, what to enter, etc.>”
8. Don’t request specific forms to be workflow enabled
We will not workflow enable forms one by one in the standard based on extension requests, instead the platform is working on supporting workflow enablement as extensions. If you have a dependency on this, do log a platform request to track this.
转载请注明：ww12345678 的部落格 | AX Helper » 记录可扩展性请求的提示 / Tips for logging extensibility requests