3 ms·

I followed the same pattern when I had the time to. Instead of building the thing, build it as a separate package and include it as a dep. Packaging code up for

by ryanar 5y ago

I followed the same pattern when I had the time to. Instead of building the thing, build it as a separate package and include it as a dep. Packaging code up for open source consumption leads to better docs, tests, and tighter abstractions that are generalized.

janto 5y ago
I think that's the opposite of what the parent says: first build the thing and only then factor it out and reinclude it.
- ChrisMarshallNY 5y ago
  Not completely. The way that it works for me, is that I start work on a project, and, while building, I notice that some code that I'm working on is: 1) Pretty complex, and fairly insular; and/or 2) Possibly useful, elsewhere. If that's the case, I will then stop work on the main project, and take some time to extract and "genericize" the subproject. I'll usually set it up as a standalone open-source project; complete with tests and documentation. As the commenter stated, I think that this results in some excellent code. I always clean the house before the guests arrive. This may happen before I have completed the coding in the main project, or may happen as the result of a review, after the fact. In some cases, I very clearly need to develop a subproject before starting on the main project, or before certain milestones within that project (for example, SDKs or drivers). In that case, the timelines are completely separate. If you look at my GH repos, you'll see a whole bunch of these projects, including some rather strange ones, like an XML duration parser[0]. These are the types of projects that I extract. In some cases, I end up not using the extracted project in my main project (happens to some of my UI widgets). In that case, even though I am not using it, I still have an excellent project for the future. Here's an example[1]. I have ended up not using the spinner in my own work, as it was too obtrusive a widget, but it's nice to have it available for future projects. [0] https://github.com/RiftValleySoftware/RVS_ParseXMLDuration https://github.com/RiftValleySoftware/RVS_ParseXMLDuration [1] https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_Spinner

by ryanar 5y ago

janto 5y ago

I think that's the opposite of what the parent says: first build the thing and only then factor it out and reinclude it.

ChrisMarshallNY 5y ago
Not completely. The way that it works for me, is that I start work on a project, and, while building, I notice that some code that I'm working on is: 1) Pretty complex, and fairly insular; and/or 2) Possibly useful, elsewhere. If that's the case, I will then stop work on the main project, and take some time to extract and "genericize" the subproject. I'll usually set it up as a standalone open-source project; complete with tests and documentation. As the commenter stated, I think that this results in some excellent code. I always clean the house before the guests arrive. This may happen before I have completed the coding in the main project, or may happen as the result of a review, after the fact. In some cases, I very clearly need to develop a subproject before starting on the main project, or before certain milestones within that project (for example, SDKs or drivers). In that case, the timelines are completely separate. If you look at my GH repos, you'll see a whole bunch of these projects, including some rather strange ones, like an XML duration parser[0]. These are the types of projects that I extract. In some cases, I end up not using the extracted project in my main project (happens to some of my UI widgets). In that case, even though I am not using it, I still have an excellent project for the future. Here's an example[1]. I have ended up not using the spinner in my own work, as it was too obtrusive a widget, but it's nice to have it available for future projects. [0] https://github.com/RiftValleySoftware/RVS_ParseXMLDuration https://github.com/RiftValleySoftware/RVS_ParseXMLDuration [1] https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_Spinner