Single Reponsibility and Seperation Of Concerns in the real world

A straight forward example I encountered recently in a common lib I use at work.

The library is reasonably new and a work in progress I guess but the code has been in production for a while and the task was actually to merge the library with another ironicaly enough (side note: I read before that as opposed to the related principle Seperation of Concerns, Single Responsibility does not encourage over seperation). There is very little structure or code in both repos as is, the code to be merged was a utils library and the the other repo was a broader sdk. So I guess it did make sense to merge the two. 

I didn't want to complete the merge without dealing with a broadly named class called 'utils'. I had problems with the name anyway as the lib already had utils in the name. I have heard it said many times before that if you can't think of a good name for a class then you should probably consider splitting it up. This was particularly true here – and so I did. The utils class essentially contained file upload and file download functionality. The code in itself had been ported from one language to another and so I would consider it a little hairy. It was essentially an untidied grouping of functions relating to the two purposes already mentioned.

The upload and download functionality shared very little in the way of common functionality – I would have been less inclined to touch the class if they did. The download relied on axios and the upload the s3 sdk (Javascript). The upload had a little more complexity around security whereas the download was from a standard url (usually a signed url but not always). In my opinion there is no advantage at all in having these two concerns threated as one. So I seperated and the code base is better for it hopefully.

One thing I didn't do was group the File download and upload functionality into a files module – I left them with other utils such as a retry calculator and page counter.  As I said before the code base is quite small and I didn't want to over engineer. Also I am aware that I work with others who are less keen on abrstactions and so I don't want to step on toes or be rude. Thats important too!