10 найбільш корисних сайтів для Java-розробників
Джерело:
Tarun Telang Нижче наведено список найбільш ефективних і заслуговують на довіру веб-ресурсів про технологію Java. Вони можуть бути корисними як для досвідчених Java-програмістів, так і для новачків. Я використовую ці ресурси протягом багатьох років для пошуку останньої інформації про технології Java.
![Кава-брейк #52. 10 найбільш корисних сайтів для Java-розробників, 7 моделей розробки програмного забезпечення, про які ви повинні знати.]()
Ресурс містить інформацію майже про все, що вам потрібно знати про 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 моделей розробки програмного забезпечення, про які ви повинні знати.]()
На відміну від інших моделей 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 є відсутність тимчасових рамок. Ця проблема може погіршитися, якщо зміни вносяться постійно.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ