Корпоративни стандарти или анархия мама
Резюме :. Много компании (и често команда) в даден момент, които се опитват да работят на техните споразумения и стандарти по отношение на структурата и дизайна на кода / документи от процеса на развитие, използването на инструменти и др В повечето случаи не се нуждаят от него. Но ако искате, как?
Стандарти и споразумения (ASIC) могат да се разделят по следния начин:
SYS писане код
Коко върху проектирането и доставката
SYS дизайн на потребителския интерфейс (UI приложения и документи)
Някои може да смятат, че Коко е пропорционална на големината на компанията, казват те, отколкото е голям, толкова по-най "бюрокрация". За да разсее този мит, ето няколко примера за моите работни места:
15K приложения). Там SYS UI документи и приложения за възможните рамки и библиотеки, както и от курса трябва да изглеждат двоичен.
Mesto2 (подобни цифри:
15K приложения). Има Коко само на документите за регистрация.
Mesto3 (> 1K човек
20 приложения). Има SYS: с документи, инструменти и монтажния процес, процесът на артефакти за проверка на версии прилагане на версии на бази данни, съхраняващи код, конфигурацията, приложенията, процеси освобождаване.
Усложни въвеждането на нови хора. защото корпоративните стандарти се различават един от друг в различни компании (екипи), новият човек дошъл при вас в проекта, ще трябва да прекарат усилия за да се присъединят към този процес. Вие ще трябва да му обясни как се прави това, а след това се провери. Е, да се опрости процедурата, разбира се, трябва да опишете Коко.
Различни екипи отговарят различен стил. Развитието на мнозина - творческия процес, и медиатори на съвременни методологии (Agile) твърдят, че процесът трябва да бъде коригирана с техните специфични нужди, без да го усложнява без реална нужда. Ето защо, създаването на корпоративен стандарт, който трябва да бъде предмет на краищата, вие най-вероятно ще се влоши ефективността на конкретни отбори и / или физически лица, този процес те просто няма да е подходящ.
Трябва да се поддържа стандарти. Това е страхотна, а това също е важно - досадна част от работата. Има хора, които не разбират напълно вашия документ, или може да намери грешки, несъвместимост с определени ситуации. И все пак - за една година може да получите по-различно мнение, стандартите, ще трябва да се актуализира, а след това отново да разгърнат.
Стандартите се променят с хората. Сега тези Коко ви развиват и всичко се случва, както обикновено, но и да отидете на сайта си ще дойде някой друг с мнение различно от твоя. Цялата объркването е вероятно да започне отново. Заслужаваше ли си?
Това прави по-лесно да се върти души. Обикновено е много лошо аргумент (въпреки че аз мисля, че се случва най-често). Първо, хората често искат да се върти, за да се промени ситуацията, за да се опита нови подходи, това беше скучно. И тук сте с тяхното обединение. На второ място, отново, различен дизайн и изисквания също могат да бъдат различни. Ако, например, използва unifitsiruete рамки и технология, значително може да усложни ефективното разработване, например, няма да има проблеми с производителността или архитектура, хората ще трябва да вмъкнете патерици заради обединението.
Интерфейсът между отборите. Развитие може да поддържа множество команди, например, си среди управлява отделни DevOps отбора си или молбата тества отделен екип QA или освобождаване продукт всички леви хора или някой ви настройва ПО, или ... За тези команди, вие не може да бъде само те могат да се променят, тъй като вие 10yu проекти. И ако всеки от тези проекти - е уникален, заповядва такива услуги ще страдат и работят неефективно. Т.е. Би било разумно, ако такъв екип, който да напише документ, който ще бъде последван от всички останали. Като пример, екипът на CI могат да изискват, че всички работи само с Maven.
Че продуктите са сходни за клиентите. Понякога да, има изискване, че продуктите са сходни по отношение на потребителския интерфейс, така че потребителите да разберат, че това е един и същ доставчик или от един и същи ресурс.
Намалете броя на подкрепа в бъдеще. Ако различни екипи притежават един инструмент (Nexus, JIRA, CI, и т.н.), така че може да се случи, че те са различни и го изправи в един момент ще се срине. За това не се случи, или всеки отбор трябва да има свои собствени инструменти, или трябва да се мисли за общи споразумения.
Има опит. Нека да инструмент, който е много добро ниво на хора притежават Н. И това е възможно да се използва алтернативен InstrumentB вчера vahtersha казал за него. Ясно е, че всеки инструмент не е съвършен, но предвид обстоятелствата на употреба InstrumentB - по този начин увеличава риска. Да, ние искаме промяна. Да, истината разберат сравнението. Разбира се, че има смисъл да се експериментира, ако това допринася за ситуацията, изведнъж InstrumentB би било много по-удобно. Но е важно да не се прекалява, нов инструмент / рамка за проекта - достатъчно, за да не забравяме и сладки хемороиди. Зад това, ако имате опит в компанията, логично е, ако всички отбори ще използват възможностите на уреда.
Тъй като сте решили да се стандартизира по нещо в кабинета си, ето някои съвети.
Възможността да не следват стандарта не трябва да бъде. За това е чудесно, ако всички проверки са автоматизирани. Вие искате да се ангажират съобщение започва с идентификационния номер на случая? Направете една кука, която проверява формата и отхвърли ангажират, ако тя не отговаря на стандарта. Кодът трябва да се следват конвенциите? Регулиране на теста, който ще свали събранието, ако правилата не са спазени. Ако съществува стандарт само по име / в документа, той винаги ще бъде някой, който няма да го последвам. Това създава риск, че хората ще прекарват времето си пред съда и обяснения, и не го искат вече трети път. В един момент, да започне да вкара всички.
Отделно от това, бих искал да спомена, времето за регистриране изразходвани. Това също е вид споразумение, стандарта, свързани с процеса, когато ръководителят на проекта например иска всички да празнуваме колко време са били изразходвани и за какво. Защо е лоша идея може да се прочете тук.
В този случай, критерият ще бъде, както следва: ако отборът ще бъде да се придържат към установените правила, след като инициаторът отиде на почивка, така че стандартът не е изпълнена успешно и че тези правила не се поддават на изпълнението на това и се опитайте да не дори си струва.
Начини да автоматизират тестването:
Maven Enforcer Plugin
Екстри. проверява на сървъра на CI
Трябва да бъде възможно да се заобиколят ограниченията. Това е в противоречие с предишния елемент, но понякога в някои критични ситуации, все още е полезно да има заобиколно решение. Ето, че това не е задължително всички :)
Обратна връзка от автоматизация трябва да е информационен. Т.е. Ако правило е счупен и удостоверяване е неуспешно, съобщение за грешка, трябва да съдържа обяснение, предложение (как да се определи положението), вероятно препратка към добавите. ресурси и, в най-лошия, за да се свържете с хора, които може да ви посъветва.
За развитието и поддържането на стандарти изискват специални хора. Това означава, че, ако наистина искате да ги спазвате. Тъй като работя тук много, това е напълно възможно, че тези хора трябва да бъдат цял екип. Ако следвате стандартите не е критично. Вижте следващия елемент.
Насоки - по-благоприятни стандарти. Насоки различават от незадължителни стандарти. Можете ли да опишете някои от тях за проекти / изисквания на процеса, но само като съвети, те казват, че би било по-добре и по-лесно за всички да ги спазвате е желателно, но не е необходимо. Например, въведете Atlassian, които имат UI насока. Повечето, че си струва да се отбележи, че спазват, дори и като се има предвид, че след тези правила, никой проверки.
Използвайте инструментите за служебен стаж. По-лесно да се напише своите документи и да използвате вече описаното съгласието на мястото на самия инструмент. Тези споразумения, разработчиците ще могат да се използват в други проекти и в други компании. Това е добър начин да се стандартизира навсякъде.
Pros в този случай е, че zamarachivatsya относно въвеждането на тези правила ще трябва да бъде много по-малък. И идеята много ще ги спазвате поне до известна степен, без ритници.
Заключения. Сякаш някаква не иска да обедини всички - за да го направят до края, не всеки може. Ето защо, насоките, или се развиват, или да бъде готов да се посвети на обединението на всичкия си труд или се пригответе за които да се следват вашите стандарти и споразумения ще бъдат една малка група от хора.