Предлагаю смотреть на эту метрику шире. Интерес может представлять вклад по языкам - в сабже вон смесь си, двух версих шелла, вкрапления perl-а. На мой взгляд, это хорошие звоночки будущих проблем в проекте. Как считаете?
Ещё можно смотреть на среднее отношение комментариев к коду - как детектор проектов вообще без комментариев, например
Представь: ты работаешь в команде, где каждый пишет коммиты как бог на душу положит. Один пишет "пофиксил баг", другой — "ну тут всё сломалось, я подправил", третий вообще оставляет "123". Потом через месяц ты пытаешься понять, что за изменения привели к новому багу. Идешь в историю коммитов, а там — ад. Ты тратишь кучу времени, чтобы просто понять, что вообще происходило.
Gitlint тут как строгий, но справедливый учитель. Он не даст закоммитить "123" или "чё-то сделал". Придётся писать нормально: "fix: исправлено падение при загрузке данных" или "feat: добавлена поддержка тёмной темы". В итоге история коммитов становится не свалкой, а читаемой историей изменений.
Но самое интересное — это когда ты начинаешь искать баг. Вместо того чтобы рыться в куче мусора, ты видишь сразу: "ага, вот тут был фикс бага с загрузкой данных, а вот тут добавили новую фичу". Это экономит время, нервы и делает жизнь чуть проще. Да, сначала все ворчат, что "ну зачем эти правила", но потом, когда история коммитов становится понятной даже через полгода, все начинают ценить этот порядок.
Так что gitlint — это не про "сделать из буханки что-то красивое", а про то, чтобы потом не пришлось разгребать бардак.
Насколько я знаю, и юнит тесты, и интеграционные тесты относят к функциональным. Или как вы определяете функциональные тесты?
В юнит тестах не обязательно всё мокать, на мой взгляд. Не вижу проблемы писать тесты, покрывающие вызов ряда функций. При этом, с моей точки зрения, это ещё не интеграционные тесты, которые должны покрывать более широкий тракт от входа до выхода.
Вообще говоря, увлечение моками мне кажется не лучшей практикой. Понятно, что внешние зависимости (сеть, бд, АПИ) стоит мокать. Но много чего лучше не мокать, а действительно вызывать. Не вижу противоречий с определением, модуль не обязан быть мельчайшим фрагментом кода.
100% покрытие тяжело достигается. А вот 80% покрытия совершенно несложно обеспечить.
Уточню – речь про длительную отладку. Когда в проекте 10к+ строк кода, то без юнит тестов иногда довольно болезненно локализовать проблему. Что именно сломалось? В этот момент отладка становится таким расследованием, занимающим время. А с тестами падает что-то конкретное. Мне это экономит время
В почти любом активно развивающемся инструменте в той или иной мере есть проблема фрагментации. Удивительно, как сложно было условному андроиду, какая боль была от питона 2->3, и прочее, и прочее. Вон выше график проблем для С++, хотя казалось бы. Вроде обратная совместимость есть, то есть можно просто со свежей версией стандарта собираться. Но, как всегда, возникают нюансы, и чем больше кодовая база, тем больше этих нюансов
Не существует в мире денег, за которые я бы согласился писать код на питоне, го, или джаве
И мне стало интересно, какие стороны вас прельщают в ваших инструментах. Не уверен, что раст позволяет писать более высоконагруженные приложения относительно, например, го. Про высококонкурентность аналогично. С доказательством корректности не сталкивался, буду иметь в виду, спасибо
Shell включает множество нюансов, но велика ли разница между условным bash и fish? Да, есть нюансы. Но их вряд ли можно назвать существенными. Питон3.6 от питона 3.11 тоже сильно отличается, но это один язык
Спасибо за языки. А теперь основной вопрос - почему они? Что в них такого прекрасного, что они лучшее в мире место, а условный питон невероятно плох, по вашему мнению?
Зависит от того, что мы измеряем. Jetbrains опрашивало разработчиков. TIOBE вычисляют некий слепок из проектов на гитхабе, ответов в поисковиках и ещё куче метрик. Можно смотреть на вакансии или резюме
Глобально, порядок языков в рейтинге имеет очень малое значение. Любой из топ-10 является хорошим кандидатом для рабочего инструмента. Ещё лучше иметь в своём репертуаре парочку языков (лучшей я считаю связку быстрого в разработке типа python и быстрого в плане производительного типа go/java/c++). Ну и как гимнастику для ума можно изотерические языки потыкать - lisp, prolog, haskell, ...
Typescript я бы тоже не выделял, наверное. Хотя знающие люди почему-то выделяют. Но не моя область
Чат-бот галлюцинирует, это общеизвестно. И на отдельные простые, казалось бы, задачи ИИ может выдавать неверный ответ. ИИ не умеет считать без плагина, плохо работает с буквами (так как внутри токены другого плана, посчитать количество вхождений буквы в слово ИИ может с трудом) и имеет ещё кучу недостатков. Под капотом нейросеть просто очень хорошо умеет прогнозировать следующее слово
Невероятно, что оно при этом способно решать задачи и вообще вести себя довольно разумно
В отчёте вроде ничего не было про плагины. Но экосистема плагинов довольно интересная, это точно. Плюс там неплохо с монетизацией вроде как, то есть при определённой доле удачи можно получить неплохую прибавку к зарплате. Некоторое время назад они забанили возможность качать плагины из РФ, сейчас с этим как?
Приятно выглядит. Плюс моего 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, и прочее, и прочее. Вон выше график проблем для С++, хотя казалось бы. Вроде обратная совместимость есть, то есть можно просто со свежей версией стандарта собираться. Но, как всегда, возникают нюансы, и чем больше кодовая база, тем больше этих нюансов
Люблю теории заговора. Какой именно из аспектов отчёта имеет смысл для коммерческой манипуляции?
Фрагментация по версиям - боль в любой технологии. Здорово, что сейчас с этим пытаются бороться
Вы довольно резко заявили
сколько процентов обезьян пишут лапшу на го
Не существует в мире денег, за которые я бы согласился писать код на питоне, го, или джаве
И мне стало интересно, какие стороны вас прельщают в ваших инструментах. Не уверен, что раст позволяет писать более высоконагруженные приложения относительно, например, го. Про высококонкурентность аналогично. С доказательством корректности не сталкивался, буду иметь в виду, спасибо
Имел в виду, что в любом языке можно получить стабильный результат, и с современными инструментами это относительно несложно
Shell включает множество нюансов, но велика ли разница между условным bash и fish? Да, есть нюансы. Но их вряд ли можно назвать существенными. Питон3.6 от питона 3.11 тоже сильно отличается, но это один язык
Спасибо за языки. А теперь основной вопрос - почему они? Что в них такого прекрасного, что они лучшее в мире место, а условный питон невероятно плох, по вашему мнению?
А глобально зачем? То есть какой вывод можно сделать из такого графика?
Зависит от того, что мы измеряем. Jetbrains опрашивало разработчиков. TIOBE вычисляют некий слепок из проектов на гитхабе, ответов в поисковиках и ещё куче метрик. Можно смотреть на вакансии или резюме
Глобально, порядок языков в рейтинге имеет очень малое значение. Любой из топ-10 является хорошим кандидатом для рабочего инструмента. Ещё лучше иметь в своём репертуаре парочку языков (лучшей я считаю связку быстрого в разработке типа python и быстрого в плане производительного типа go/java/c++). Ну и как гимнастику для ума можно изотерические языки потыкать - lisp, prolog, haskell, ...
Typescript я бы тоже не выделял, наверное. Хотя знающие люди почему-то выделяют. Но не моя область
Чат-бот галлюцинирует, это общеизвестно. И на отдельные простые, казалось бы, задачи ИИ может выдавать неверный ответ. ИИ не умеет считать без плагина, плохо работает с буквами (так как внутри токены другого плана, посчитать количество вхождений буквы в слово ИИ может с трудом) и имеет ещё кучу недостатков. Под капотом нейросеть просто очень хорошо умеет прогнозировать следующее слово
Невероятно, что оно при этом способно решать задачи и вообще вести себя довольно разумно
В отчёте вроде ничего не было про плагины. Но экосистема плагинов довольно интересная, это точно. Плюс там неплохо с монетизацией вроде как, то есть при определённой доле удачи можно получить неплохую прибавку к зарплате. Некоторое время назад они забанили возможность качать плагины из РФ, сейчас с этим как?