7 ключови практики за кодиране за пъргави разработчици

Agile разработването на софтуер не се отнася само до гъвкави принципи и практики. За да бъде успешен в пускането на софтуер, който влияе положително на крайните потребители, отговаря на техническия дълг и се разгръща надеждно, екипът на разработчиците трябва също така да разгледа техните практики за кодиране, водещи до гъвкавост и архитектурни стандарти.

Още по-важно съображение е заложено за технологичните организации. Колкото и да е трудно да разработите софтуер, още по-трудно е да внедрявате подобрения и надстройки редовно за продължителен период. Devops CI / CD и IAC (инфраструктура като код) частично адресират един критичен фактор, тъй като автоматизацията позволява надеждни и повторяеми начини за разполагане на приложения. Добавете непрекъснато тестване и екипите за разработка имат начин да потвърдят, че промените в кода не засягат съществуващата функционалност.

С напредването на приложенията обаче първоначалните разработчици преминават към други проекти, а понякога и към други компании. Когато нови разработчици се присъединят към екипа, те трябва да научат архитектурата на софтуера и да разберат кода, преди да могат надеждно и ефективно да го променят.

Освен това разработчиците, които създават приложения, често искат да разработят нови. Може да се чувствате комфортно и безопасно да останете привързани към приложенията, които разработвате, но връзката с кода ви не е здравословна за вашата кариера или организация.

Най-добрият начин да преминете към нови и вълнуващи инициативи за разработване на софтуер е да направите вашата архитектура, приложение и код лесно поддържани от други разработчици. Пъргавите екипи и разработчици трябва да установят и прилагат практики за кодиране, които поддържат непрекъснато разработване на софтуер.

1. Не преоткривайте колелото

Първото правило за кодиране: Не кодирайте нещо, което не се нуждае от кодиране! Как

  • Помислете за задаване на въпроси относно изискванията. Защо дадена функция е важна? Кой се възползва? По-конкретно, проучете опции за некодиране, за да разрешите проблема. Понякога най-доброто решение изобщо не е решение.
  • Някой от вашата организация вече ли е кодирал подобно решение? Може би има микроуслуга, която просто се нуждае от подобрение или софтуерна библиотека, която се нуждае от незначително надграждане? Не забравяйте да прегледате кодовата база на вашата организация, преди да кодирате нещо ново.
  • Има ли решения на трети страни, включително инструменти на достъпна цена SaaS или опции с отворен код, които отговарят на минимални изисквания?
  • Разглеждали ли сте отворени хранилища за кодиране като GitHub за примери на кодове и фрагменти, които отговарят на изискванията за съответствие на вашата организация?

2. Обмислете възможностите за разработка с нисък код

Ако все пак трябва да кодирате решение, тогава може би алтернативните платформи с нисък код могат да позволят разработването на възможностите по-ефективно в сравнение с кодирането на езици за разработка като Java, .Net, PHP и JavaScript.

Платформите с нисък код като Caspio, Quick Base, Appian, OutSystems и Vantiq предоставят инструменти за разработване на приложения с малко код и понякога дори без кодиране изобщо. Всяка платформа е специализирана в различни възможности и по този начин е подходяща за определен клас приложения. Caspio например улеснява вграждането на формуляри и работни процеси в уебсайтове. Quick Base има стабилни възможности за работен процес и автоматизация, а управляваната от събития архитектура на Vantiq е подходяща за IoT и други приложения за данни в реално време.

Има моменти, когато се изисква кодиране, но разработчиците също трябва да владеят една или повече опции за разработка с нисък код и да ги обмислят за подходящи случаи на употреба.  

3. Автоматизирайте тестването

Освен писането на код, който отговаря на изискванията, едно от най-важните неща, които разработчиците трябва да направят, е да го тестват. Тестовите практики за разработка и автоматизираните инструменти за тестване са узрели и екипите за разработка трябва да включват тестове за единица, регресия, производителност и сигурност като част от техните гъвкави оценки.

В допълнение към тестовете за валидиране на компилации и версии, тези тестове също помагат да се направи кодът по-поддържаем. Тестовете са документация и установяват договор за това как трябва да се държи кодът. Когато нови разработчици се присъединят към екипи и неволно внедрят лоша промяна, непрекъснатото тестване спира компилацията и предоставя значима обратна връзка на разработчика, за да се справи бързо с проблема.

4. Екстернализирайте всички конфигурационни параметри

Не трябва да има извинение за разработчиците да поставят твърди кодове на системно ниво, потребителски имена и пароли или друга информация за конфигурацията в кода. Виждал съм разработчици да използват преки пътища, докато разработват прототипи, които попадат в производствената среда. В днешните архитектури това никога не трябва да се прави. Твърдото кодиране не е технически дълг, а мързелива, безотговорна практика на кодиране, която може да има значителни последици. Ако кодът стане случайно достъпен, той създава уязвимост на защитата, ако са изложени крайни точки или идентификационни данни за достъп.

Отиването на една стъпка по-напред, когато се работи по наследствен код, адресирането на всякакви твърдо кодирани конфигурации и параметри трябва да бъде технически приоритет, който не подлежи на договаряне.

5. Следвайте конвенциите за именуване и включете коментари, за да направите кода четим

Веднъж работех с невероятно талантлив разработчик, който не знаеше добре английски и не беше най-добрият машинописец. Той създава екземпляри на обекти с имена като a , b и c и след това създава локални променливи, наречени zz , yy , xx . Би се ангажирал да почисти това преди пускането, но рядко се проследяваше.

Не трябва да имате нужда от програмиране на двойки или тълпи, за да признаете, че това е ужасна практика.

Екипите трябва да приемат конвенции за именуване като Ръководство за стилове на JavaScript на JavaScript и Ръководство за стил на Java и да се ангажират да коментират кода поне на модулно ниво и в идеалния случай на ниво клас. Освен това организациите трябва да обмислят използването на инструменти за анализ на статичен код, които предоставят обратна връзка на разработчиците, когато кодът се нуждае от рефакторинг за структурата и факторите за четливост.

6. Често проверявайте кода в контрола на версиите

Ако не проверявате кода в контрола на версиите ежедневно или по-често, той може да създаде конфликти и други блокове, които влияят на екипа. Една малка грешка може да накара пъргавите екипи да пропуснат ангажиментите си за спринт или да създадат допълнителна работа за разрешаване на зависимости.

Екипите трябва да се споразумеят за конвенции за проверка на код, който не е готов за производство. Конвенционалните подходи включват флагове за функции и разклоняване на Git.

7. Избягвайте да кодирате героиката и сложността

Повечето разработчици, които познавам, станаха професионални софтуерни инженери, защото обичат да решават предизвикателствата за кодиране. Кодирането е изкуство, наука и занаят, а по-добрите разработчици се стремят към провокиращи размисъл задачи за кодиране и елегантни внедрения.

Освен че има сива граница между решаването на предизвикателни бизнес и технически задачи срещу генерирането на кодиране, което оставя следващите разработчици с код, който е труден за разбиране и сложен за поддръжка.

За тези от нас, които са кодирали известно време, помним удобството на Perl еднолинейните линии или използването на вложени шаблони в C ++. Понякога има основателни причини да се използват тези подходи, но ако нова група разработчици не разбира тези техники, е по-трудно да промените кода. Понякога прости, но по-малко елегантни практики за кодиране са по-добри.

Движеща ловкост в гъвкавата разработка на софтуер

Ритуалите, вградени в размисъл и пъргаво развитие, включително ангажименти, избори, ревюта на спринтове и ретроспективи, вече са доказани практики, които дават възможност за сътрудничество на екипа и стимулират успешното изпълнение. Но за да демонстрират гъвкавост за дълго време, разработчиците трябва да поемат отговорности и практики за кодиране, които позволяват по-дългосрочна поддръжка и разширяемост на кода, който разработват.

Екипите за разработка трябва да имат критичен поглед върху своите практики за кодиране. Той не е достатъчно добър за демонстрация и пускане днес; също е от решаващо значение да се даде възможност на другите лесно да поддържат приложението и кода.