Проблема любых договорённостей о коде в том, что их можно нарушать. Куда проще, когда есть инструмент, который заставляет правилам следовать. Мне понравилась концепция gofmt в golang, хоть я никак за этот язык не возьмусь и только мельком знаю отдельные факты. Тулза языка, которая за тебя форматирует код - это же гениально. Это не опциональный pylint. Круто же
Здорово, что лично вы хорошо пишите код. Я, надеюсь, тоже неплохо. Но как только речь начинает идти про большой и разнообразный коллектив, в котором в том числе джуны, то закон Мерфи начинает работать на полную катушку)
Приглашаю вас почитать и обсудить разное в моём ТГ-канале — Markwhen — инструмент для построения роадмапов — Подкаст про Роли в ИТ-проекте — Подборка материалов про архитектуру (зачем нужны архитектурные схемы, как их документировать, какие инструменты использовать)
Конкретно данный подход никак. Этот подход покрывает планомерное взаимодействие.
Если мы говорим о чем-то критическом, то в зависимости от ситуации встреча может быть устроена здесь и сейчас или в течение дня поставлена в календарь.
Но практика показывает, что такие вопросы с очень большой срочностью – редки. Люди зачастую сами эту срочность создают. Но если задаться вопросом, а так ли это срочно? Скорее всего окажется, что вопрос не такой срочный. Особенно, если этот вопрос задать на спокойную голову.
Предлагаю смотреть на эту метрику шире. Интерес может представлять вклад по языкам - в сабже вон смесь си, двух версих шелла, вкрапления perl-а. На мой взгляд, это хорошие звоночки будущих проблем в проекте. Как считаете?
Ещё можно смотреть на среднее отношение комментариев к коду - как детектор проектов вообще без комментариев, например
Представь: ты работаешь в команде, где каждый пишет коммиты как бог на душу положит. Один пишет "пофиксил баг", другой — "ну тут всё сломалось, я подправил", третий вообще оставляет "123". Потом через месяц ты пытаешься понять, что за изменения привели к новому багу. Идешь в историю коммитов, а там — ад. Ты тратишь кучу времени, чтобы просто понять, что вообще происходило.
Gitlint тут как строгий, но справедливый учитель. Он не даст закоммитить "123" или "чё-то сделал". Придётся писать нормально: "fix: исправлено падение при загрузке данных" или "feat: добавлена поддержка тёмной темы". В итоге история коммитов становится не свалкой, а читаемой историей изменений.
Но самое интересное — это когда ты начинаешь искать баг. Вместо того чтобы рыться в куче мусора, ты видишь сразу: "ага, вот тут был фикс бага с загрузкой данных, а вот тут добавили новую фичу". Это экономит время, нервы и делает жизнь чуть проще. Да, сначала все ворчат, что "ну зачем эти правила", но потом, когда история коммитов становится понятной даже через полгода, все начинают ценить этот порядок.
Так что gitlint — это не про "сделать из буханки что-то красивое", а про то, чтобы потом не пришлось разгребать бардак.
Насколько я знаю, и юнит тесты, и интеграционные тесты относят к функциональным. Или как вы определяете функциональные тесты?
В юнит тестах не обязательно всё мокать, на мой взгляд. Не вижу проблемы писать тесты, покрывающие вызов ряда функций. При этом, с моей точки зрения, это ещё не интеграционные тесты, которые должны покрывать более широкий тракт от входа до выхода.
Вообще говоря, увлечение моками мне кажется не лучшей практикой. Понятно, что внешние зависимости (сеть, бд, АПИ) стоит мокать. Но много чего лучше не мокать, а действительно вызывать. Не вижу противоречий с определением, модуль не обязан быть мельчайшим фрагментом кода.
100% покрытие тяжело достигается. А вот 80% покрытия совершенно несложно обеспечить.
Уточню – речь про длительную отладку. Когда в проекте 10к+ строк кода, то без юнит тестов иногда довольно болезненно локализовать проблему. Что именно сломалось? В этот момент отладка становится таким расследованием, занимающим время. А с тестами падает что-то конкретное. Мне это экономит время
В почти любом активно развивающемся инструменте в той или иной мере есть проблема фрагментации. Удивительно, как сложно было условному андроиду, какая боль была от питона 2->3, и прочее, и прочее. Вон выше график проблем для С++, хотя казалось бы. Вроде обратная совместимость есть, то есть можно просто со свежей версией стандарта собираться. Но, как всегда, возникают нюансы, и чем больше кодовая база, тем больше этих нюансов
Не существует в мире денег, за которые я бы согласился писать код на питоне, го, или джаве
И мне стало интересно, какие стороны вас прельщают в ваших инструментах. Не уверен, что раст позволяет писать более высоконагруженные приложения относительно, например, го. Про высококонкурентность аналогично. С доказательством корректности не сталкивался, буду иметь в виду, спасибо
Проблема любых договорённостей о коде в том, что их можно нарушать. Куда проще, когда есть инструмент, который заставляет правилам следовать. Мне понравилась концепция gofmt в golang, хоть я никак за этот язык не возьмусь и только мельком знаю отдельные факты. Тулза языка, которая за тебя форматирует код - это же гениально. Это не опциональный pylint. Круто же
Здорово, что лично вы хорошо пишите код. Я, надеюсь, тоже неплохо. Но как только речь начинает идти про большой и разнообразный коллектив, в котором в том числе джуны, то закон Мерфи начинает работать на полную катушку)
Проблема не в goto, а в неаккуратном его применении. Куда проще начинающему сказать "goto плох" и всё. Так меня больше 10 лет назад на Си учили
Сильно потом я понял причины. И вот излил их вам в виде небольшой заметки
Приглашаю вас почитать и обсудить разное в моём ТГ-канале
— Markwhen — инструмент для построения роадмапов
— Подкаст про Роли в ИТ-проекте
— Подборка материалов про архитектуру (зачем нужны архитектурные схемы, как их документировать, какие инструменты использовать)
Конкретно данный подход никак. Этот подход покрывает планомерное взаимодействие.
Если мы говорим о чем-то критическом, то в зависимости от ситуации встреча может быть устроена здесь и сейчас или в течение дня поставлена в календарь.
Но практика показывает, что такие вопросы с очень большой срочностью – редки. Люди зачастую сами эту срочность создают. Но если задаться вопросом, а так ли это срочно? Скорее всего окажется, что вопрос не такой срочный. Особенно, если этот вопрос задать на спокойную голову.
Чтобы "сверить часы" - поставить новые задачи, пересмотреть приоритеты текущих задач, подсветить текущие проблемы
Приятно выглядит. Плюс моего cloc - можно в CI/CD запихать при надобности
А зачем вы смотрите на строки кода? Потому что красиво или есть причины смотреть на эти метрики?
Предлагаю смотреть на эту метрику шире. Интерес может представлять вклад по языкам - в сабже вон смесь си, двух версих шелла, вкрапления perl-а. На мой взгляд, это хорошие звоночки будущих проблем в проекте. Как считаете?
Ещё можно смотреть на среднее отношение комментариев к коду - как детектор проектов вообще без комментариев, например
Это позволит оценить только число строк, без учёта комментариев. Можно грепнуть однострочные комментарии, конечно, а вот с многострочными уже никак
Не получится раскладку по языкам получить. Для проекта на одном языке, конечно, не актуально
Для проекта со вложенностью такой способ напрямую не работает, надо докручивать
Собственно, зачем докручивать, если есть рабочее решение?) Правда, зачем нужно знать число строк в проекте особого ответа у меня нет. Просто красивое
Представь: ты работаешь в команде, где каждый пишет коммиты как бог на душу положит. Один пишет "пофиксил баг", другой — "ну тут всё сломалось, я подправил", третий вообще оставляет "123". Потом через месяц ты пытаешься понять, что за изменения привели к новому багу. Идешь в историю коммитов, а там — ад. Ты тратишь кучу времени, чтобы просто понять, что вообще происходило.
Gitlint тут как строгий, но справедливый учитель. Он не даст закоммитить "123" или "чё-то сделал". Придётся писать нормально: "fix: исправлено падение при загрузке данных" или "feat: добавлена поддержка тёмной темы". В итоге история коммитов становится не свалкой, а читаемой историей изменений.
Но самое интересное — это когда ты начинаешь искать баг. Вместо того чтобы рыться в куче мусора, ты видишь сразу: "ага, вот тут был фикс бага с загрузкой данных, а вот тут добавили новую фичу". Это экономит время, нервы и делает жизнь чуть проще. Да, сначала все ворчат, что "ну зачем эти правила", но потом, когда история коммитов становится понятной даже через полгода, все начинают ценить этот порядок.
Так что gitlint — это не про "сделать из буханки что-то красивое", а про то, чтобы потом не пришлось разгребать бардак.
Спасибо, потыкаю, если время будет. Вот для linux я пока не нашёл решения удобного
Прикольное. Кому интересно, вот ссылки
https://github.com/koekeishiya/yabai
https://github.com/koekeishiya/skhd
Полностью согласен. В области тг-ботов, кажется, питон вообще доминирует
Прямо в точку
Ещё проекты без докера, что нередко встречается в data science, хрен запустишь
Насколько я знаю, и юнит тесты, и интеграционные тесты относят к функциональным. Или как вы определяете функциональные тесты?
В юнит тестах не обязательно всё мокать, на мой взгляд. Не вижу проблемы писать тесты, покрывающие вызов ряда функций. При этом, с моей точки зрения, это ещё не интеграционные тесты, которые должны покрывать более широкий тракт от входа до выхода.
Вообще говоря, увлечение моками мне кажется не лучшей практикой. Понятно, что внешние зависимости (сеть, бд, АПИ) стоит мокать. Но много чего лучше не мокать, а действительно вызывать. Не вижу противоречий с определением, модуль не обязан быть мельчайшим фрагментом кода.
100% покрытие тяжело достигается. А вот 80% покрытия совершенно несложно обеспечить.
Спасибо за ссылку, почитаю на досуге
Уточню – речь про длительную отладку. Когда в проекте 10к+ строк кода, то без юнит тестов иногда довольно болезненно локализовать проблему. Что именно сломалось? В этот момент отладка становится таким расследованием, занимающим время. А с тестами падает что-то конкретное. Мне это экономит время
А вы пишите тесты?
"Только ситхи всё возводят в абсолют"
В почти любом активно развивающемся инструменте в той или иной мере есть проблема фрагментации. Удивительно, как сложно было условному андроиду, какая боль была от питона 2->3, и прочее, и прочее. Вон выше график проблем для С++, хотя казалось бы. Вроде обратная совместимость есть, то есть можно просто со свежей версией стандарта собираться. Но, как всегда, возникают нюансы, и чем больше кодовая база, тем больше этих нюансов
Люблю теории заговора. Какой именно из аспектов отчёта имеет смысл для коммерческой манипуляции?
Фрагментация по версиям - боль в любой технологии. Здорово, что сейчас с этим пытаются бороться
Вы довольно резко заявили
сколько процентов обезьян пишут лапшу на го
Не существует в мире денег, за которые я бы согласился писать код на питоне, го, или джаве
И мне стало интересно, какие стороны вас прельщают в ваших инструментах. Не уверен, что раст позволяет писать более высоконагруженные приложения относительно, например, го. Про высококонкурентность аналогично. С доказательством корректности не сталкивался, буду иметь в виду, спасибо
Имел в виду, что в любом языке можно получить стабильный результат, и с современными инструментами это относительно несложно