Skip to main content
Software Engineering

Return to Answer

Typography. Always make space after interpunction.
Source Link
Jan Hudec
Jan Hudec
  • 18.4k
  • 1
  • 41
  • 64

Point 2 is reasonable argument against the use of the given approach.I I worked on something similar where user can have data in different form depending on the entry point.Obviously Obviously,complexity complexity of your code is going to increase as per the number of new flows you introduce but depending on benefits involved sometimes you have to add new user flows.If If you do not have use cases with insanely high branching factor,you you can easily manage complexity if you focus on few things.

Try to make things readable at each level.Whether Whether you are exposing your API or writing code,keep keep everything meaningful both for your programmers and API users.If If you take care of readability,smaller smaller things like naming etc.,things things will become less complex.

Do not rely on data patterns in your storage expect a few key fields,you you will have to be careful while defining what is you always going to have.For For example,you you have created your API assuming,you you will always have this field filled by the user but then you introduce a new use case where that field is not mandatory.You You might have hard time changing your code for that.

Follow standard coding principles that our elders have been teaching us like KISS,SOLID SOLID,design design patterns etc.This This one also includes my first point but that has been mentioned separately because that is the worst thing in a complex scenario.

Point 2 is reasonable argument against the use of the given approach.I worked on something similar where user can have data in different form depending on the entry point.Obviously,complexity of your code is going to increase as per the number of new flows you introduce but depending on benefits involved sometimes you have to add new user flows.If you do not have use cases with insanely high branching factor,you can easily manage complexity if you focus on few things.

Try to make things readable at each level.Whether you are exposing your API or writing code,keep everything meaningful both for your programmers and API users.If you take care of readability,smaller things like naming etc.,things will become less complex.

Do not rely on data patterns in your storage expect a few key fields,you will have to be careful while defining what is you always going to have.For example,you have created your API assuming,you will always have this field filled by the user but then you introduce a new use case where that field is not mandatory.You might have hard time changing your code for that.

Follow standard coding principles that our elders have been teaching us like KISS,SOLID,design patterns etc.This one also includes my first point but that has been mentioned separately because that is the worst thing in a complex scenario.

Point 2 is reasonable argument against the use of the given approach. I worked on something similar where user can have data in different form depending on the entry point. Obviously, complexity of your code is going to increase as per the number of new flows you introduce but depending on benefits involved sometimes you have to add new user flows. If you do not have use cases with insanely high branching factor, you can easily manage complexity if you focus on few things.

Try to make things readable at each level. Whether you are exposing your API or writing code, keep everything meaningful both for your programmers and API users. If you take care of readability, smaller things like naming etc., things will become less complex.

Do not rely on data patterns in your storage expect a few key fields, you will have to be careful while defining what is you always going to have. For example, you have created your API assuming, you will always have this field filled by the user but then you introduce a new use case where that field is not mandatory. You might have hard time changing your code for that.

Follow standard coding principles that our elders have been teaching us like KISS, SOLID, design patterns etc. This one also includes my first point but that has been mentioned separately because that is the worst thing in a complex scenario.

Source Link
WordsWorth
WordsWorth
  • 621
  • 1
  • 6
  • 9

Point 2 is reasonable argument against the use of the given approach.I worked on something similar where user can have data in different form depending on the entry point.Obviously,complexity of your code is going to increase as per the number of new flows you introduce but depending on benefits involved sometimes you have to add new user flows.If you do not have use cases with insanely high branching factor,you can easily manage complexity if you focus on few things.

Try to make things readable at each level.Whether you are exposing your API or writing code,keep everything meaningful both for your programmers and API users.If you take care of readability,smaller things like naming etc.,things will become less complex.

Do not rely on data patterns in your storage expect a few key fields,you will have to be careful while defining what is you always going to have.For example,you have created your API assuming,you will always have this field filled by the user but then you introduce a new use case where that field is not mandatory.You might have hard time changing your code for that.

Follow standard coding principles that our elders have been teaching us like KISS,SOLID,design patterns etc.This one also includes my first point but that has been mentioned separately because that is the worst thing in a complex scenario.