Спасибо за полезное и очень важное дополнение! Существует четкое разделение ролей, но, к сожалению, не все компании и заказчики о них в курсе. На многих проектах каноническое распределение обязанностей между специалистами сильно изменилось. Мы стараемся, чтобы как можно больше разработчиков и заказчиков были осведомлены о правильном распределении ролей, а не искали универсального специалиста в качестве «волшебной таблетки от всех проблем».
Наряду с использованием широкого спектра современных инструментов ИБ, мы подбираем и специфические релевантные варианты для каждого конкретного случая. В некоторых компаниях все еще работают с ПО, которое написано на более ранних версиях Java. И которые в силу различных обстоятельств не могут перейти на более старшие версии. Для них не менее важно уметь настраивать правила безопасности, учитывая и внутренние регламенты организаций. Мы учитываем все пожелания заказчиков и подбираем решение исходя из ситуации. В этом особенность заказной разработки.
Конечно, использование маинд карты для простой формы ввода может показаться излишним. Автор использовала эту форму в качестве визуального примера, на котором просто объяснить, как такой подход может помочь.
На практике интеллект-карты чаще используются для более сложных проектов, где необходимо глубокое понимание пользовательского опыта. Вот почему это помогает:
лучше понять, как пользователи будут взаимодействовать с продуктом;
выявить скрытые проблемы, которые могут быть не очевидны на первый взгляд;
сделать тестирование более эффективным, сфокусировав его на ключевых моментах пользовательского опыта.
В результате время, потраченное на создание маинд карты, окупается за счет лучшего понимания пользователей и выявления важных проблем на ранней стадии.
Привет, благодарим за обратную связь! Мы ценим комментарии наших читателей и нам важно видеть конструктивную критику.
Ответ автора: не сказал бы, что SDET не нужны там, где используют Low-Code. В процессе создания этой статьи я заметил, что на просторах сети есть интересные вакансии, например, эта: https://builtin.com/job/sdet-appian-experience-remote/2957618 Поэтому было принято решение включить маленький кусочек информации про Low-Code/No-Code платформы. Насчет «воды» могу только указать на тег статьи — это лишь мнение :)
Спасибо за комментарий!:) Постараемся ответить по порядку.
Да, такой вариант рассматривался. Но все же мы решили продолжать разрабатывать и поддерживать проект с использованием KMP, так как мы видим тенденцию развития данной технологии и уверены, что вскоре многие проблемы будут решены. В том числе путем перехода на новый UI Compose Multiplatform. Еще раз подчеркнем, что мы не утверждаем, что KMP — это плохая технология и ее нужно опасаться. Совсем наоборот. Мы говорим о том, к каким неочевидным трудностям управления проектом стоит быть готовым при использовании KMP, а также делаем вывод, что при росте масштаба проекта и сложности бизнес-логики растет и фатальность допущенных ошибок.
и 3. Согласны с вами по поводу современных языков программирования. На счет формирования команды автор полагает, что здесь решает, в том числе, владелец проекта и то финансирование, которое он готов вложить команду разработки. Универсальный разработчик - не редкость, но его экспертность дороже оплачивается. Такие специалисты конечно ценятся на проекте, но иногда нужно больше «неуниверсальных» рук и умов, чтобы уложиться в поставленные сроки)
Да, фиксировать контракты между доменной и нативными частями необходимо в любом случае. Но если приложение полностью нативное, то разработчики часто работают по конкретному флоу, реализуя все механизмы от самых низших слоев к высшим (если мы говорим Clean Architecture) и сам более гибко может менять контракт
Конечно нет, KMP не виновник проблем проекта) Все инструменты хороши, нужно уметь ими правильно пользоваться
Новичкам в разработке мы обычно советуем начать с этих книг, независимо от языка программирования: • «Чистый код» Р.Мартина • «Грокаем алгоритмы» А.Бхаргава — очень помогает с базовыми пониманием, что такое алгоритмы, какие бывают и т.д. • «2022. System Design. Подготовка к сложному интервью» — очень рекомендуем прочитать 1 и 2 главу всем, кто планирует работать с микросервисами и т.д. • «TDD Экстремальное программирование» К.Бека — нужно ознакомиться с водной частью (1 и 2 глава), дальше идет уже сильно специфическая тематика.
Для тех, кто только задумался о том, чтобы освоить Golang, можем порекомендовать «Head First. Изучаем Go» Джея Макгаврен, после которой лучше сразу читать «Go на практике» Мэтта Батчера и Мэтта Фарина.
Все остальные книги и последовательность опциональны от выбора и предпочтений молодого бойца на Go :)
Спасибо, работает! Пока работала над этой задачей, тестировала на собственных ссылках, и всегда открытая фигма как раз иконку не отдает :) У них иконки лежат по другому урлу —static.figma.com. Вашим способом фигмовскую иконку я добыла :) Правда, страшненькая, маленькая, но все-таки! Это хороший повод поискать еще несколько вариантов добычи иконок и написать вторую часть статьи :)
Спасибо за комментарий! Действительно, часто иконку не находим, но для наших нужд этого пока хватает. А вот искать иконку с указанием размеров — это идея! Уже думаю :)
В нашем проекте нет такой функции, чтобы обмениваться личными сообщениями. Если появится такая тема, я обязательно учту этот момент, спасибо за то, что обратили внимание :)
Спасибо, что так погрузились! Про «парсить код страницы» — это возможно после того, как ты этот код получишь, а как его получить? Опять запрос, от них отказались. Насчет кэшировать — пока считается, что пользователи пользуются нашим приложением не для хранения ссылок, так что по идее нагрузки большой не должно быть, если появится необходимость, будем думать. Маленький размер картинки тоже пока устраивает :)
Статья про Linux, который используется для десктопных приложений или автономных устройств. Всякие высоконагруженные системы, обрабатывающие миллионы запросов в секунду, управляющие сотней другой девайсов и прочее — это все же отдельная тема. Поддержка GPS, Wi-Fi и управление батареей тоже ведь могут быть частью ядра Linux. А кроссплатформенными кутишными апи решается, но не всегда. Обращу внимание, что мы ограничили стек используемых технологий С++ Qt 5.12. Это то, что мы использовали на реальном проекте, и поверьте, возможности данной версии Qt весьма ограничены.
Спасибо за дополнение! Цель статьи — показать, как получить соответствующие данные. Как ими воспользоваться, каждый волен решать самостоятельно. Можно отображать для пользователя, сразу после получения, можно, как вы предложили, разбить по слоям и только потом использовать.
Swagger будет всегда содержать актуальную документацию, как и если использовать, например, файл XML-документации, который будет находиться в той же директории, что и скомпилированный файл DLL или EXE. Имя файла будет соответствовать имени сборки, например MyProject.xml. XML-документация может быть использована для создания HTML-документации при помощи инструментов, таких как DocFX или Sandcastle.
xml
<PropertyGroup>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>
Добрый день! Спасибо за дискуссию. Поясним: п. 1-3. В статье указан простой пример и функция может быть большего размера. Да, я согласен, что имя функции должно отражать, "что я выполняю", но xml-комментарии не только помогают быстрее прочитать назначение, но и быстрее интерпретировать его на родной язык разработчиков. То же самое относится к параметрам и возвращаемым значениям. Так же с легкостью импортируются, например, в swagger или с помощью другого инструмента импорта xml-документации. п. 4-5. Описывать ошибки — дополнительный способ защиты. Внутри его так же можно описать. Сам эксепшн по сути также создан для того, чтобы уберечь нас от неожиданных событий.
Спасибо, что поделились! Никто не запрещает использовать любые удобные для вас методы. Автор рассказал о своем личном опыте, который может кому-то помочь и упростить его код.
Спасибо за полезное и очень важное дополнение! Существует четкое разделение ролей, но, к сожалению, не все компании и заказчики о них в курсе. На многих проектах каноническое распределение обязанностей между специалистами сильно изменилось. Мы стараемся, чтобы как можно больше разработчиков и заказчиков были осведомлены о правильном распределении ролей, а не искали универсального специалиста в качестве «волшебной таблетки от всех проблем».
Наряду с использованием широкого спектра современных инструментов ИБ, мы подбираем и специфические релевантные варианты для каждого конкретного случая.
В некоторых компаниях все еще работают с ПО, которое написано на более ранних версиях Java. И которые в силу различных обстоятельств не могут перейти на более старшие версии. Для них не менее важно уметь настраивать правила безопасности, учитывая и внутренние регламенты организаций.
Мы учитываем все пожелания заказчиков и подбираем решение исходя из ситуации. В этом особенность заказной разработки.
Конечно, использование маинд карты для простой формы ввода может показаться излишним. Автор использовала эту форму в качестве визуального примера, на котором просто объяснить, как такой подход может помочь.
На практике интеллект-карты чаще используются для более сложных проектов, где необходимо глубокое понимание пользовательского опыта. Вот почему это помогает:
лучше понять, как пользователи будут взаимодействовать с продуктом;
выявить скрытые проблемы, которые могут быть не очевидны на первый взгляд;
сделать тестирование более эффективным, сфокусировав его на ключевых моментах пользовательского опыта.
В результате время, потраченное на создание маинд карты, окупается за счет лучшего понимания пользователей и выявления важных проблем на ранней стадии.
Есть такой вариант в Jira https://www.atlassian.com/ru/agile/tutorials/burndown-charts
Привет, благодарим за обратную связь! Мы ценим комментарии наших читателей и нам важно видеть конструктивную критику.
Ответ автора: не сказал бы, что SDET не нужны там, где используют Low-Code. В процессе создания этой статьи я заметил, что на просторах сети есть интересные вакансии, например, эта: https://builtin.com/job/sdet-appian-experience-remote/2957618
Поэтому было принято решение включить маленький кусочек информации про Low-Code/No-Code платформы. Насчет «воды» могу только указать на тег статьи — это лишь мнение :)
Спасибо за комментарий!:) Постараемся ответить по порядку.
Да, такой вариант рассматривался. Но все же мы решили продолжать разрабатывать и поддерживать проект с использованием KMP, так как мы видим тенденцию развития данной технологии и уверены, что вскоре многие проблемы будут решены. В том числе путем перехода на новый UI Compose Multiplatform. Еще раз подчеркнем, что мы не утверждаем, что KMP — это плохая технология и ее нужно опасаться. Совсем наоборот. Мы говорим о том, к каким неочевидным трудностям управления проектом стоит быть готовым при использовании KMP, а также делаем вывод, что при росте масштаба проекта и сложности бизнес-логики растет и фатальность допущенных ошибок.
и 3. Согласны с вами по поводу современных языков программирования. На счет формирования команды автор полагает, что здесь решает, в том числе, владелец проекта и то финансирование, которое он готов вложить команду разработки. Универсальный разработчик - не редкость, но его экспертность дороже оплачивается. Такие специалисты конечно ценятся на проекте, но иногда нужно больше «неуниверсальных» рук и умов, чтобы уложиться в поставленные сроки)
Да, фиксировать контракты между доменной и нативными частями необходимо в любом случае. Но если приложение полностью нативное, то разработчики часто работают по конкретному флоу, реализуя все механизмы от самых низших слоев к высшим (если мы говорим Clean Architecture) и сам более гибко может менять контракт
Конечно нет, KMP не виновник проблем проекта) Все инструменты хороши, нужно уметь ими правильно пользоваться
Спасибо за замечание! На самом деле мы изначально хотели тестировать без внешних вызовов. Но вы правы — оба варианта могут быть использованы)
Новичкам в разработке мы обычно советуем начать с этих книг, независимо от языка программирования:
• «Чистый код» Р.Мартина
• «Грокаем алгоритмы» А.Бхаргава — очень помогает с базовыми пониманием, что такое алгоритмы, какие бывают и т.д.
• «2022. System Design. Подготовка к сложному интервью» — очень рекомендуем прочитать 1 и 2 главу всем, кто планирует работать с микросервисами и т.д.
• «TDD Экстремальное программирование» К.Бека — нужно ознакомиться с водной частью (1 и 2 глава), дальше идет уже сильно специфическая тематика.
Для тех, кто только задумался о том, чтобы освоить Golang, можем порекомендовать «Head First. Изучаем Go» Джея Макгаврен, после которой лучше сразу читать «Go на практике» Мэтта Батчера и Мэтта Фарина.
Все остальные книги и последовательность опциональны от выбора и предпочтений молодого бойца на Go :)
Спасибо за то, что переводите и издаете такие полезные книги :)
Спасибо, работает! Пока работала над этой задачей, тестировала на собственных ссылках, и всегда открытая фигма как раз иконку не отдает :) У них иконки лежат по другому урлу —static.figma.com.
Вашим способом фигмовскую иконку я добыла :) Правда, страшненькая, маленькая, но все-таки! Это хороший повод поискать еще несколько вариантов добычи иконок и написать вторую часть статьи :)
Спасибо за комментарий! Действительно, часто иконку не находим, но для наших нужд этого пока хватает. А вот искать иконку с указанием размеров — это идея! Уже думаю :)
В нашем проекте нет такой функции, чтобы обмениваться личными сообщениями. Если появится такая тема, я обязательно учту этот момент, спасибо за то, что обратили внимание :)
Спасибо, что так погрузились! Про «парсить код страницы» — это возможно после того, как ты этот код получишь, а как его получить? Опять запрос, от них отказались. Насчет кэшировать — пока считается, что пользователи пользуются нашим приложением не для хранения ссылок, так что по идее нагрузки большой не должно быть, если появится необходимость, будем думать. Маленький размер картинки тоже пока устраивает :)
Статья про Linux, который используется для десктопных приложений или автономных устройств. Всякие высоконагруженные системы, обрабатывающие миллионы запросов в секунду, управляющие сотней другой девайсов и прочее — это все же отдельная тема. Поддержка GPS, Wi-Fi и управление батареей тоже ведь могут быть частью ядра Linux.
А кроссплатформенными кутишными апи решается, но не всегда. Обращу внимание, что мы ограничили стек используемых технологий С++ Qt 5.12. Это то, что мы использовали на реальном проекте, и поверьте, возможности данной версии Qt весьма ограничены.
Спасибо за дополнение! Цель статьи — показать, как получить соответствующие данные. Как ими воспользоваться, каждый волен решать самостоятельно. Можно отображать для пользователя, сразу после получения, можно, как вы предложили, разбить по слоям и только потом использовать.
Swagger будет всегда содержать актуальную документацию, как и если использовать, например, файл XML-документации, который будет находиться в той же директории, что и скомпилированный файл DLL или EXE. Имя файла будет соответствовать имени сборки, например MyProject.xml. XML-документация может быть использована для создания HTML-документации при помощи инструментов, таких как DocFX или Sandcastle.
Добрый день! Спасибо за дискуссию. Поясним:
п. 1-3. В статье указан простой пример и функция может быть большего размера. Да, я согласен, что имя функции должно отражать, "что я выполняю", но xml-комментарии не только помогают быстрее прочитать назначение, но и быстрее интерпретировать его на родной язык разработчиков. То же самое относится к параметрам и возвращаемым значениям. Так же с легкостью импортируются, например, в swagger или с помощью другого инструмента импорта xml-документации.
п. 4-5. Описывать ошибки — дополнительный способ защиты. Внутри его так же можно описать. Сам эксепшн по сути также создан для того, чтобы уберечь нас от неожиданных событий.
Спасибо, что поделились! Никто не запрещает использовать любые удобные для вас методы. Автор рассказал о своем личном опыте, который может кому-то помочь и упростить его код.
Спасибо за внимательность, исправлено
Всем спасибо за замечания! Внесли изменения, теперь статья более актуальна)