Тут пол статьи как раз о том, как они масштабировали etcd. Может это конечно и легко, но таки автор оригинала решил про это статью написать. Видимо для него это было не слишком просто сделать.
Конечно. Поэтому я и писал выше, что иногда достаточно подумать о том, как тестировать, чтобы в коде не было такого, что штрихкод не тестируется без базы.
Весь вопрос в сложности и типе проекта. Многопоточность, интеграция (с чем угодно) - это все сразу усложняет тестирование в разы. Причем один из таких случаев - это (тривиальная на вид) интеграция с любой СУБД. Все что мы тут можем - это сделать из этой интеграции, условно, что-то типа CRUD API, и тестировать с его моком. Что многие реальные классы ошибок ну ни разу не предотвращает.
Ничего не имею против тестов в целом, но есть куча случаев, когда они вообще ничего не дают. И да, я сам как раз из этой самой, инженерной школы.
В моей практике (а это сильно интеграционные проекты) - почти нет такой выгоды. То что мы иногда ловим в проме, всплывает лишь на одной интеграции скажем из 20 похожих. Не всегда на это просто написать тест даже постфактум. А уж предугадать заранее кейс, который потребует теста - вообще можно в редчайших случаях.
Это не значит что везде так, далеко не все проекты вообще такие.
Честно говоря, все эти решения имеют те или иные проблемы. Ну или ограничения, если хотите. Например, решения типа JOOQ предполагают, что у вас при компиляции структура базы такая же, как в проме. С одной стороны, вроде бы это плюс (вы примерно об этом пишете в п.1), а с другой - это далеко не всегда просто обеспечить. Просто потому, что база с которой вы работаете, может быть не ваша, и изменения в ее схему вносятся другой командой. Ну или вы просто заранее ничего не знаете про базу вообще, кроме того что она существует, и всю ее структуру можете добыть только при запуске, но не ранее.
Я не люблю вот этот формально-логический подход к оценке полезности тестов.
Если же подходить с практически-инженерной точки зрения, то каждый тест снижает вероятность того, что в тестируемом коде находится ошибка негативно влияющая на систему в целом.
Может вы и математику не любите?
Переформулирую другим способом: еще один, два или десять тестов не приближают вас ни на на миллиметр к гарантии того, что в коде нет ошибок. Тесты теоретически этого обеспечить не могут, только показать наличие. Доказательства правильности у вас не будет. В общем случае (насколько я понимаю, доказательство правильности сродни проблеме останова машины Тьюринга, которая не имеет решения).
В частных же конкретных случаях - ну да, вы можете написать тесты на некоторые сложные части кода, и спать спокойно, ибо ощущение усталости от проделанной работы написанные тесты конечно же дают :) И оно реально будет работать лучше - особенно с учетом того, что для написания тестов код надо немного понимать, а это положительно сказывается на его качестве само по себе. Даже если только задумать их писать и потратить время на это обдумывание.
И причем заметьте - вы приводите пример, когда одна ошибка не воспроизводится, и де факто на нее и тест написать невозможно (в моем понимании, многопоточная логика приложений вообще на сегодня тестами как следует не покрывается). А второй случай явного падения, при всех его неприятных последствиях, диагностируется за пять минут, и исправляется навсегда. Потому что ошибка обычно простая. И строго говоря, такие ошибки предотвращаются не тестами, а рефакторингом.
А представьте, что вы делаете такое исправление (на самом деле это не секунды вовсе, потому что зачастую проект еще собрать надо). И ваши пользователи, когда они видят ваш очередной релиз, читают release notes, и видят там что? Видят они задачу, где написано: "Заменил две константы на переменную, теперь SONAR счастлив". Лично для меня это будет хороший повод данный релиз не внедрять, а подождать следующего, когда автор сделает что-то более существенное.
Ну т.е. это не совсем общий нынешний уровень, если угодно, это скорее влияние качества кода на том микроуровне, где работают сонары и линтеры, на общее качество проекта. И это влияние ну оооочень опосредованное. Наверное не всегда, ведь проекты разные - но часто.
Ну да. Написали немного эмоционально, но по большому счету... Я тоже на днях смотрел, что мне там эти линтеры нагенерили. Вот представьте себе, у вас в коде две строковые константы, сообщения об ошибках. И они одинаковые. СОНАР нам пишет - создайте переменную, устраните дублирование. И у этого всего уровень Critical. Што, блин? У нас на уровень бага критикал можно выпустить релиз, по упрощенной процедуре. Потому что критикал - это когда что-то не работает, и надо быстро починять. Но когда вот эта фигня получает такой уровень - ну так и отношение к результатам работы линтера соответствующее.
1.Перед отправкой кода на ревью обязательно проведите все автоматические проверки (тесты, линтеры и т.д.)
Цель ревью никакого отношения к автоматическим проверкам не имеет. Она в том, чтобы показать код человеку, который оценивает его с человеческой точки зрения.
И делать это можно на любом этапе, когда вам двоим удобно. Например когда код вообще еще сырой, и даже не компилируется - чтобы оценить общую структуру, идеи, алгоритмы и т.п. - то что можно примерно считать архитектурой, но не в картинках, а уже в виде кода.
При этом размер pull request может быть вообще любым, хотя завершенным и небольшим конечно лучше, как правило. Но когда изменения бывают реально большими, разбивать их на мелкие части - не самое удачное решение.
Что же до автоматических проверок, то в правильно налаженном процессе при создании pull request они уже как правило будут автоматически запущены, поэтому данный совет никакого смысла не имеет. Наладьте процесс, и забудьте про эту ерунду.
В двух словах - все что тут написано, скорее всего верно для разработчиков начинающих. А если вы синьор, вы спокойно можете все эти правила нарушать, потому что вы знаете, что делаете. И зачем делаете. А если оба участника синьоры, то и подавно.
Вплоть до того, что вообще ревью не проводить. Да, так можно было :)
Проблема в том, что и ваша статья не тоже самое, о чем написано в заголовке. Как уже ниже отметили, из перечисленных команд только маленькая часть (поверим на слово что 3 штуки) являются встроенными средствами bash. Все остальные - обычные команды, и к баш никакого отношения не имеют. Ну или скажем vim - с какого боку это баш? Ни с какого.
Ну и да, если вы ничего на эту тему не нашли - значит вы не искали. Хочу вам напомнить, что многие из этих команд существуют с рождения Unix, т.е. c 1960-х годов. Ну то есть, лет 60 так примерно. И даже если только СССР учитывать, что это максимум конец 80-х. Да и башу уже 34 года, если верить Википедии. По ним столько статей и книг написано - не перечитать. С любыми целями и для любой аудитории.
Не совсем так. На новом месте вам придется многое начинать с начала. Ваши хард скиллы никуда не денутся, а вот знакомство с бизнесом текущей компании, с тем как все в ней устроено - все это будет по-другому.
И если в этой ситуации новый работодатель готов вам платить больше - это скорее всего значит, что только ваши хард скиллы, или их часть, неспецифичная для компании, уже стоит больше, чем ваша текущая зарплата целиком.
Да ладно. Я понимаю что многолетний опыт MS SQL не конвертируется напрямую в опыт постгреса, но сам по себе опыт никуда не денется. И свою роль будет играть. Другое дело, что может быть стоит сейчас уже озаботиться изучением чего-то нового.
Да ну, не, лично я настолько нынче далек от MS SQL. У нас в процессе его замещение на постгрес, так что 2024 по плану будет последним годом эксплуатации всех экземпляров.
Я в целом и не спорю. Просто это может быть стоило чуть яснее сформулировать. Ну т.е. вы декларировали что хотите ускорить запуск вот этого проекта и снизить потребление - вы именно это померяли, это можно считать что доказано. А в целом - ну там как получится, другие проекты могут повести себя иначе.
Я возможно про память недостаточно четко изложил свою мысль. Давайте чуть поясню - я про то, что если мы в heap память приложения скажем хотим загрузить гигабайт данных каких-то, и использовать ее как кеш, то этот гигабайт не изменится, если собрать все граалем, правда же? Ну т.е. когда вы пишете про уменьшение потребления памяти - было бы очень неплохо уточнить, о какой памяти идет речь.
В некоторых сценариях.
Тут пол статьи как раз о том, как они масштабировали etcd. Может это конечно и легко, но таки автор оригинала решил про это статью написать. Видимо для него это было не слишком просто сделать.
Ну, строго говоря, рефакторинг это то что без изменения функциональности ) И он может быть проведен автоматически, правда далеко не в любом языке.
Конечно. Поэтому я и писал выше, что иногда достаточно подумать о том, как тестировать, чтобы в коде не было такого, что штрихкод не тестируется без базы.
Весь вопрос в сложности и типе проекта. Многопоточность, интеграция (с чем угодно) - это все сразу усложняет тестирование в разы. Причем один из таких случаев - это (тривиальная на вид) интеграция с любой СУБД. Все что мы тут можем - это сделать из этой интеграции, условно, что-то типа CRUD API, и тестировать с его моком. Что многие реальные классы ошибок ну ни разу не предотвращает.
Ничего не имею против тестов в целом, но есть куча случаев, когда они вообще ничего не дают. И да, я сам как раз из этой самой, инженерной школы.
В моей практике (а это сильно интеграционные проекты) - почти нет такой выгоды. То что мы иногда ловим в проме, всплывает лишь на одной интеграции скажем из 20 похожих. Не всегда на это просто написать тест даже постфактум. А уж предугадать заранее кейс, который потребует теста - вообще можно в редчайших случаях.
Это не значит что везде так, далеко не все проекты вообще такие.
Честно говоря, все эти решения имеют те или иные проблемы. Ну или ограничения, если хотите. Например, решения типа JOOQ предполагают, что у вас при компиляции структура базы такая же, как в проме. С одной стороны, вроде бы это плюс (вы примерно об этом пишете в п.1), а с другой - это далеко не всегда просто обеспечить. Просто потому, что база с которой вы работаете, может быть не ваша, и изменения в ее схему вносятся другой командой. Ну или вы просто заранее ничего не знаете про базу вообще, кроме того что она существует, и всю ее структуру можете добыть только при запуске, но не ранее.
Может вы и математику не любите?
Переформулирую другим способом: еще один, два или десять тестов не приближают вас ни на на миллиметр к гарантии того, что в коде нет ошибок. Тесты теоретически этого обеспечить не могут, только показать наличие. Доказательства правильности у вас не будет. В общем случае (насколько я понимаю, доказательство правильности сродни проблеме останова машины Тьюринга, которая не имеет решения).
В частных же конкретных случаях - ну да, вы можете написать тесты на некоторые сложные части кода, и спать спокойно, ибо ощущение усталости от проделанной работы написанные тесты конечно же дают :) И оно реально будет работать лучше - особенно с учетом того, что для написания тестов код надо немного понимать, а это положительно сказывается на его качестве само по себе. Даже если только задумать их писать и потратить время на это обдумывание.
И причем заметьте - вы приводите пример, когда одна ошибка не воспроизводится, и де факто на нее и тест написать невозможно (в моем понимании, многопоточная логика приложений вообще на сегодня тестами как следует не покрывается). А второй случай явного падения, при всех его неприятных последствиях, диагностируется за пять минут, и исправляется навсегда. Потому что ошибка обычно простая. И строго говоря, такие ошибки предотвращаются не тестами, а рефакторингом.
Все это разумно кроме одного - тесты не ловят ошибки. Ну или точнее, ловят конечно, какие-то, но они не могут гарантировать отсутствие ошибок.
Ревью тоже может ловить ошибки - но другого сорта. Например, использование алгоритмов не с тем О-малым. Но тоже не гарантирует их отсутствия.
А представьте, что вы делаете такое исправление (на самом деле это не секунды вовсе, потому что зачастую проект еще собрать надо). И ваши пользователи, когда они видят ваш очередной релиз, читают release notes, и видят там что? Видят они задачу, где написано: "Заменил две константы на переменную, теперь SONAR счастлив". Лично для меня это будет хороший повод данный релиз не внедрять, а подождать следующего, когда автор сделает что-то более существенное.
Ну т.е. это не совсем общий нынешний уровень, если угодно, это скорее влияние качества кода на том микроуровне, где работают сонары и линтеры, на общее качество проекта. И это влияние ну оооочень опосредованное. Наверное не всегда, ведь проекты разные - но часто.
Ну да. Написали немного эмоционально, но по большому счету... Я тоже на днях смотрел, что мне там эти линтеры нагенерили. Вот представьте себе, у вас в коде две строковые константы, сообщения об ошибках. И они одинаковые. СОНАР нам пишет - создайте переменную, устраните дублирование. И у этого всего уровень Critical. Што, блин? У нас на уровень бага критикал можно выпустить релиз, по упрощенной процедуре. Потому что критикал - это когда что-то не работает, и надо быстро починять. Но когда вот эта фигня получает такой уровень - ну так и отношение к результатам работы линтера соответствующее.
Цель ревью никакого отношения к автоматическим проверкам не имеет. Она в том, чтобы показать код человеку, который оценивает его с человеческой точки зрения.
И делать это можно на любом этапе, когда вам двоим удобно. Например когда код вообще еще сырой, и даже не компилируется - чтобы оценить общую структуру, идеи, алгоритмы и т.п. - то что можно примерно считать архитектурой, но не в картинках, а уже в виде кода.
При этом размер pull request может быть вообще любым, хотя завершенным и небольшим конечно лучше, как правило. Но когда изменения бывают реально большими, разбивать их на мелкие части - не самое удачное решение.
Что же до автоматических проверок, то в правильно налаженном процессе при создании pull request они уже как правило будут автоматически запущены, поэтому данный совет никакого смысла не имеет. Наладьте процесс, и забудьте про эту ерунду.
В двух словах - все что тут написано, скорее всего верно для разработчиков начинающих. А если вы синьор, вы спокойно можете все эти правила нарушать, потому что вы знаете, что делаете. И зачем делаете. А если оба участника синьоры, то и подавно.
Вплоть до того, что вообще ревью не проводить. Да, так можно было :)
Проблема в том, что и ваша статья не тоже самое, о чем написано в заголовке. Как уже ниже отметили, из перечисленных команд только маленькая часть (поверим на слово что 3 штуки) являются встроенными средствами bash. Все остальные - обычные команды, и к баш никакого отношения не имеют. Ну или скажем vim - с какого боку это баш? Ни с какого.
Ну и да, если вы ничего на эту тему не нашли - значит вы не искали. Хочу вам напомнить, что многие из этих команд существуют с рождения Unix, т.е. c 1960-х годов. Ну то есть, лет 60 так примерно. И даже если только СССР учитывать, что это максимум конец 80-х. Да и башу уже 34 года, если верить Википедии. По ним столько статей и книг написано - не перечитать. С любыми целями и для любой аудитории.
Не совсем так. На новом месте вам придется многое начинать с начала. Ваши хард скиллы никуда не денутся, а вот знакомство с бизнесом текущей компании, с тем как все в ней устроено - все это будет по-другому.
И если в этой ситуации новый работодатель готов вам платить больше - это скорее всего значит, что только ваши хард скиллы, или их часть, неспецифичная для компании, уже стоит больше, чем ваша текущая зарплата целиком.
Да ладно. Я понимаю что многолетний опыт MS SQL не конвертируется напрямую в опыт постгреса, но сам по себе опыт никуда не денется. И свою роль будет играть. Другое дело, что может быть стоит сейчас уже озаботиться изучением чего-то нового.
Да ну, не, лично я настолько нынче далек от MS SQL. У нас в процессе его замещение на постгрес, так что 2024 по плану будет последним годом эксплуатации всех экземпляров.
Я в целом и не спорю. Просто это может быть стоило чуть яснее сформулировать. Ну т.е. вы декларировали что хотите ускорить запуск вот этого проекта и снизить потребление - вы именно это померяли, это можно считать что доказано. А в целом - ну там как получится, другие проекты могут повести себя иначе.
А мы все равно заведем и подпишемся :)
Я возможно про память недостаточно четко изложил свою мысль. Давайте чуть поясню - я про то, что если мы в heap память приложения скажем хотим загрузить гигабайт данных каких-то, и использовать ее как кеш, то этот гигабайт не изменится, если собрать все граалем, правда же? Ну т.е. когда вы пишете про уменьшение потребления памяти - было бы очень неплохо уточнить, о какой памяти идет речь.
Ну в общем да, не совсем тоже самое.