holeksii/traineeship

Привіт!

Ми зібралися тут, щоб стати крутими комерційними розробниками😊

Для початку розберемося з визначеннями:

Хто такий комерційний розробник? – Це людина, яка приносить бізнесу гроші.

Як він може це робити? – Розробляти софт, який заробляє або економить гроші. Для цього він повинен, витративши мінімальну кількість ресурсів, розробити софт, що має внутрішню і зовнішню якість.

• Зовнішня якість – як добре софт вирішує бізнес-завдання.
• Внутрішня якість – на скільки легко створений софт розвивати, підтримувати, а також на скільки легко його розуміти іншим членам команди.

Які навички має крутий розробник? – Окрім технічних навичок (куди ж без них), у крутого розробник розвинуті - «soft skills». Насамперед це - "вміння допомагати" іншим членам команди. Працюючи в команді, ми можемо примножити результати своїх зусиль, навчивши людей того, що вміємо чи навчаючись у них. Важливою частиною цієї навички є - "вміння критикувати конструктивно". Ми не кажемо, що зроблено погано, а говоримо, що можна зробити краще і чому!

Отже, наші принципи:

• Мета роботи розробника – за мінімальний час зробити максимально якісне ПЗ. Ми хочемо вдосконалювати цю навичку.
• Взаємодопомога – ми працюємо в команді і допомагаємо один одному.
• Конструктивна критика – ми кажемо, що можна зробити краще, а не що зроблено погано.

Основні правила

1. Код форматується відповідно до Google code style.

   Налаштування для середовища розробки ( https://github.com/google/styleguide ):

   • IntelliJ IDEA https://github.com/google/styleguide/blob/gh-pages/intellij-java-google-style.xml як імпортувати: https://www.jetbrains.com/help/idea/copying-code-style-settings.html
   • Eclipse https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml

2. Усі проєкти збираються за допомогою Maven.

3. Файли середовища розробки та інші тимчасові файли не повинні потрапляти в репозиторій ( https://github.com/github/gitignore ).

4. Покриття коду Unit tests (Junit5):

   • Тест перевіряє один шматок логіки за раз. Тобто, якщо необхідно перевірити як працює метод, який ми перевіряємо з правильними даними - це один тест. Якщо необхідно перевірити як працює метод з іншими даними - другий тест.
   • Тест пишеться за принципом:

   I. Підготовка тестових даних.

   II. Виконання методу, який ми тестуємо.

   III. Перевірка результату.

Алгоритм виконання завдань

1. Перейти за посиланням на завдання в GitHub Clasroom, буде створено ваш особистий репозиторій.
2. Виконати завдання. Усі коміти відправити в master.
3. Надіслати посилання на виконане завдання в дискорд-канал #ready-for-review
4. Переходити до наступного завдання
5. Якщо до попереднього завдання прийшли якісь зауваження, то виправити їх і знову опублікувати посилання в #ready-for-review

FAQ

Відповіді на поширені запитання ти можеш знайти у файлі FAQ. Будь ласка, ознайомся з ним. Якщо не знайшов відповідь на своє запитання там, у нашому ком'юніті є канал "Help", зазирни туди. Якщо не знайшов відповіді на своє запитання - напиши там і тобі обов'язково хтось відповість.

Завдання

Завдання виконуються в такій послідовності:

1. Intro
2. Generics
3. Game of Life
4. GC