10 наиболее полезных сайтов для Java-разработчиков
Источник:
Tarun Telang
Ниже приведен список наиболее эффективных и заслуживающих доверия веб-ресурсов о технологии Java. Они могут быть полезными как для опытных Java-программистов, так и для новичков. Я использую эти ресурсы в течение многих лет для поиска последней информации о технологиях Java.
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 1]()
Ресурс содержит информацию почти обо всем, что вам нужно знать о Java, включая новости, статьи, блоги, справочные материалы, варианты карьеры и информацию, связанную с проектами Java. Рекомендую регулярно посещать этот сайт, чтобы быть в курсе последних новостей о платформе Java.
Вам не обойтись без этого ресурса, если вы хотите загрузить и установить последнюю версию Java Development Kit. Он также содержит подробные инструкции о том, как запускать установочные файлы Java на различных платформах.
Этот раздел сайта Oracle содержит справочную информацию по API для Java SE. Документация HTML создается из исходного кода Java с помощью инструмента JavaDoc.
Здесь имеется большая коллекция учебных пособий и справочных материалов по языку программирования Java. Уроки также доступны, в том числе, в виде книги «Учебник по Java, шестое издание» (на английском языке). Вы можете перейти по этой ссылке, чтобы купить ее в Amazon.
Сайт содержит пробные тесты и полезные ресурсы для изучения различных тем, начиная от Java, баз данных, Android и до подготовки к сертификации. Это очень хорошее место для изучения Java с помощью практических упражнений.
Здесь вы можете найти проекты, связанные с Java EE, а также проекты, ранее размещенные на Java.net. На этом сайте размещено множество различных ссылок на проекты с дополнительной информацией о них и контактные данные, которые относятся к этим проектам.
Посетите этот сайт, чтобы следить за обсуждениями, вопросами и ответами о технологиях и фреймворках Java. Javapedia.net полезен как для опытных разработчиков Java и Java EE, так и для новичков и студентов, готовящихся к собеседованию.
Сайт содержит информацию о последних технологиях в Java Enterprise Edition. Это место, где Java-разработчики обсуждают различные темы, связанные с Java, Java EE, программированием, программным обеспечением и тенденциями в серверной разработке. Это очень большое онлайн-сообщество для корпоративных архитекторов и разработчиков Java, в котором можно найти ежедневные новости, технические обсуждения, вебинары и другую полезную информацию.
Это место, где вы можете найти новейшее программное обеспечение Java (игры, мобильные и настольные приложения). Это легальный и безопасный ресурс для установки подключаемых модулей Java. В отличие от многих других сайтов, тут нет никаких рекламных всплывающих окон и сомнительных установочных файлов, которые на самом деле не связаны с Java.
Здесь вы найдете актуальную информацию о том, как Java поддерживает инновации, лежащие в основе нашего цифрового мира. Сайт содержит коллекцию ресурсов по платформе Java для студентов, любителей, разработчиков и руководителей IT-компаний.
Несмотря на то, что в интернете можно найти много подобных сайтов со ссылками по Java, большинство из них устарели и показывают информацию, актуальную только до Java 5. После Java 8 язык претерпел серьезные изменения, что требует от разработчиков нового подхода к программированию на Java. Язык также очень быстро развивается, новые версии Java выпускаются каждые шесть месяцев.
7 моделей разработки программного обеспечения, о которых вы должны знать
Источник:
DZone
Жизненный цикл разработки софта — это процесс планирования, проектирования, разработки, тестирования и развертывания программного обеспечения с минимально возможными затратами, предпочтительно в кратчайшие сроки. Для достижения этой цели команды разработчиков должны выбрать правильную модель разработки программного обеспечения, соответствующую требованиям проекта и ожиданиям всех заинтересованных сторон.
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 2]()
Существует 7 моделей, которые вам следует знать, от каскадной до V-Model и Scrum. Давайте рассмотрим каждую из них.
1. Каскадная модель (Waterfall)
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 3]()
Каскадная модель считается одним из первых методов разработки программного обеспечения. Уже из названия понятно, что этот процесс разработки включает в себя линейное продвижение по порядку: анализ, проектирование, разработка, тестирование, развертывание и поддержка. Каждый этап четко определен конкретными результатами.
Каскадная модель последовательная, это означает, что следующий этап не может начаться, пока не завершен текущий. Этап считается завершенным, когда поставленная цель достигнута и кто-то дает согласие на дальнейшую работу над проектом.
В этой модели нет гибкости — вы не можете пропускать, возвращаться или менять этапы. В результате процесс разработки может оказаться излишне сложным и дорогим. Отсутствие гибкости делает эту модель более дорогостоящей и трудоемкой по сравнению с другими моделями. Если требования неясны или неправильно поняты, то использовать эту модель очень рискованно.
Кроме того, эта модель не идеальна для длительных, сложных или текущих проектов, где требуется большая гибкость.
Хотя недостатки модели заметны и значительны, она может быть полезна для небольших разовых проектов с ограниченными требованиями и короткими сроками, поскольку она проста и быстро настраивается. Однако команда должна убедиться, что все требования четко определены, однозначны и не могут измениться в будущем.
Сейчас модель Waterfall потеряла популярность, поскольку IT-команды практикуют более гибкую разработку программного обеспечения, которая позволяет вносить постоянные улучшения.
2. V-модель
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 4]()
V-модель, или модель утверждения и проверки, расширяет каскадную модель, добавляя в нее план тестирования. Вместо того, чтобы двигаться линейно вниз по этапам разработки программного обеспечения, V-модель движется вниз до этапа кодирования, затем поворачивается и начинает подниматься вверх по этапах тестирования, образуя V-образную форму.
Каждому этапу разработки соответствует определенное действие по тестированию. Это позволяет группе находить ошибки в технических требованиях, коде и архитектуре на ранних этапах работы над проектом. Добавление плана тестирования дает V-модели больше шансов на успех, чем у каскадной модели. Однако V-модель остается линейной, что делает ее негибкой.
Как и в каскадной модели, команда может начать следующий этап только после завершения предыдущего этапа. Это затрудняет внесение изменений, делает их дорогостоящими и требует много времени.
Таким образом, эта модель лучше всего подходит для коротких проектов с фиксированными, четко определенными и задокументированными требованиями, но не идеальна для длительных, сложных или текущих проектов.
3. Итеративная (инкрементная) модель
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 5]()
Как и другие модели разработки программного обеспечения, итеративная (инкрементная) модель разработана для устранения некоторых недостатков каскадной модели. Она также начинается с планирования и заканчивается развертыванием. Но в отличие от каскадной модели, эта модель включает повторяющиеся циклы на протяжении всего процесса. Эти циклы бывают итеративными (повторяющимися) и инкрементными (пошаговыми).
Процесс разработки начинается с выполнения небольшого набора требований, и каждый цикл в нем сопровождается новым набором требований. Итерационный характер этой модели позволяет программному обеспечению развиваться и расти, поскольку небольшие изменения могут вноситься на протяжении всего процесса. Это происходит потому, что новая итерация строится на основе предыдущей. Разработчики могут вносить изменения, основываясь на опыте предыдущих циклов.
Поскольку все требования не изложены в начале проекта и многие изменения вносятся в процессе, работа может начаться быстро. Однако ресурсы могут быть быстро израсходованы, поскольку процесс часто повторяется, не говоря уже о том, что управление становится более сложным.
Несмотря на то, что модель допускает некоторые изменения, она по-прежнему состоит из четко обозначенных процессов, которые иногда приводят к негибкости. Стоимость внесения изменений здесь ниже, чем у каскадной модели и модели V, но эта модель не идеальна для проектов, в которых требования могут изменяться во время итерации.
Итерационная модель создает больше рисков из-за частых изменений, неизвестных затрат и требований к ресурсам, а также неопределенных сроков.
4. Модель прототипирования
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 6]()
Модель прототипирования сосредоточена на улучшении понимания командой разработчиков желаний и потребностей клиента путем создания прототипов. Создав небольшую рабочую копию желаемой программы, можно устранить недопонимание до того, как начнется полноценная разработка.
Прототип разрабатывается, тестируется и дорабатывается с учетом пожеланий и замечаний заказчика. Как только прототип принят, команда приступает к разработке конечного продукта.
Модель прототипирования может резко сократить количество итераций. Это экономит время и увеличивает шансы на удовлетворение запросов клиентов. Однако нужно учитывать время, которое разработчик тратит на разработку прототипов. Если заказчик требует много изменений, часто меняет свое мнение или делает невыполнимые запросы, то разработка прототипа может быстро усложниться. По этой причине лучше всего ограничить количество итераций, разрешенных до принятия прототипа.
Когда окончательный прототип находится в разработке, больше никаких требований или изменений вносить в план нельзя. Это существенный недостаток модели прототипирования.
5. Спиральная модель
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 7]()
Спиральная модель фокусируется на оценке риска. В результате любая команда, желающая использовать эту модель, должна иметь специалистов, обладающих знаниями и навыками в конкретной области.
Модель состоит из четырех этапов: планирование, анализ рисков, разработка и оценка. Количество витков в спирали зависит от конкретного проекта и требований руководителя. В среднем разработка программного обеспечения по этой модели занимает 6 месяцев.
Спиральная модель сочетает в себе функции каскадной модели и прототипирования, делая упор на дизайн, включая создание прототипа (на этапе проектирования), и путем выполнения этапов, аналогичных тем, что в модели Waterfall.
Непрерывная и повторяющаяся разработка позволяет разработчикам вносить изменения и добавлять новые функции. Кроме того, разработка носит систематический характер, что упрощает процесс.
Заказчик участвует в рассмотрении каждого этапа цикла, что может быть обременительно для процесса разработки, если с заказчиком нет постоянной связи. Поскольку количество циклов или итераций не определено, существует риск превышения бюджета и несоблюдения сроков. Поэтому создание готового продукта часто требует больших затрат и времени.
Гибкая методология (Agile)
Agile — это методология, основанная на 12 принципах, изложенных в
Agile Manifesto. Это скорее образ мышления, чем набор строгих протоколов. Метод Agile создан для более эффективной разработки программного обеспечения, чем с использованием предыдущих моделей, включая каскадную модель. Суть гибкой модели состоит в сосредоточении внимания на сотрудничестве, коммуникации и постоянных изменениях.
Существует несколько вариантов Agile-разработки. Все они ориентированы на командную работу, межфункциональное сотрудничество, итеративную разработку и раннюю обратную связь с клиентами. Тестирование, обратная связь и внесение изменений позволяют командам разрабатывать и выпускать лучшее программное обеспечение.
Давайте посмотрим на 2 модели Agile.
6. Модель Scrum
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 8]()
Модель Scrum — самая популярная модель Agile. Ее итерации в разработке известны как спринты. Во время этих спринтов продолжительностью 1–4 недели команды оценивают предыдущий спринт, добавляют новые функции и планируют следующий спринт. Изменения не допускаются после того, как определены действия спринта.
После каждого спринта добавляются новые функции / элементы, которые будут закодированы и протестированы в следующем спринте. Это происходит до тех пор, пока не будут добавлены все функции и проект не будет признан готовым к выпуску.
Расширение сотрудничества между межфункциональными командами, а также между организацией и заказчиком, снижает количество недоразумений и ошибок, которые часто возникают из-за недостаточного взаимодействия. Кроме того, дополнительные этапы сокращают время выхода на рынок.
Улучшенная коммуникация сокращает время, затрачиваемое на устранение ошибок, и увеличивает вероятность того, что конечный пользователь будет доволен продуктом. Тем не менее, такое сотрудничество требует от клиента значительного участия в рабочем процессе. Также нужно учесть, что если заказчик требует добавить слишком много функций, срок сдачи проекта может быть сдвинут.
7. Модель Kanban
![Кофе-брейк #52. 10 наиболее полезных сайтов для Java-разработчиков, 7 моделей разработки программного обеспечения, о которых вы должны знать - 9]()
В отличие от других моделей, Kanban не имеет ярко выраженных итераций. Если команда действительно планирует итерации, это невероятно короткие спринты, иногда всего за один день.
Для визуального обозначения статуса выполнения проекта и других деталей используется доска с заметками в виде стикеров (наклеек). Такая визуализация позволяет команде сосредоточиться на самой важной функции в разработке на данный момент. Кроме того, доска Kanban подчеркивает, что остается пространство для постоянного улучшения функций.
Хотя метод стикеров на доске помогает мотивировать команду сосредоточиться на выполнении важной задачи, это плохой способ определять и поддерживать временные рамки. По этой причине очень сложно планировать длительные проекты.
Поскольку нет установленного этапа планирования, изменения могут вноситься в любое время. Одним из распространенных недостатков Kanban является отсутствие временных рамок. Эта проблема может усугубиться, если изменения вносятся постоянно.
Переход к Agile
Каждая из перечисленных моделей создавалась с целью улучшения процесса разработки и доставки программного обеспечения. Любая модель разработки может хорошо работать для конкретных типов проектов. Однако старые модели с ручным управлением, такие как каскадная модель, быстро уходят в прошлое.
IT-команды и компании в целом при создании программного обеспечения должны действовать быстрее и эффективнее, удовлетворяя потребности клиентов и не отставая от конкурентов. Более быстрый, воспроизводимый и безопасный процесс разработки программного обеспечения основан на автоматизации. И поскольку уровень автоматизации и скорости недостижим для многих моделей, в конечном итоге методология Agile становится все более популярной.
Существует 7 моделей, которые вам следует знать, от каскадной до V-Model и Scrum. Давайте рассмотрим каждую из них.
Каскадная модель считается одним из первых методов разработки программного обеспечения. Уже из названия понятно, что этот процесс разработки включает в себя линейное продвижение по порядку: анализ, проектирование, разработка, тестирование, развертывание и поддержка. Каждый этап четко определен конкретными результатами.
Каскадная модель последовательная, это означает, что следующий этап не может начаться, пока не завершен текущий. Этап считается завершенным, когда поставленная цель достигнута и кто-то дает согласие на дальнейшую работу над проектом.
В этой модели нет гибкости — вы не можете пропускать, возвращаться или менять этапы. В результате процесс разработки может оказаться излишне сложным и дорогим. Отсутствие гибкости делает эту модель более дорогостоящей и трудоемкой по сравнению с другими моделями. Если требования неясны или неправильно поняты, то использовать эту модель очень рискованно.
Кроме того, эта модель не идеальна для длительных, сложных или текущих проектов, где требуется большая гибкость.
Хотя недостатки модели заметны и значительны, она может быть полезна для небольших разовых проектов с ограниченными требованиями и короткими сроками, поскольку она проста и быстро настраивается. Однако команда должна убедиться, что все требования четко определены, однозначны и не могут измениться в будущем.
Сейчас модель Waterfall потеряла популярность, поскольку IT-команды практикуют более гибкую разработку программного обеспечения, которая позволяет вносить постоянные улучшения.
V-модель, или модель утверждения и проверки, расширяет каскадную модель, добавляя в нее план тестирования. Вместо того, чтобы двигаться линейно вниз по этапам разработки программного обеспечения, V-модель движется вниз до этапа кодирования, затем поворачивается и начинает подниматься вверх по этапах тестирования, образуя V-образную форму.
Каждому этапу разработки соответствует определенное действие по тестированию. Это позволяет группе находить ошибки в технических требованиях, коде и архитектуре на ранних этапах работы над проектом. Добавление плана тестирования дает V-модели больше шансов на успех, чем у каскадной модели. Однако V-модель остается линейной, что делает ее негибкой.
Как и в каскадной модели, команда может начать следующий этап только после завершения предыдущего этапа. Это затрудняет внесение изменений, делает их дорогостоящими и требует много времени.
Таким образом, эта модель лучше всего подходит для коротких проектов с фиксированными, четко определенными и задокументированными требованиями, но не идеальна для длительных, сложных или текущих проектов.
Как и другие модели разработки программного обеспечения, итеративная (инкрементная) модель разработана для устранения некоторых недостатков каскадной модели. Она также начинается с планирования и заканчивается развертыванием. Но в отличие от каскадной модели, эта модель включает повторяющиеся циклы на протяжении всего процесса. Эти циклы бывают итеративными (повторяющимися) и инкрементными (пошаговыми).
Процесс разработки начинается с выполнения небольшого набора требований, и каждый цикл в нем сопровождается новым набором требований. Итерационный характер этой модели позволяет программному обеспечению развиваться и расти, поскольку небольшие изменения могут вноситься на протяжении всего процесса. Это происходит потому, что новая итерация строится на основе предыдущей. Разработчики могут вносить изменения, основываясь на опыте предыдущих циклов.
Поскольку все требования не изложены в начале проекта и многие изменения вносятся в процессе, работа может начаться быстро. Однако ресурсы могут быть быстро израсходованы, поскольку процесс часто повторяется, не говоря уже о том, что управление становится более сложным.
Несмотря на то, что модель допускает некоторые изменения, она по-прежнему состоит из четко обозначенных процессов, которые иногда приводят к негибкости. Стоимость внесения изменений здесь ниже, чем у каскадной модели и модели V, но эта модель не идеальна для проектов, в которых требования могут изменяться во время итерации.
Итерационная модель создает больше рисков из-за частых изменений, неизвестных затрат и требований к ресурсам, а также неопределенных сроков.
Модель прототипирования сосредоточена на улучшении понимания командой разработчиков желаний и потребностей клиента путем создания прототипов. Создав небольшую рабочую копию желаемой программы, можно устранить недопонимание до того, как начнется полноценная разработка.
Прототип разрабатывается, тестируется и дорабатывается с учетом пожеланий и замечаний заказчика. Как только прототип принят, команда приступает к разработке конечного продукта.
Модель прототипирования может резко сократить количество итераций. Это экономит время и увеличивает шансы на удовлетворение запросов клиентов. Однако нужно учитывать время, которое разработчик тратит на разработку прототипов. Если заказчик требует много изменений, часто меняет свое мнение или делает невыполнимые запросы, то разработка прототипа может быстро усложниться. По этой причине лучше всего ограничить количество итераций, разрешенных до принятия прототипа.
Когда окончательный прототип находится в разработке, больше никаких требований или изменений вносить в план нельзя. Это существенный недостаток модели прототипирования.
Спиральная модель фокусируется на оценке риска. В результате любая команда, желающая использовать эту модель, должна иметь специалистов, обладающих знаниями и навыками в конкретной области.
Модель состоит из четырех этапов: планирование, анализ рисков, разработка и оценка. Количество витков в спирали зависит от конкретного проекта и требований руководителя. В среднем разработка программного обеспечения по этой модели занимает 6 месяцев.
Спиральная модель сочетает в себе функции каскадной модели и прототипирования, делая упор на дизайн, включая создание прототипа (на этапе проектирования), и путем выполнения этапов, аналогичных тем, что в модели Waterfall.
Непрерывная и повторяющаяся разработка позволяет разработчикам вносить изменения и добавлять новые функции. Кроме того, разработка носит систематический характер, что упрощает процесс.
Заказчик участвует в рассмотрении каждого этапа цикла, что может быть обременительно для процесса разработки, если с заказчиком нет постоянной связи. Поскольку количество циклов или итераций не определено, существует риск превышения бюджета и несоблюдения сроков. Поэтому создание готового продукта часто требует больших затрат и времени.
Модель Scrum — самая популярная модель Agile. Ее итерации в разработке известны как спринты. Во время этих спринтов продолжительностью 1–4 недели команды оценивают предыдущий спринт, добавляют новые функции и планируют следующий спринт. Изменения не допускаются после того, как определены действия спринта.
После каждого спринта добавляются новые функции / элементы, которые будут закодированы и протестированы в следующем спринте. Это происходит до тех пор, пока не будут добавлены все функции и проект не будет признан готовым к выпуску.
Расширение сотрудничества между межфункциональными командами, а также между организацией и заказчиком, снижает количество недоразумений и ошибок, которые часто возникают из-за недостаточного взаимодействия. Кроме того, дополнительные этапы сокращают время выхода на рынок.
Улучшенная коммуникация сокращает время, затрачиваемое на устранение ошибок, и увеличивает вероятность того, что конечный пользователь будет доволен продуктом. Тем не менее, такое сотрудничество требует от клиента значительного участия в рабочем процессе. Также нужно учесть, что если заказчик требует добавить слишком много функций, срок сдачи проекта может быть сдвинут.
В отличие от других моделей, Kanban не имеет ярко выраженных итераций. Если команда действительно планирует итерации, это невероятно короткие спринты, иногда всего за один день.
Для визуального обозначения статуса выполнения проекта и других деталей используется доска с заметками в виде стикеров (наклеек). Такая визуализация позволяет команде сосредоточиться на самой важной функции в разработке на данный момент. Кроме того, доска Kanban подчеркивает, что остается пространство для постоянного улучшения функций.
Хотя метод стикеров на доске помогает мотивировать команду сосредоточиться на выполнении важной задачи, это плохой способ определять и поддерживать временные рамки. По этой причине очень сложно планировать длительные проекты.
Поскольку нет установленного этапа планирования, изменения могут вноситься в любое время. Одним из распространенных недостатков Kanban является отсутствие временных рамок. Эта проблема может усугубиться, если изменения вносятся постоянно.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ