Като Java програмист бих искал да спазвам добрите Java практики #1
Description
Какво искаме да постигнем.
Като програмисти целта ни е да автоматизираме процеси и най - оптимално да работим с данни. Работата ни изисква да работим с други хора и да комуникираме с тях информация за това какво сме постигнали, като същевременно създаваме код, който има нужда от минимално количество обяснения за да бъде разбран.
Как ще постигнем нашите цели.
За да улесним комуникацията между девелопърите, често използваме конвеции. Конвенциите са не само свързание с езиците за програмиране които използваме, но и с технологиите които избираме.
Какви стъпки да предприемем за да спазваме добрите практики в програмирането.
Git
Когато започваме нов проект е добре да имаме възможност да споделяме кода си и да можем да комуникираме с колегите си , както самият код, то така и защо сме взели дадени решения. За целта използваме система за потдържане на версии на кода ни (SCV) , към моменнта най -популярната и може би най -гъвкава такава система е git.
Добрите практики свързание с гит са доста, но можем да започнем от основните.
- Всеки един проект трябва да има
README.md, който лесно и ясно да покзва какво се очаква от този проект, какво има в него и допълнителна информация за технологиите и структурата на проекта. Можем да мислим за този файл като едно mini-wiki на проекта ни. Readme файла е винаги в репозиторито и ние успяваме да си набавим необходимата информация без да ни се налага да ходим във външни системи, всичко от което имаме нужда за да започнем да работим се намира в репото. .gitignore- този файл инструктира гит какво не искаме да бъде в репозиторито ни. Тук може да се намерят доста добри темплейти. Правилото е да не качваме файлове, които са специфични за нашата локална среда, всичко в репозиторито трябва да има отношение към проекта.
Пример за подобни файлове са artefacts от идето ни като папка.ideaили файлJava-Advanced.iml- Когато правим нова задача винаги я правим в различен бранч от мастъра. Бранч за дадена задача се нарича още
feature branch, когато работим с feature бранчове, можем да сме сигурни че не пречим на никого да работи, макар и текущото репо да се използва само от един програмист е добре да се спазва така практика дори и в подобни ситуациии. - Pull Request - След като сме готови с нашата задача е добра практика, направо си е задължително, някой с повече от опит или други човек от нашият екип да погледне кода, да направи code review. Pull Request- a не е концепция на git а на github, но въпреки това много удобно се вписва в потока на работа с git. Когато правим pull request правим следните неща :
- Винаги бранчваме от основният бранч за разбработка, това не винаги е master, но в случаят е; т.е бранчваме от master бранча.
- Докато работим по дадена задача, няма нищо лошо в това да правим повечеко къмити и да ги пращаме към repoto тоест :
git commit -m "issue-1 Some meaningful message"и след товаgit push - След като сме готови с задачата си, отиваме в UI на гитхъб и правим Pull Request
- След това избираме кой да бъде нашият проверяващ, reviewer, и започваме диалог с този човек докато и двамата не сме съгласни, че кода може да добавен към репото.
- След това идва най -сладката част , merge-ването на кода към основният branch за разработка.
С Pull Requests е много по -лесно да се комуникира информация вътре в екипа, това е и основната функция на Pull Request-a.
Java
Java e един от доста старите езици за програмиране, създадена през 1995/1996, това е позволило на пграмистите да изградяд доста добри практики за да улеснят споделянето на код помежду си.
###. Наименования
Имената на пакети
Имената на пакетите трябва да са reverse url, тоест все едно гледаме website урл на обратно - пример :
package edu.softuni.javaadvancedне бива да използваме MultidimentionalArrays за име на пакет. Можем да преименуваме този пакет на
package edu.softuni.javaadvanced.arrays.multidimensionalИмена на Класове
Имената на класовете са винаги с Главна бука, спазвайки camelCase конвенцията. Не е добра практика да започват с подчертваки или числа.