5 ms·

That is some high-quality code (minus the lack of tests). Nice job!

by sibeliuss 7y ago

PetahNZ 7y ago
Am I missing something, from the 10 minutes I spent poking around this is mediocre at best.
- sibeliuss 7y ago
  I'm not sure what codebases you've worked on, but this is hardly "mediocre" in any sense of the word. It's highly organized, consistent and modular. The toolchain is modern and set up well. The code is easy to read. There are folks the world over that would find working in this codebase a joy, and would be able to easily jump in and start contributing at any level of the stack.
sverhagen 7y ago
Maybe it's very readable, but in some circles production code with no tests is considered per definition low quality. Or: if there's no tests, the code "doesn't exist".
- PetahNZ 7y ago
  What about the myriad of try catch console.log. With the statement in the readme "Database & file-based logging" unless they are overriding console, then I don't even know what they mean. https://github.com/Viveckh/Veniqa/search?q=console.log&unscoped_q=console.log https://github.com/Viveckh/Veniqa/search?q=console.log&unsco...
- greatmango 7y ago
  let me guess - the people in those circles work for either already-profitable companies or companies flush with venture capital, rather than a company trying to get off the ground before it runs out of money?
  - sverhagen 7y ago
    I have worked for either established and startup companies (admittedly with varying success). I think it has more to do with the composition of the team. As engineers there are a lot of different experiences we can bring to the table, but some of us have had the transformative experience of being on projects where the testing was right, in how to do and the amount, and we have seen how it helps us on a daily basis to move faster and be humbled by the bugs that we'd otherwise have released, or that we'd otherwise would've had to troubleshoot on a remote system rather than fixing them minutes after creating them. I'm now making it a point to expose my team members to the same awesome experience. But I also understand that, as you're building a startup team, and there are many things you have to get right, this may be a skill you would go without. Also, I'm not advocating 99+% test coverage for new (startup) projects, but one could start with some tests selectively for core functionality or the most complex parts, and already enjoy a great overall benefit.
- nicoburns 7y ago
  That seems pretty absolutist. Tested code is only as good as the tests themselves. I'd take readable, reliable code which covers all the corner cases over tested code that doesn't actually work reliably any day. Of course, tests can help you achieve this kind of high quality code, and good tests have other benefits like helping you to prevent regressions when modifying the code, but you can still have high quality code without them and low quality code with them.
  - amoitnga 7y ago
    in my experience, taken from projects I worked on with and without tests, even bad tests are better than no tests at all. No tests usually good indicators that there will be a lot of repeated and overcomplicated code. Having a solid test coverage allows you to change/extract functions at any point when you see something is getting outta shape. With no tests, however, it's much easier and less scary to add rather than change. People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. Also, oftentimes, especially on the server side, it's just easier to implement/verify with automated test from the start rather than by hand. None of it is related to the OP codebase, just thoughts in the abstract.
    - sibeliuss 7y ago
      I tend to think about tests as insurance. Without them, you're flying blind.
    - speedplane 7y ago
      > People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. I certainly hope that quality testing is more than just your preference or even a good practice: it's now a central part of software development. At this point, we know enough about the benefits of good testing to say that it's practically malpractice to not have them. Good tests may not be a strong enough signal to conclude that a project is good quality, but lack of tests is a clear sign that a project is low quality.
tnolet 7y ago
What makes you say it’s high quality? Can you point out specifics?
- deleted 7y ago
  [deleted]

That is some high-quality code (minus the lack of tests). Nice job!

PetahNZ 7y ago

Am I missing something, from the 10 minutes I spent poking around this is mediocre at best.

sibeliuss 7y ago
I'm not sure what codebases you've worked on, but this is hardly "mediocre" in any sense of the word. It's highly organized, consistent and modular. The toolchain is modern and set up well. The code is easy to read. There are folks the world over that would find working in this codebase a joy, and would be able to easily jump in and start contributing at any level of the stack.

sverhagen 7y ago

Maybe it's very readable, but in some circles production code with no tests is considered per definition low quality. Or: if there's no tests, the code "doesn't exist".

PetahNZ 7y ago
What about the myriad of try catch console.log. With the statement in the readme "Database & file-based logging" unless they are overriding console, then I don't even know what they mean. https://github.com/Viveckh/Veniqa/search?q=console.log&unscoped_q=console.log https://github.com/Viveckh/Veniqa/search?q=console.log&unsco...
greatmango 7y ago
let me guess - the people in those circles work for either already-profitable companies or companies flush with venture capital, rather than a company trying to get off the ground before it runs out of money?
- sverhagen 7y ago
  I have worked for either established and startup companies (admittedly with varying success). I think it has more to do with the composition of the team. As engineers there are a lot of different experiences we can bring to the table, but some of us have had the transformative experience of being on projects where the testing was right, in how to do and the amount, and we have seen how it helps us on a daily basis to move faster and be humbled by the bugs that we'd otherwise have released, or that we'd otherwise would've had to troubleshoot on a remote system rather than fixing them minutes after creating them. I'm now making it a point to expose my team members to the same awesome experience. But I also understand that, as you're building a startup team, and there are many things you have to get right, this may be a skill you would go without. Also, I'm not advocating 99+% test coverage for new (startup) projects, but one could start with some tests selectively for core functionality or the most complex parts, and already enjoy a great overall benefit.
nicoburns 7y ago
That seems pretty absolutist. Tested code is only as good as the tests themselves. I'd take readable, reliable code which covers all the corner cases over tested code that doesn't actually work reliably any day. Of course, tests can help you achieve this kind of high quality code, and good tests have other benefits like helping you to prevent regressions when modifying the code, but you can still have high quality code without them and low quality code with them.
- amoitnga 7y ago
  in my experience, taken from projects I worked on with and without tests, even bad tests are better than no tests at all. No tests usually good indicators that there will be a lot of repeated and overcomplicated code. Having a solid test coverage allows you to change/extract functions at any point when you see something is getting outta shape. With no tests, however, it's much easier and less scary to add rather than change. People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. Also, oftentimes, especially on the server side, it's just easier to implement/verify with automated test from the start rather than by hand. None of it is related to the OP codebase, just thoughts in the abstract.
  - sibeliuss 7y ago
    I tend to think about tests as insurance. Without them, you're flying blind.
  - speedplane 7y ago
    > People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. I certainly hope that quality testing is more than just your preference or even a good practice: it's now a central part of software development. At this point, we know enough about the benefits of good testing to say that it's practically malpractice to not have them. Good tests may not be a strong enough signal to conclude that a project is good quality, but lack of tests is a clear sign that a project is low quality.

tnolet 7y ago

What makes you say it’s high quality? Can you point out specifics?

deleted 7y ago
[deleted]