У нас новый продукт: ReviewTool - среда рецензирования кода для Subversion (SVN).
Ключевые возможности
+ Работа с ветками Subversion.
+ "Нулевая" конфигурация, почти никаких настроек кроме структуры веток и адреса репозитория. Права доступа проверяются самим Subversion
+ Интеграция с любым трекером задач: ссылка на задачу на основе номера ветки (бранча).
+ Конфиденциальность! Никакого облака, только коробочная "on-premise" версия.
+ Языки - русский/английский
Просмотр изменений:
+ Визуализация пробелов
+ Визуализация переносов кода (когда рефакторинг был)
+ Режим IDE и режим общего просмотра.
+ Просмотр сообщений коммита к правкам, чтобы понимать "Что менялось".
Комментирование кода
+ Добавление комментариев к строчкам кода
+ Просмотр предыдущих комментариев с переходом по отметкам
+ Автоматическое формирование отчёта со ссылкой на результаты проверки.
+ Возможность отправки отчета в любой трекер задач через кастомный шлюз.
Система контроля версий Subversion обеспечивает централизованный доступ, неизменность истории и работу с большими файлами из коробки.
ReviewTool - инструмент организации процесса рецензирования кода для Subversion.
Детали и информация по стоимости в личку.
Возможны скидки за ранний доступ.
Примеры экранов ниже.
#reviewtool
Ключевые возможности
+ Работа с ветками Subversion.
+ "Нулевая" конфигурация, почти никаких настроек кроме структуры веток и адреса репозитория. Права доступа проверяются самим Subversion
+ Интеграция с любым трекером задач: ссылка на задачу на основе номера ветки (бранча).
+ Конфиденциальность! Никакого облака, только коробочная "on-premise" версия.
+ Языки - русский/английский
Просмотр изменений:
+ Визуализация пробелов
+ Визуализация переносов кода (когда рефакторинг был)
+ Режим IDE и режим общего просмотра.
+ Просмотр сообщений коммита к правкам, чтобы понимать "Что менялось".
Комментирование кода
+ Добавление комментариев к строчкам кода
+ Просмотр предыдущих комментариев с переходом по отметкам
+ Автоматическое формирование отчёта со ссылкой на результаты проверки.
+ Возможность отправки отчета в любой трекер задач через кастомный шлюз.
Система контроля версий Subversion обеспечивает централизованный доступ, неизменность истории и работу с большими файлами из коробки.
ReviewTool - инструмент организации процесса рецензирования кода для Subversion.
Детали и информация по стоимости в личку.
Возможны скидки за ранний доступ.
Примеры экранов ниже.
#reviewtool
👍1
Про нейронки и разработку программного обеспечения
Чем больше я использую ИИ-агентов (модели) тем больше убеждаюсь, что Метод с Правилами Документирования и Правилами непрерывного проектирования становится становится не просто рекомендацией, а жизненно необходимым.
И вот почему:
1. ИИ-агент работает, как я на проекте, который первый раз вижу. Он видит целевую часть для внесения изменений, но не понимает её. Чтобы понять он начинает шерстить весь проект, чтобы понять "Что значит эта функция" , "К чему относится это имя", "Из чего состоит та или иная сущность".
И проблема не в том, что жгутся токены, а том что это ДОЛГО. Иногда быстрее руками все сделать чем ждать пока ИИ-агент построить у себя контекст.
2. Второй аспект в том, что код не описывает "Почему, так сделано", модульные тесты фиксируют поведение "должно работать так" , а "почему?" - на этот вопрос в коде нет ответа. Как результат ИИ-модель начинает пробивать дыры в архитектуре. Так бывает когда главный архитектор покинул компанию, а вместо него остались профессионалы, но никто не знает Замысел.
И получается, что формально "Задача выполнена", а в реальности это уже костыли. И вроде код работает, и тесты есть, но... это костыли и со временем они будут только наслаиваться, пока эту махину нельзя будет поддерживать.
Поэтому важно:
1. Проектировать в Вики. Думать в вики. Писать туда что хотел автор, основной замысел.
2. Регулярно обновлять документацию. "Замысел - архитектура" с описанием почему так.
3. При завершении задачи писать отчёт "Как именно сделано" , Пусть это будет "дублирование из вики", но чтобы поставить новое задание ИИ-агенту нужно чтобы живой исполнитель, сам понял "как это примерно работает".
Нейронка может писать хороший код, правильный. стерильный. Но если в проекте есть "хаки" (потому что так работает быстрее или проще поддерживать) - то всё ломается.
Самое интересное, что мы сейчас возвращаемся в 1970 код и статье Винстона Ройса , основная мысль которой "Чтобы быстрее запускать программное обеспечение в эксплуатацию - пиши БОЛЬШЕ документов". Разница только в том, что ДОКУМЕНТЫ нужны больше не людям, а ИИ-агентам чтобы они БЫСТРЕЕ находили ответы, и БЫСТРЕЕ писали код, а не "шарились" по исходникам загружая контекст.
#метод #ии
Чем больше я использую ИИ-агентов (модели) тем больше убеждаюсь, что Метод с Правилами Документирования и Правилами непрерывного проектирования становится становится не просто рекомендацией, а жизненно необходимым.
И вот почему:
1. ИИ-агент работает, как я на проекте, который первый раз вижу. Он видит целевую часть для внесения изменений, но не понимает её. Чтобы понять он начинает шерстить весь проект, чтобы понять "Что значит эта функция" , "К чему относится это имя", "Из чего состоит та или иная сущность".
И проблема не в том, что жгутся токены, а том что это ДОЛГО. Иногда быстрее руками все сделать чем ждать пока ИИ-агент построить у себя контекст.
2. Второй аспект в том, что код не описывает "Почему, так сделано", модульные тесты фиксируют поведение "должно работать так" , а "почему?" - на этот вопрос в коде нет ответа. Как результат ИИ-модель начинает пробивать дыры в архитектуре. Так бывает когда главный архитектор покинул компанию, а вместо него остались профессионалы, но никто не знает Замысел.
И получается, что формально "Задача выполнена", а в реальности это уже костыли. И вроде код работает, и тесты есть, но... это костыли и со временем они будут только наслаиваться, пока эту махину нельзя будет поддерживать.
Поэтому важно:
1. Проектировать в Вики. Думать в вики. Писать туда что хотел автор, основной замысел.
2. Регулярно обновлять документацию. "Замысел - архитектура" с описанием почему так.
3. При завершении задачи писать отчёт "Как именно сделано" , Пусть это будет "дублирование из вики", но чтобы поставить новое задание ИИ-агенту нужно чтобы живой исполнитель, сам понял "как это примерно работает".
Нейронка может писать хороший код, правильный. стерильный. Но если в проекте есть "хаки" (потому что так работает быстрее или проще поддерживать) - то всё ломается.
Самое интересное, что мы сейчас возвращаемся в 1970 код и статье Винстона Ройса , основная мысль которой "Чтобы быстрее запускать программное обеспечение в эксплуатацию - пиши БОЛЬШЕ документов". Разница только в том, что ДОКУМЕНТЫ нужны больше не людям, а ИИ-агентам чтобы они БЫСТРЕЕ находили ответы, и БЫСТРЕЕ писали код, а не "шарились" по исходникам загружая контекст.
#метод #ии
💯3👍1