renku

I think the main advantage of Markdown is that the source is equally readable without having to run it through a processor.

I don't think this really applies to this Mermaid library. For a Markdown-like I would expect more of an ASCII-art like input, which would look like the rendered chart also in its ASCII form.

What you mean to say: JavaScript is not class-oriented.

Sure, there are features that JavaScript lacks compared to other object-oriented languages, but saying that it's not object-oriented is like saying that it's statically typed. It's just wrong, the language is full of objects.

"robotic" part seems to be pure clickbait. From robotic you would expect something that would act autonomously. This one doesn't even seem to be automatic - requiring one to push a button or use some app to control it at the distance.

Then again, that latter part looks scary - can somebody push the button in app to close the bed while you're sleeping? Hopefully there are some sensors to detect whether it's safe to perform the moving.

...in case there are such sensors, it might actually be properly robotic. Unfortunately no information about safety of this all is not given.

The problems you describe aren't really problems with Code Review per se, rather with the process that's enforcing the reviews.

The idea of code reviews is that somebody else reads your code and provides feedback. Whether the reviewer is sent a pull request, a list of commits in master or a printout is a matter of implementation.

I see a cyclic problem in here: Reviews take lot of time -> developers want to get more done, not wait for a review -> so they send more changes to review -> reviews take even more time -> ...

I think the solution is to find ways to make reviews smaller instead. Breaking tasks to smaller pieces that take less time to implement and review. (But not by reducing the # of lines in diff - squeezing several changes into one commit is a sure way to make it harder to review.) Smaller reviews will also be more effective - with large reviews there's a tendency for a reviewer to wear off and just skim through the changes.

Of course that's easier to say than do... it's something I'm trying to do by myself and not fully succeeding.

It's hard to decide which are the critical changes. Even a single line change can have major consequences - where do you draw the line...

I guess both 100% code review coverage and 100% test coverage are extremes that one shouldn't worry too much about. But my suspicion is that 100% test coverage can do more harm than reviewing of each commit.

What are these "more direct and optimal measures" that are cheaper than code reviews?

In my experience code reviews are much cheaper than other means of raising software quality. For example unit tests only start to add real value after you have written a good bunch of them, so they form this regression-safety-net.

I haven't seen Continuous integration and refactoring being thrown out of the window because of code reviews. Quite the opposite. Code reviews usually ask the author to refactor his code further. Similarly I have no idea why one would stop continuous integration because of code reviews.