4 ms·

I don't have time to implement a tool for implementing CRUD. Wouldn't it be better to not have so many layers of abstraction that you need a tool in the first p

by meuk 9y ago

I don't have time to implement a tool for implementing CRUD. Wouldn't it be better to not have so many layers of abstraction that you need a tool in the first place? Let me elaborate on what it took me to implement a CRUD controller. I had to implement a repository interface, a respository a context, a service interface, and a controller. Then I had to understand how to write the swagger documentation. Then there is a convention of wrapping every result and exception in some kind of wrapper, which is not documented so I had to figure this out from looking at other controllers. Then I saw a execution path for another CRUD controller which could throw an error which was not in this wrapper, so I had to discuss this with someone from the team. Sure enough, he is in another country, and takes a while to respond. I was lucky it was still morning, or he would have gone home already (there's a 4 hour time difference). Sure enough, this was a bug in the other controller. Then, there is a logging and a monitoring service I had to understand and implement. Undocumented, of course. The controller I used as a reference was inconsistent in monitoring, so I had to discuss this. Then, the requirements for the controller are not clear. The RESTful way of responding to a GET request for a nonexisting resource would be a 404, but the wrapper does not allow this. The reference controller returns 200 OK, but with a null value. So I had to check if this is indeed what's intended. Then I had to figure out how the unit testing framework works and I had to write tests for each method. OK, good practice, but it feels a bit weird, since the unit tests should not use the database while the entire purpose of the CRUD controller is to use the database. So much of the logic I'm supposed to test is mocked. So, I had to learn how the mocking framework works. Then I wanted to write unit tests for the repository, but entity framework crashes when I use an in-memory database. The other developers had a look, but didn't understand this either. The other repository implementations are not tested anyway, so I skipped this. Additionally, visual studio crashed, corrupted my git repository, and I ended up deleting and cloning the whole repo again. Then, I had to configure the project again before it would build, which involves opening the project in an older version of visual studio, then opening the same project in the latest version (some errors magically disappear), and adjusting the IIS settings (which are a mystery to me). I also had a long meeting to attend, and the person who's supposed to get me started didn't have time to help me. In the end, I'm still not quite happy with the actual logic in the controller (it has inconsistencies similar to the controller I used as a reference), but I refuse to spend more time on it.

Sammi 9y ago
Look, work is always pain. That's why they give you money for doing it. The real question is what kind of pain are you willing to endure and why are you willing to endure that pain? Is there a problem that you think needs solving, that you are willing to endure pain for?
atoko 9y ago
Most software is moving data around. All the abstractions you mentioned have a purpose. It makes sense to test each in isolation. For example, a controller whos’ service is a mocked implementation. You can test that your controller and its routes make the correct service calls without ever hitting a database. About the documentation, maybe you’re the one to take initiative and spin up a wiki? Maybe you’re the person that consolidates logging into a reusable internal library? Related to the topic, maybe this is not what you should be doing. There is good work out there, but as cliche as it sounds, you have to show passion for them to find you.
marvin 9y ago
Hope you won't get me wrong here; this sounds to me like the million details required to implement something properly, and certainly a task like the one you describe here would take a workday or two to implement properly. But it does also sound like there are some problematic inefficiencies in the way your company's software stack is set up. Common tasks like logging, caching and error handling should be abstracted away to a separate layer so that you get it for free whenever you implement a new service or endpoint. Don't know if this is old news to you, but check out e.g. [1]. This part about abstracting away rote work and optimizing a stack to be less maintenance-heavy is a learnable skill. The problematic part is that your working environment needs to have it in its culture. It needs to be okay for staff to spend a week here and there tuning a process that's used again and again. This is a big force multiplier which needs to be appreciated by management. I'm in an online banking company with an 18-year history and all the cruft that entails, and we're in aggregate spending multiple full-time positions continually upgrading our infrastructure and practices. Releases used to be one-week affairs that were performed twice a year. Now they're done in half an hour, most of which is verification and monitoring. Etc, etc. [1]: https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30...

by meuk 9y ago

Sammi 9y ago

Look, work is always pain. That's why they give you money for doing it. The real question is what kind of pain are you willing to endure and why are you willing to endure that pain? Is there a problem that you think needs solving, that you are willing to endure pain for?

atoko 9y ago

Most software is moving data around. All the abstractions you mentioned have a purpose. It makes sense to test each in isolation. For example, a controller whos’ service is a mocked implementation. You can test that your controller and its routes make the correct service calls without ever hitting a database. About the documentation, maybe you’re the one to take initiative and spin up a wiki? Maybe you’re the person that consolidates logging into a reusable internal library? Related to the topic, maybe this is not what you should be doing. There is good work out there, but as cliche as it sounds, you have to show passion for them to find you.

marvin 9y ago

Hope you won't get me wrong here; this sounds to me like the million details required to implement something properly, and certainly a task like the one you describe here would take a workday or two to implement properly. But it does also sound like there are some problematic inefficiencies in the way your company's software stack is set up. Common tasks like logging, caching and error handling should be abstracted away to a separate layer so that you get it for free whenever you implement a new service or endpoint. Don't know if this is old news to you, but check out e.g. [1]. This part about abstracting away rote work and optimizing a stack to be less maintenance-heavy is a learnable skill. The problematic part is that your working environment needs to have it in its culture. It needs to be okay for staff to spend a week here and there tuning a process that's used again and again. This is a big force multiplier which needs to be appreciated by management. I'm in an online banking company with an 18-year history and all the cruft that entails, and we're in aggregate spending multiple full-time positions continually upgrading our infrastructure and practices. Releases used to be one-week affairs that were performed twice a year. Now they're done in half an hour, most of which is verification and monitoring. Etc, etc. [1]: https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30...