4 ms·

Less code, loose coupling. Do one thing and do it well. Keep the external API simple. It's always easier to change a small thing instead of a large thing. S

Less code, loose coupling. Do one thing and do it well. Keep the external API simple. It's always easier to change a small thing instead of a large thing. So make a small thing, and only make it a big thing if you absolutely have to. I think my favorite recent HN example of this was that article where Discord rewrote their "unread message count" service in Rust. They were able to make a huge change to a critical section slowly and incrementally because it was loosely coupled. The programming language they chose didn't matter, because it could just be changed. The implementation didn't matter because the consuming code didn't know about any implementation details. The change happened and all the other teams had to care about was that there weren't weird latency spikes anymore.

nikofeyn 7y ago
> Less code, loose coupling. Do one thing and do it well. Keep the external API simple. > It's always easier to change a small thing instead of a large thing. So make a small thing, and only make it a big thing if you absolutely have to. this is along the lines of what i was going to suggest. i prefer to code everything such that it does just one thing that is appropriately at the level or context it sits at. a function should just do one thing and have reliable outputs based upon inputs. a class should represent one thing. class methods should do one action. modules should collect functionality that does a thing. processes and servers should do a thing. and so one. if you build your system out of things only doing the thing they say they do, then it becomes clear when they're being changed in incorrect ways.