Comments by Ehouarn Perret (Top 5 by date)

I think you're overexagerating... a bit, I dont think I added that much entropy to the project, and for most of it, that can be easily changed into something a bit less trickier and more conventional but will increase a lot the number of lines for barely nothing... that's always the same old song.

I don't think it has something to do with the architect... or maybe you're probably have any good idea about how to make it better. But you're probably gonna defend yourself with the fact that there is not enough details... wait the post was not long enough? I think that if it sounds already that much doogy for you, that means there is already something to tell about the organization / architecture / code...

I'm working in startup and as for now we do not have that many guys to code, (aka we are two and we have plenty of other projects to deal with, plus meetings, plus support, plus unit tests, plus other libraries, plus UI...), I guess what we have done so far is not that bad cause we still have customers and many new projects, and soon we're gonna add three guys to my team, so I was wondering how I could improve what has been already done.

Also I have this feeling that your answer is a little arrogant. No offense, this is just what I feel and it's probably not your intention.

Still that's true that there is no proper section for such analysis, so I just gave a try here. I'm terribly sorry, if, to you, was so disturbing.

Well thanks your feedback, it's hard to tell more about the topic as it involves plenty of details...
But let's give a try:

Basically, we have different product:
- A Controller to perform measurement channel inputs (e.g. Current, Voltage, Frequency, Digital, Relay, etc.) and generate some signals on its outputs (AWG, Voltage, Frequency, Digital, etc.) and some typical automotive buses: CAN, LIN and K-LINE.
- A Unit, able to deal with the power supply and to embed several controllers.
- An Extension to perform some temperature measurements and bring, it's connected to the Unit.

The fact is the embedded team who (is charge of designing all the dirty stuff over the hardware) gave me the commands and acknowledgments are not really clear, neither user-friendly, and for some legacy reasons they're not gonna change that...
Mainly cause prior to that situation we used to have a software dealing directly with the commands and it was a huge huge huge mess. Since I decided to gather all the communication stuff in assembly dedicated to that. It allows btw to make instrument drivers (for NI LabVIEW) by wrapping the objects and methods of the assembly. I'm pretty proud of that cause it allows our systems to be used in many many different Software platforms (e.g. Matlab) and in our own software platforms as well. I also manage myself to make our assembly Mono compliant.

The protocol as it has been defined it not that extensible (not necessarily there is a need to make it extensible but I feel sometimes that it could be better).
Unit Command: {@}{UnitId}{XX}{_}{UnitMessageKeyword}{=Parameters}(if any){;}
Unit Acknowledgment: {#}{UnitId}{XX}{_}{UnitMessageKeyword}{=Answer}(if any){;}

Controller Command: {@}{ParentUnitId}{ControllerId}{_}{ControllerMessageKeyword}{=Parameters}(if any){;}
Controller Acknowledgment: {#}{ParentUnitId}{ControllerId}{_}{ControllerMessageKeyword}{=Answers}(if any){;}

Extension Command: {@}{ExtensionId}{XX}{_}{ExtensionMessageKeyword}{=Parameters}(if any){;}
Extension Acknowledgment: {@}{ExtensionId}{XX}{_}{ExtensionMessageKeyword}{=Parameters}(if any){;}

Controller Instead to provide a dummy interface with the command to the end users, I decided to gather messages and acknowledgment into things what really the user needs through properties, it's more natural as it really represents the Unit:
- Property (Category) Power Supply => Enabled { get; set; } / CurrentMax { set; get; } / Current { get; } / Voltage { get; set; }
- Property (category) Information => SubCategory Identifiers { get; } / SubCategory OperatingTimes { get; } / etc.
- Method On() // Turn On...
- Method Off() // Turn Off...
- Method Lock() // Remote Control Only
- Method Unlock() // Allow Manual Mode
- ReadOnlyKeyedCollection<controller,>
- Etc.

Lock() / Unlock() methods could be gathered as a Boolean Property Locked { get; set; }
The same for On() / Off() methods into Powered / On { get; set; } or whatsoever.

The fact is that we are making new products, some of them are based on the previous one: like a Controller which is out of the unit for the customers who do not need a big power supply.

I was just suggesting factories for better re-usability matters, the fact is my solution now is a bit boring to implement and I'd like to make things easier. The core of the troubles are that there is an underlying implementation of the messages. For some reasons a Message Keyword does not necessarily match a Command Implementation in the assembly, sometimes the possibilities for one keywords are simply too much (and can lead to have a lot of Nullable as properties of the message), therefore when it's possible a keyword can be used in different command implementations when the concerns are properly separated.

Message
^- Acknowledgment (Token Reception: Start / Stop)
^- AcknowledgmentUnit
^- AcknowledgmentController
^- AcknowledgmentExtension

^- Command (Token Transmission: Start / Stop)
^- CommandUnit
^- CommandController
^- CommandExtensi