Дмитрий Беляев

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

#!/bin/bash
DEBIAN_FRONTEND=noninteractive apt install mysql-server -y

use std::str;

let x: &[u8] = &[b'a', b'b', b'c'];
let stack_str: &str = str::from_utf8(x).unwrap();

const cancelable = fn => { // Создаётся функция cancelable, которая принимает функцию и сохраняет в переменную fn
  const wrapper = (...args) =>{ // Создаётся функция-обёртка, которая принимает любой набор аргументов
    if(fn) return fn(...args) // Если в cancelable была передана функция, то вызывает её с необходимыми аргументами
  }

  wrapper.cancel = () => fn = null // Добавляет свойство во wrapper для очистки переменной fn 

  return wrapper // Возвращает обёртку
}

const fn = par =>{ // Функция, которая оборачивается в декоратор со своим аргументом
  console.log('Function called, par:',par)
}

const f = cancelable(fn) // Создаёт обёртку вокруг fn

f('first') // Function called, par: first
f.cancel() // fn является переменной внутри cancelable, здесь мы её обнуляем
f('second') // Ничего не выводит, потому что условие у wrapper отрабатывает, только если функция есть

от выбора библиотек

что значит код

какая между ними разница

что я делаю не так

с какой-либо из «сторон дела»: пользователя, верстки, программирования, поисковых систем?