I've found that most of the time dev teams use async workflow for code reviews. But it delays releases and leads to a lot of postponed context switches. In my experience, sync code reviews that have higher priority over other tasks is a much more productive workflow. With sync reviews we can deliver faster and improve the quality of the codebase
We have tried to show the most important events in the history of space exploration: first spacecrafts, flights to other planets and landings on celestial bodies.
We believe that achievements in space belong to all mankind. We believe that space exploration is a significant step in the evolution of our civilization.
My current company is transforming into Agile right now, and I find this article is very good description of all these crazy stuff which happen in the company:
> Until today’s meeting, the friendly Agile consultant at my company has spent his time photoshopping the team leader’s face onto pictures of Yoda, and researching the motivational properties of various colours of magic marker. And he gets paid for it.
When I started a new React-project at my work, I asked myself: "Why do I need any external dependencies for state management such as Redux or MobX? What functionality from this dependencies do I need in the first place?".
I realised that I just want to have many views connected to one dataset, and I want to re-render all connected views when dataset was changed. This is a simple pub-sub pattern which everyone can implement himself. So, I implemented it myself in just 65 lines of code. I use this solution in production for 6 months and don't see any drawbacks.
What are the advantages of Redux or MobX over this solution?
Functional UI is still need some sort of imperative shell [1] to manage state. You can use OOP and Remold just for "reactive" behaviour, and implement all state transitions inside object in a functional way. For example:
// Pure function
const addProduct = (order, product) => ({
total: order.total + product.price,
});
// Imperative state
class Order extends Remold {
state = {
total: 0
};
@act setState(newState) { this.state = newState; }
addProduct(p) { this.setState(addProduct(this.state, p)); }
}
> What are the advantages of this solution over features already in React (no need of Redux) such as context and the reduce hook?
From the React Documentation about Context feature [2]:
> Apply it sparingly because it makes component reuse more difficult.
With Remold you don't have any problems with component's reusability. You just attach pure component to an object and "connect" object's state into component's props:
// Pure component
const OrderWidget = ({ total }) => <div class="widget">{total}</div>;
// Pure function
const addProduct = (order, product) => ({
total: order.total + product.price,
});
// Imperative state
class Order extends Remold {
state = {
total: 0
};
@act setState(newState) { this.state = newState; }
addProduct(p) { this.setState(addProduct(this.state, p)); }
@mold(OrderWidget) asWidget() { return { total: this.state.total }; }
}
Redux also has some more nice features around middleware which is great for data interception and manipulation, and selectors which can be great for performance if memoized. Also, you don't need redux for it, but the idea of separating pure view code and code that does network calls and implements business logic is really useful.
At the end of the day, you can write whatever you want from scratch, but it becomes a cost/benefit analysis.
Totally agree with you. React is just an API which enhances vanilla JavaScript. In React it's possible to use all prior knowledge and practices from other languages, eg functions/objects composition, and decoration.
Vue is different. With it, you can't confidently use your previous programming experience.
You can do what you want just in 17 lines of pure JavaScript. This is an example:
const
create_store = ({state, actions}) => {
const
after_update_do = [],
subscribe = fn => after_update_do.push(fn),
notify = () => after_update_do.forEach(fn => fn(state)),
create_action = action => (...args) => {
state = action(state, ...args);
notify()
};
return Object.entries(actions).reduce((bound_actions, [action_name, action]) =>
Object.assign({}, bound_actions, {[action_name]: create_action(action)}),
{subscribe})
},
counter = create_store({
state: 0,
actions: {
increase: state => state + 1,
decrease: state => state - 1,
multiply_add: (state, a, b) => state * a + b,
},
});
counter.subscribe(state => console.log('First reactive component was updated with: ' + state));
counter.subscribe(state => console.log('Second reactive component was updated with: ' + state));
Now you can call all actions directly from the counter and update all components in reactive manner.
counter.increase();
// First reactive component was updated with: 1
// Second reactive component was updated with: 1
counter.multiply_add(2, 3)
// First reactive component was updated with: 5
// Second reactive component was updated with: 5
Not all notes belong in shared source code. I take notes on overall code structure and oddities, but also debug output, commands I've run, daily todos, thoughts on papers, experimental results, etc.
I used to save markdown files to git, but 1.) search was difficult and 2.) sometimes I wanted to see the evolution of a project while other times I wanted notes by day.
This project aims to make it easier to record and recall knowledge that teams need and take for granted. I tend to think about onboarding new members, how projects are run, and very specific, technical challenges not on Stack Overflow.
I'm open to feedback. I want to continue to push down a wiki/knowledge base path, but i'm not sure how other teams currently manage stale knowledge and dissemination of technical info.
Notes are structured differently than source code. My notes contain things like tasks, each affecting many source files, sometimes dozens, design notes affecting the code globally, and even plain brain dumps, which would be best left unshared.
Personally, I generate at least as much prose in notes as I do lines of source code, so there would also be readability issues.
Have you tried a pair programming? I realized that this practice much more effective than code review. Pair programming encourages learning inside a team, interactions and code quality. It also reduces time to market.
I'm learning Erlang right now and find that every OTP behavior has main parts in its API: client, server, possible inputs and possible outputs. But a one-dimensional structure of standard documentation (from top to bottom) can't present all these parts in one place which leads to loss of a context and longer learn-curve. That's why I create this cheat sheet to present OTP behaviors in one place using opportunities of a two-dimensional structure.
