Забыли упомянуть Линтер, который пытались внедрить и который ставил в тупик даже опытных разрабов и не прижился, уступив место грамотно созданному (не сразу) регламенту.
Про новеньких:
Бывало, что два "относительно новеньких" встают на ревью в сетке двойного ревью, которые апрувят и сливают сразу свой код с явными ошибками. Такую ситуацию подсвечивали обоим и в дальнкйшнм было меньше ошибок (но по началу приходилось поглядывать за ними).
По поводу частичного ревью и конфликтов ревьюера и разработчика согласен, но, каюсь, пару раз так делал, чтоб разработчик сам весь код подправил по начальным замечаниям. Процесс долгий и реально приводит к конфликтам, поэтому отказался.
Как всегда остаётся дилемма - качество кода (только согласно регламента) против скорости отдачи задачи в тест. Весы шатаются и ревьюеру важно проявлять стойкость и приводить доводы своих замечаний. Желательно с ссылками на регламент. Бывало, что хотят обойти регламент фразой "работает же", упираясь в непоколебимость регламентных требований и "твёрдого" ревьюера :)
Ну и, естественно, я также был и есть со стороны разработчика, которому подсвечивают лишние пробелы, пропущенные точки с запятой и т.д. Вызывает негодование из-за лишней итерации задачи, но с годами маты сменились на "хмм, точно, ща подправлю".
Про рефакторинг полностю согласен. Если разраб не хочет править код вне своего, но видно, что его правки выделяются, решение остаётся за разработчиком, но в задаче желательно отписать, что форма требует дальнейшего рефакторинга. Такие комменты особо никто не воспринимает, но зато разраб все свои мосты грамотно уничтожил и к нему не подкопаться потом.
Про "противоположные рекомендации" первый раз увидел, такого не должно быть, но если есть, нужно реально вычишать "серые зоны" общением. Благо все открыты для диалога. И тут реально будет спасать регламент написания кода (который после обсуждений реально подправить и всем подсветить, такое было).
Статья хорошая, я бы добавил пару матов ещё в ней 😂
Я забыл написать в статье, что выбрал путь Google Script только из-за доступности.
Не спорю, хороший телеграм-бот сможет всё это делать, но обычный пользователь, не программист, в большинстве случаев не захочет разворачивать сервер для поддержания бота, плюс писать/улучшать код для него.
А в моей статье хватит обычного копипаста и двух аккаунтов — Google и Telegram для завершения задачи.
Stylus достаточно мощный инструмент плагин и данная статья тому доказательство.
Нашёл данный плагин случайно и создав пару новых стилей, использую даже на работе.
Забыли упомянуть Линтер, который пытались внедрить и который ставил в тупик даже опытных разрабов и не прижился, уступив место грамотно созданному (не сразу) регламенту.
Про новеньких:
Бывало, что два "относительно новеньких" встают на ревью в сетке двойного ревью, которые апрувят и сливают сразу свой код с явными ошибками. Такую ситуацию подсвечивали обоим и в дальнкйшнм было меньше ошибок (но по началу приходилось поглядывать за ними).
По поводу частичного ревью и конфликтов ревьюера и разработчика согласен, но, каюсь, пару раз так делал, чтоб разработчик сам весь код подправил по начальным замечаниям. Процесс долгий и реально приводит к конфликтам, поэтому отказался.
Как всегда остаётся дилемма - качество кода (только согласно регламента) против скорости отдачи задачи в тест. Весы шатаются и ревьюеру важно проявлять стойкость и приводить доводы своих замечаний. Желательно с ссылками на регламент. Бывало, что хотят обойти регламент фразой "работает же", упираясь в непоколебимость регламентных требований и "твёрдого" ревьюера :)
Ну и, естественно, я также был и есть со стороны разработчика, которому подсвечивают лишние пробелы, пропущенные точки с запятой и т.д. Вызывает негодование из-за лишней итерации задачи, но с годами маты сменились на "хмм, точно, ща подправлю".
Про рефакторинг полностю согласен. Если разраб не хочет править код вне своего, но видно, что его правки выделяются, решение остаётся за разработчиком, но в задаче желательно отписать, что форма требует дальнейшего рефакторинга. Такие комменты особо никто не воспринимает, но зато разраб все свои мосты грамотно уничтожил и к нему не подкопаться потом.
Про "противоположные рекомендации" первый раз увидел, такого не должно быть, но если есть, нужно реально вычишать "серые зоны" общением. Благо все открыты для диалога. И тут реально будет спасать регламент написания кода (который после обсуждений реально подправить и всем подсветить, такое было).
Статья хорошая, я бы добавил пару матов ещё в ней 😂
У меня ещё идея была сделать две педали под столом. Левая нога CTRL+C, правая CTRL+V.
Ускорит копипаст и ноги разомнутся :)
Сделал статью с подробным разбором хронологии Стражей Галактики, собственно это и была начальная часть идеи, с которой родилось дерево.
Не спорю, хороший телеграм-бот сможет всё это делать, но обычный пользователь, не программист, в большинстве случаев не захочет разворачивать сервер для поддержания бота, плюс писать/улучшать код для него.
А в моей статье хватит обычного копипаста и двух аккаунтов — Google и Telegram для завершения задачи.
инструментплагин и данная статья тому доказательство.Нашёл данный плагин случайно и создав пару новых стилей, использую даже на работе.