Это философия, на мой взгляд. Кто-то любит чистоту и порядок, а кому-то плевать. Но тех кому плевать — обычно мало. Опять же, те, кто любит чистоту, делятся на тех, кто будет ее наводить, и на тех, которые терпеть не могут убирать. Первые берут веник, вторые — покупают робот-пылесос. Если вам плевать, с чем работать — то можете хоть минифицированный код писать;) В конечном итоге любой код должен быть человекочитабельным и однородным. По моему, оправдывать неряшливость отрешенностью — ну не ок. Но если вы познали дзен — ждем статьи о том, как не беспокоится об оформлении кода и как этого достичь)
Если я верно понял — Standard — 3й в списке пресетов. Набрать 2 команды и выбрать Standard в списке из 3х пунктов — не сложно. ESLint более универсален, он модульный, настраиваемый и мощный. Если вам нужна поддержка разного кодстайла в разных проектах — он нужен. Если у вас 1 стиль для всего — можно конечно же ограничится 1 библиотекой
Оформив весь код по единым правилам вы не повысите его качество.
Я писал, что единое оформление освобождает ресурсы разработчика и дает возможность замечать плохой код. И при ревью, и при разработке. Если такой код попадает в продакшн — очень жаль того, кто это пропустил/написал. Все же код нужно читать, а не просматривать.
Мозг так не работает. Он быстро обучается замечать важное и игнорировать несущественное.
К сожалению, действительность далека от желаний. На моем опыте ряд проектов, которые требовали погружения и понимания, и отсутствие оформления кода затягивало процесс разработки. Возможно, мы рассуждаем о проектах разной сложности. Если проект не сложный — согласен, игнорировать можно
Смотрите какая идея во всем этом — не подстраиваться под «хочу — пишу, хочу — нет» конкретного человека, а форматировать исходный код всегда до коммита, чтобы разработчик всегда видел отклонения, всегда видел принятый кодстайл. Настойка оформления кода и сам кодстайл вынесен за рамки ответственности программиста и присутствует независимо от его предпочтений.В конечном итоге программист будет следовать ему со временем. Плюс ко всему — например я провожу ревью через гитлаб. Если код который я вижу в гитлабе, отформатирован так же как в редакторе или IDE, с которым я работаю — мне нужно лишний раз настраиваться на чтение(об этом я писал в статье).
Да, это один из вариантов воркэраунда кодстайла для вебшторма, я упомянул тот, с которым приходилось сталкиваться чаще — а именно импорт из .jscsrc. и да, папку .idea после настройки нужно закомитить, чтобы не заниматься настройкой на других машинах.
Самое массивное с чем я сталкивался — это изменение окончания строк во всем файле. это выглядит стремно и я обычно такое возвращаю обратно и помогаю перенастроить гит(как правило это он), на сохранение текущих концов строк.
Если форматирование настроено изначально, то массивных изменений быть не должно. Если же делается глобальное форматирование — то как правило есть требование такие вещи делать в отдельных коммитах или отдельными мр, чтобы не блокировать и не усложнять кодревью.
используемая версия MS SQL 2008 или 2012. Что касается других инструментов генерации тестовых данных — основная проблема в том, что в то время мы не полностью понимали статистику распределения, это было в начале проекта. Поэтому нас интересовала исследовательская часть по нахождению этих правил. Из-за этого правила распределения были бы не верными при генерации тестовых данных.
400 работ — термин бизнес-логики. Работа — совокупность данных об одном пациенте (визите)
да, мы еще некоторые вещи делали. Но и графики в том числе, которые акцентировали внимание, что все хорошо. Тут получался дополнительный эффект от того, что мы выбирали характеристики измерения правильно (в абсолютном большинстве случаев) и это уходило в нашу «копилку» характеристик, которые мониторим. И так же величины становились измеримыми.
Вероятно, вы правы, некого вывода в виде рецепта я не привел. Причем, когда статья задумывалась и формировалась, такая идея была.
Хотел показать некие практики наподобие «У вас есть сервис генерирующий thumbnail'ы (активное использование диска) — берите такой-то сервер. У вас строго вычислительный сервис — вам подойдет другой сервер».
Позже решил отказаться от такой идеи. Уж слишком однобокие получаются выводы. На практике такого и не встречал. Как правило, мы имеем дело с web-проектом, который активно нагружает все компоненты сервера, а значит все его компоненты должны быть быстрые. И приходим мы к выводу, что если нужен быстрый web-проект, то и сервер должен быть быстрый целиком, как бы банально это не звучало.
Поэтому в статье даётся перечень инструментов, которые позволяет измерить производительность отдельных компонентов сервера. Что делать с результатами — каждый решает сам.
Я писал, что единое оформление освобождает ресурсы разработчика и дает возможность замечать плохой код. И при ревью, и при разработке. Если такой код попадает в продакшн — очень жаль того, кто это пропустил/написал. Все же код нужно читать, а не просматривать.
К сожалению, действительность далека от желаний. На моем опыте ряд проектов, которые требовали погружения и понимания, и отсутствие оформления кода затягивало процесс разработки. Возможно, мы рассуждаем о проектах разной сложности. Если проект не сложный — согласен, игнорировать можно
Если форматирование настроено изначально, то массивных изменений быть не должно. Если же делается глобальное форматирование — то как правило есть требование такие вещи делать в отдельных коммитах или отдельными мр, чтобы не блокировать и не усложнять кодревью.
400 работ — термин бизнес-логики. Работа — совокупность данных об одном пациенте (визите)
Хотел показать некие практики наподобие «У вас есть сервис генерирующий thumbnail'ы (активное использование диска) — берите такой-то сервер. У вас строго вычислительный сервис — вам подойдет другой сервер».
Позже решил отказаться от такой идеи. Уж слишком однобокие получаются выводы. На практике такого и не встречал. Как правило, мы имеем дело с web-проектом, который активно нагружает все компоненты сервера, а значит все его компоненты должны быть быстрые. И приходим мы к выводу, что если нужен быстрый web-проект, то и сервер должен быть быстрый целиком, как бы банально это не звучало.
Поэтому в статье даётся перечень инструментов, которые позволяет измерить производительность отдельных компонентов сервера. Что делать с результатами — каждый решает сам.