МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЛЬВІВСЬКА ПОЛІТЕХНІКА»
ІНСТИТУТ ГУМАНІТАРНИХ ТА СОЦІАЛЬНИХ НАУК
КАФЕДРА ІНОЗЕМНИХ МОВ
РЕФЕРАТ
НА ТЕМУ:
«Адаптивний код з використанням С#»
ВИКОНАЛА:
аспірант кафедри ПЗ
Пєщик А.П.
___________________
НАУКОВИЙ КЕРІВНИК:
д.т.н., проф. Федасюк Д.В.
___________________
КОНСУЛЬТАНТ З
АНГЛІЙСЬКОЇ МОВИ:
д.пед.н., доц. Гаврилюк М.В.
___________________
Львів 2016
Рецензія
Зміст
Вступ. 4
1. Scrum... 5
1.1. Ролі 5
1.2. Артефакти.. 7
2. SOLID.. 10
2.1. Принцип одного обов"язку. 10
2.2. Принцип відкритості / закритості 12
2.3. Принцип підстановки Лісков. 15
2.4. Принцип поділу інтерфейсу. 16
2.5. Принцип інверсії залежностей.. 18
Висновки. 21
Summary. 22
Vocabulary. 25
References. 27
Вступ
Programming is a slow process. If your code is adaptive, you will be able to make changes to it more quickly, more easily, and with fewer errors than you would if you were working with a codebase that impedes changes. Requirements, as every developer knows, are subject to change. How change is managed is a key differen- tiating factor between successful software projects and those that atrophy due to scope creep. Developers can react in many ways to requirement changes, with two opposing viewpoints highlighting the continuum that lies between.
First, developers can choose a rigid viewpoint. In this approach, from the develop- ment process down to class design, the project is as inflexible as if it were implemented 50 years ago by using punch cards. Waterfall methodologies are conspicuous culprits in ensuring that software cannot change freely. Their determination that the phases of analysis, design, implementation, and testing be distinct and one-way make it difficult— or at least expensive—for customers to change requirements after implementation has begun. The code, then, does not need to be built for change: the process all but forbids alterations.
The second approach, Agile methodology, is not just an alternative
to such rigid methodologies, but a reaction to them. The aim of Agile processes
is to embrace change as a necessary part of the contract between client and
developer. If customers want to change something in the product that they are
paying for, the temporal and financial cost should be correlated to the size of
the change, not the phase of the process that is currently in progress. Unlike
physical engineering, software engineering works with a malleable tool: source
code. The bricks and mortar that form a house are literally fused together as
construction progresses. The expense involved in changing the design of a house
is necessarily linked to the completion of the building phase. If the project
has not been started—if it is still just in blueprints—change is relatively
cheap. If the windows are in, the electricity wired up, and the plumbing
fitted, moving the upstairs bathroom down next to the kitchen could be
prohibitively expensive. With code, mov- ing features around and reworking the
navigation of a user interface should not be as significant.
Unfortunately, this is not always the case. The temporal cost alone often
prohibits such changes. This, I find, is largely a result of a lack of
adaptability in code.
Scrum (Скрам) - одна з найпопулярніших методологій гнучкої розробки. Одна з причин її популярності - простота.
У методології Scrum всього три ролі:
· Scrum Master
· Product Owner
· Team
Скрам Майстер (Scrum Master) - найважливіша роль в методології. Скрам Майстер відповідає за успіх Scrum в проекті. По суті, Скрам Майстер є інтерфейсом між менеджментом і командою. Як правило, цю роль в проекті відіграє менеджер проекту або лідер команди. Важливо підкреслити, що Скрам Майстер не роздає завдання членам команди. У Scrum команда самоорганізується і є самокеровною.
Основні обов"язки Скрам Майстра:
§ Створює атмосферу довіри
§ Бере участь в мітингах як ведучий
§ Усуває перешкоди
§ Робить проблеми і відкриті питання видимими
§ Відповідає за дотримання практик і процесу в команді
Скрам Майстер веде Daily Scrum Meeting і відстежує прогрес команди за допомогою Sprint Backlog, відзначаючи статус всіх завдань в спринті. Scrum Master може також допомагати Product Owner створювати Backlog для команди.
Product Owner - це людина, яка відповідає за розробку продукту. Як правило, це product manager для продуктової розробки, менеджер проекту для внутрішньої розробки і представник замовника для розробки на замовлення. Product Owner - це єдина точка прийняття остаточних рішень для команди в проекті, саме тому це завжди одна людина, а не група або комітет. Обов"язки Product Owner такі:
§ Відповідає за формування product vision
§ Управляє очікуваннями замовників і всіх зацікавлених осіб
§ Координує і пріоретизує Product backlog
§ Надає зрозумілі і перевірені вимоги команді
§ Взаємодіє з командою і замовником
§ Відповідає за приймання коду в кінці кожної ітерації
Product Owner ставить завдання команді, але він не має права ставити завдання конкретного члена проектної команди протягом спринту.
Команда (Team). В методології Scrum команда самоорганізується і є самокерованою. Команда бере на себе зобов"язання щодо виконання обсягу робіт на спринт перед Product Owner. Робота команди оцінюється як робота єдиної групи. У Scrum внесок окремих членів проектної команди не оцінюється, так як це розвалює самоорганізацію команди. Обов"язки команди такі:
§ Відповідає за оцінку елементів Backlog
§ Приймає рішення по дизайну та імплементації
§ Розробляє програмне забезпечення і надає його замовнику
§ Відстежує власний прогрес (разом зі Скрам Майстром)
§ Відповідає за результат перед Product Owner
Розмір команди обмежується розміром групи людей, здатних ефективно взаємодіяти лицем до лиця. Типові розмір команди - 7 плюс мінус 2.
Команда в Scrum крос функціональна. У неї входять люди з різними навичками - розробники, аналітики, тестувальники. Немає заздалегідь визначених і поділених ролей в команді, що обмежують область дій членів команди. Команда складається з інженерів, які вносять свій внесок в загальний успіх проекту відповідно до своїх здібностей і проектної необхідністю.
Команда самоорганізовується для виконання конкретних завдань в проекті, що дозволяє їй гнучко реагувати на будь-які можливі завдання. Для полегшення комунікацій команда повинна знаходитися в одному місці. Переважно розміщувати команду не в кубриках, а в одній загальній кімнаті для того, щоб зменшити перешкоди для вільного спілкування. Команді необхідно надати все необхідне для комфортної роботи, забезпечити дошками і фліпчартами, надати всі необхідні інструменти і середу для роботи.
1.2. АртефактиProduct Backlog - це пріоритизування списку наявних на даний момент бізнес вимог і технічних вимог до системи. Product Backlog включає в себе завдання які повинні бути зроблені.
Product Backlog постійно переглядається і доповнюється - в нього включаються нові вимоги, видаляються непотрібні, переглядаються пріоритети. За Product Backlog відповідає Product Owner. Він також працює спільно з командою для того, щоб отримати наближену оцінку на виконання задач Product Backlog для того, щоб більш точно розставляти пріоритети відповідно до необхідного часом на виконання.
Sprint Backlog
Sprint Backlog містить функціональність, обрану Product Owner з Product Backlog. Всі функції розбиті за завданнями, кожна з яких оцінюється командою. Кожен день команда оцінює обсяг роботи, який потрібно виконати для завершення завдань.
Результатом Sprint є готовий продукт, який можна передавати замовнику. Замовник отримує можливість гнучко управляти цілями системи, оцінюючи результат спринту і пропонуючи поліпшення до створеної функціональності.
Такі поліпшення потрапляють в Product Backlog, пріорітезіруются нарівні з іншими вимогами і можуть бути заплановані на наступний (або на один з наступних) спринтів. Протягом спринту робляться всі роботи по збору вимог, дизайну, кодування і тестування продукту. Цілі спринту повинні бути фіксованим. Це дозволяє команді давати зобов"язання на той обсяг робіт, який повинен бути зроблений в спринті. Це означає, що Sprint Backlog не може бути змінений ніким, крім команди.
Daily Scrum Meeting
Цей мітинг проходить щоранку на початку дня. Він призначений для того, щоб всі члени команди знали, хто і чим займається в проекті. Тривалість цього мітингу строго обмежена і не повинна перевищувати 15 хвилин. Мета мітингу - поділитися інформацією. Він не призначений для вирішення проблем в проекті. Всі питання, що вимагають спеціального обговорення повинні бути винесені за межі мітингу. Скрам мітинг проводить скрам Майстер. Він по колу задає питання кожному члену команди
§ Що зроблено вчора?
§ Що буде зроблено сьогодні?
§ З якими проблемами зіткнувся?
Демо і рев"ю спринту
Рекомендована тривалість 4 години. Команда демонструє інкремент продукту, створений за останній спринт. Product Owner, менеджмент, замовники, користувачі в свою чергу його оцінюють. Команда розповідає про поставлені завдання, про те як вони були вирішені, які перешкоди були у них на шляху, які були прийняті рішення, які проблеми залишилися невирішеними.
На підставі огляду приймаюча сторона може зробити висновки про те, як повинна далі розвиватися система. Учасники мітингу роблять висновки про те, як відбувався процес в команді і пропонує рішення щодо його поліпшення. Скрам Майстер відповідає за організацію та проведення цього мітингу. Команда допомагає йому скласти адженду і розпланувати хто і в якій послідовності що представляє. Підготовка до мітингу не повинна займати у команди багато часу (правило - не більше двох годин).
Зокрема, саме тому забороняється використовувати презентації в Power Point. Підготовка до мітингу не повинна займати у команди більше 2-ух годин.
2. SOLID
Коли процес написання ПЗ еволюціонував з наукової області в справжню інженерну дисципліну, виникла ціла низка принципів. Одні з таких принципів є SOLID.
Під абревіатурою SOLID ховаються наступні принципі розробки ПЗ:
· Single responsibility (принцип одного обов"язку),
· Open for extension and closed for modification (принцип відкритості / закритості),
· Liskov substitution (принцип підстановки Лісков),
· Interface segregation (принцип поділу інтерфейсу),
· Dependency inversion (принцип інверсії залежностей).
Дотримання принципів побудови програмного забезпечення SOLID допоможе уникнути побудова важкої для розширення архітектури ПЗ.
2.1. Принцип одного обов"язкуПринцип одного обов"язку - це перший принцип SOLID, який означає, що клас має бути створений для виконання лише однієї задачі, яку він повинен повністю інкапсулювати. Отже, всі сервіси цього класу мають бути повністю підпорядковані її виконанню. Результатом слідування цій концепції є наявність лише однієї причини для зміни класу, що робить його значно «здоровішим».
Програмний код наведений нижче демонструє порушення даного прикладу.
Нехай в системі є клас, що представляє в ній робітника:
public class Employee {
private String name;
// another fields
public String getName() {
return name;
}
// another methods
public void printReport() {
// code for printing report
}
}
Крім цього, існує можливість друкувати звіт про робітника за допомогою методу printReport(). Це і є порушення прицнипу.
Для прикладу, розглянемо випадок зміни формату звіту. Це змусить програмістів редагувати printReport(), що, можливо, призведе до зміни робочого коду, що відповідає за представлення робітника. Та навпаки, якщо у клас буде додано будь-яка нова функціональність, наприклад поле telNumber, то ці зміни будуть впливати на вміст звіту. А редагуючи вміст, можна зачепити формат звіту.
Очевидно, що проблема полягає в багатоцільовому Employee. Тому її рішення буде наступним — розділити його функціональність, наприклад так:
public class Employee {
private String name;
// another fields
public String getName() {
return name;
}
// another methods
}
public class Reporter {
public void printReport(Employee worker) {
// code for printing report
}
}
Серед плюсів прицнипу Одного обов’язку варто відмітити наступні:
· протидіє дублюванню коду, адже якщо функціональність розташована в неправильному місці, то доведеться копіювати її в потрібне;
· зменшує можливість зміни вже відтестованого коду;
· забезпечує відповідність назв класів та їх функціональності, що полегшує життя тим, хто обслуговуватиме цей код в майбутньому.
Мінус використання полягає в зростанні кількості класів, що приводить до зростання складності системи.
2.2. Принцип відкритості / закритостіПриницп відкритості/закритості – це наступний принцип SOLID, який означає, що програмні сутності, такі як класи, модулі, функції, методи та ін. мають бути відкритими для розширення та закритими для змін. Це означає, що вони можуть надавати можливість змінювати свою поведінку без або з мінімальними змінами коду. Тому при проектуванні системи необхідно закласти в неї можливість безболісного додавання функціоналу чи його зміни.
Прикладом порушення цього прикладу є наступний програмний код.
Нехай в системі є клас спортивного парсера для створення різних об"єктів SportInfo, що інкапсулюють різну інформацію про гру:
public class BadParserRealization {
public SportInfo parse(String[] data) {
SportInfo result;
if (data[0].equals("nba")) {
// code to parse NBA
} else {
if (data[0].equals("nhl")) {
// code to parse NHL
}
}
return result;
}
}
На перший погляд все коректно, проте при спробі додати нову лігу, наприклад MLB, виникнуть проблеми. Програмісти будуть змушені редагувати parse(String[] data), і, можливо, зачеплять робочий код.
Дана проблема легко вирішується застосуванням шаблону проектування Builder. Рішення може бути наступним:
public class BetterParserRealization {
private Map
public BetterParserRealization(Map
setBuilders(builders);
}
public void setBuilders(Map
if (builders == null) {
throw new NullPointerException("Builders can not be null!");
}
this.builders = builders;
}
public void parse(String[] data) {
SportInfoBuilder builder = builders.get(data[0]);
builder.build(data);
return builder.getResult();
}
}
public interface SportInfoBuilder {
public void build(String[] data);
}
public class NBASportInfoBuilder implements SportInfoBuilder {
private SportInfo result;
@Override
public void build(String[] data) {
// code to parse NBA
}
public SportInfo getResult() {
return result;
}
}
Спочатку визначається парсер, що може обробити вхідний масив. Відношення між ним та лігою встановлюється іншим класом (це може бути шаблон проектування Abstract Factory або IoC контейнер). Варто відмітити, що при додаванні нової ліги, потреби в редагуванні вже робочого коду відпадають, натомість необхідно створити новий клас, що буде реалізовувати інтерфейс SportInfoBuilder.
До переваг та недоілків даного прицнипу можна віднести
· Плюсом використання цього принципу є те, що він дозволяє додавати новий функціонал без редагування вже написаного коду, отже система стає гнучкою та легко супроводжується.
· Мінус полягає в зростанні кількості класів, що приводить до зростання складності системи.
2.3. Принцип підстановки ЛісковПринцип підстановки Лісков має наступне визначення - найважливіший критерій для оцінки якості ухвалених рішень при побудові ієрархій успадкування. Сформулювати його можна у вигляді простого правила: тип S буде підтипом Т тоді і тільки тоді, коли кожному об"єктові о1 типу S відповідає певний об"єкт o2 типу T таким чином, що для всіх програм P, реалізованих в термінах T, поведінка P не зміниться, якщо o1 замінити на o2.
Принцип Лісков є суворішим за поняття підтипу в теорії типів, яка вимагає тільки:
· коваріантність методів по типу результата;
· контраваріантність методів по типах аргументів;
· заборону в методах підтипу викиду винятків, які не є похідними від типів винятків, що викидуються методами базового типу.
Тому це призводить до деяких обмежень на те як контракти можуть взаємодіяти з успадкуванням:
· Передумови не можуть бути посилені в підтипі.
· Післяумови не можуть бути послаблені в підтипі.
· Інваріанти базового типу повинні виконуватись в підтипі.
· «Історичне обмеження»: заборона модифікації стану об"єкта методами підтипу, які відсутні в базовому типі.
Функція, що обробляє ієрархію класів з порушеннями принципу Лісков, використовує посилання на базовий клас, але також вимушена мати інформацію про підклас. Така функція також порушує принцип відкритості/закритості оскільки її необхідно змінювати в разі появи нових похідних класів.
У цьому контексті принцип заміщення Лісков можна переформулювати так: Функції, які використовують посилання на базові класи, повинні мати можливість використовувати об"єкти похідних класів, не знаючи про це.
З відси випливає, що публічне успадкування можна використовувати тільки коли виконується принцип заміщення Лісков. Приватне успадкування дозволене тільки для доступу до protected частини та заміщення віртуальних методів. Для всіх інших випадків, успадковування використовувати не бажано.
2.4. Принцип поділу інтерфейсуСуть принципу поділу інтерфейсу - багато малих інтерфейсів краще, ніж один великий. Іншими словами, занадто «товсті» інтерфейси необхідно розділяти на менші та специфічні, щоб їх клієнти знали лише про ті методи, що необхідні для них у роботі. Як результат, при зміні певного функціоналу, незмінними мають лишитися ті класи, що не використовують його. Тобто виконання цього принципу допомагає системі залишатися гнучкою при внесенні до неї змін та лишатися простою для рефакторингу.
Прикладом дотримання даного принципу є використання шаблону Адаптер, який наведений в коді програми.
public interface Animal {
void eat();
void fly();
void bark();
}
public interface Eatable {
void eat();
}
public interface Flyable {
void fly();
}
public interface Barkable {
void bark();
}
public class FlyingAdapter implements Eatable, Flyable {
private Animal animal;
public FlyingAdapter(Animal animal) {
this.animal = animal;
}
@Override
public void fly() {
animal.fly();
}
@Override
public void eat() {
animal.eat();
}
}
public class BarkingAdapter implements Eatable, Barkable {
private Animal animal;
public BarkingAdapter(Animal animal) {
this.animal = animal;
}
@Override
public void bark() {
animal.bark();
}
@Override
public void eat() {
animal.eat();
}
}
Наслідки використання цього підходу є те, що клієнтський код працює лише з тією функціональністю, яка йому потрібна. В той же час, робота відбувається за допомогою сутностей старої системи, що не вимагає в ній будь-яких змін. Подібний підхід знижує очевидність архітектурних рішень, прочитність коду, і має використовуватись тільки якщо зміна старої системи неможлива з певних причин.
Серед плюсів варто відзначити наступні:
· при необхідності створення нової реалізації інтерфейсу немає потреби реалізовувати непотрібні методи;
· клієнтський код отримує лише те, що потрібне для його роботи.
Мінус використання полягає в зростанні кількості інтерфейсів, що приводить до зростання складності системи.
2.5. Принцип інверсії залежностейОстаній з принципів SOLID є принцип інверсії залежностей, суть якого полягає у розриві зв"язності між програмними модулями вищого та нижчого рівнів за допомогою спільних абстракцій.
Принцип формулюється наступним чином:
· Модулі вищого рівня не повинні залежати від модулів нижчого рівня. Всі вони повинні залежати від абстракцій.
· Абстракції не повинні залежати від деталей реалізації. Деталі реалізації повинні залежати від абстракцій.
Принцип інверсії залежностей вирішує проблеми коли програма, або її частина, яка виконує своє призначення і в той самий час має одну або декілька наступних особливостей, є невдало спроектованою:
1. У програму, або її частину, складно внести зміни, оскільки будь-яка зміна впливає на занадто велику кількість компонентів системи (жорсткість).
2. При внесенні змін порушується робота компонентів системи у несподіваних місцях (крихкість).
3. Складно використати той самий код у іншій програмі, оскільки його неможливо витягти з даної програми (непорушність).
Програма спроектована жорстко, якщо у неї не можна легко внести зміни. Така жорсткість обумовлена тим фактом, що одна єдина зміна до тісно взаємозв’язаного коду дає початок послідовності змін в залежних модулях. Якщо дизайнери або розробники не здатні визначити межі тієї послідовності змін, вплив цих змін неможливо спрогнозувати. А отже і наслідки цих змін спрогнозувати неможливо. Керівники проектів, які стикаються з подібною непередбачуваністю, неохоче погоджуються на впровадження змін. Тому такий дизайн офіційно визнається жорстким.
Крихкість означає схильність програми до виникнення помилок у багатьох місцях після внесення хоча б однієї правки. Часто буває, що проблеми виникають у місцях, які не мають концептуального відношення до місця, якого стосувалась правка. Така крихкість знижує довіру до організації, що займалася проектуванням та розробкою програми. Користувачі та керівники проектів не можуть передбачити якість їх продукту. Прості зміни, внесені до однієї частини програми, призводять до збоїв у роботі зовсім не пов’язаних з нею інших частин програми. Спроби виправити це призводять до виникнення ще більших труднощів, і процес підтримки продукту починає нагадувати собаку, що бігає за власним хвостом.
Дизайн програми є непорушним
у випадку, коли бажані частини дизайну сильно залежать від небажаних деталей
реалізації. Дизайнери, які поставлять собі за мету проектування такого дизайну,
який можна було б використати у інших програмах, можуть здивуватися, як зручно
такий дизайн використовувати при створенні нової програми. Але якщо було
спроектовано дизайн, що сильно пов’язаний с деталями реалізації, то такі
дизайнери будуть налякані кількістю роботи, необхідної для виокремлення потрібної
частини дизайну з-поміж інших непотрібних частин. У багатьох випадках такі
проекти не використовуються повторно, оскільки витрати на виокремлення
необхідної частини вищі, ніж витрати на проектування нового дизайну.
Summary
1)First chapter has served as an introduction to the Scrum process, which is an iterative and incremental agile software development framework for managing product development.
Scrum projects, like any software projects, are vulnerable to failure. Spotting when something is going wrong is a significant part of management, but spotting why it is happening can be even harder. The rest of the book is providing advice and guidelines for ensuring that code is adaptive from the bottom up, making change easier and allowing you to focus solely on adding business value with every sprint.
2)The next chapter is showing how the organization of dependencies presents a significant problem when creating software applications.
Dependencies must be managed at all levels, from individual classes and methods interacting with each other, through assembly references, to the high-level architecture of components.
Author provides a solid foundation for maintainable, adaptive code that is reinforced with each chapter. Main idea is - if the assemblies are a mix of references, and the layers do not hide their infrastructural dependencies, the code will become harder to test and understand.
3)In third chapter is described what interfaces are and why they are crutual for writing adaptive code.
Interfaces are useless without accompanying implementations. But without interfaces, implementations and their associated dependencies would make it hard to maintain and extend the code.
Interfaces can simplify otherwise complicated code and add an extra dimension of adaptability.
4)Next chapter is a hybrid of unit testing and refactoring because those two activities should be paired together and performed in tandem. Each unit test should represent an expectation of the code and the result should be transmitted to a developer.
Although as code they are technical artifacts, unit tests enforce real-world behavior in objects, just as those objects encapsulate real-world concepts.
5)Fifth chapter describes The single responsibility principle. It has a hugely positive impact on the adaptability of code. Compared to equivalent code that does not follow the principle, SRP-compliant code leads to a greater number of classes that are smaller and more directed in scope. Where there would otherwise have been a single class or suite of classes with interdependencies and a confusion of responsibility, the SRP introduces order and clarity.
6)Next chapter describes The open/closed principle. How developers can build code that allows change over time.
There are two main types of extension point available: implementation inheritance and interface inheritance. Virtual and abstract methods allow to create subclasses that customize methods in a base class. If classes delegate to interfaces, this provides you with more flexibility in your extension points by a variety of patterns.
7)In seventh chapter author describes the Liskov substitution principle as one of the more complex facets of the SOLID principles. If this principle is violated, it becomes harder for clients to handle all types in a class hierarch in the same way. Ideally, clients would be able to hold a reference to a base type or interface and not alter its own behavior depending on the concrete subclass that it is actually using at run time.
8)This chapter is dedicated to the art of good interface design.
There are plenty of reasons why interfaces should be separated—to aid decoration, to correctly hide functionality from clients, as self-documentation for other developers, or as a side effect of architectural design. Whatever the reason, it is a technique which should be kept at the forefront whenever one is creating an interface. As with most programming tools, it is easier to start out on the right path than to go back and heavily refactor.
9)Last chapter is about Dependency injection. It is the core thing that holds together every other facet of this book. Such extension points are key to the development of adaptive code and key to the steady progress of an application as it gains in size and complexity.
For all its far-reaching effects, dependency injection is actually a deceptively simple pattern that is nonetheless powerful and unappreciated
Vocabulary
|
1 |
acronym |
аббревиатура |
|
2 |
adage |
поговорка |
|
3 |
adhered to |
придерживаться |
|
4 |
adhering |
придерживаясь |
|
5 |
affinity |
близость |
|
6 |
aforementioned |
вышеупомянутый |
|
7 |
alleviate |
облегчать |
|
8 |
alter |
изменять |
|
9 |
amend |
вносить изменения |
|
10 |
arrange |
договариваться |
|
11 |
assert |
утверждать |
|
12 |
back out |
уклоняться, отменять |
|
13 |
bear in mind |
имейте в виду |
|
14 |
benevolent |
великодушный |
|
15 |
bequest |
наследство |
|
16 |
bloated |
раздутый |
|
17 |
bootstrap |
начальная загрузка |
|
18 |
boundary |
граница |
|
19 |
bountiful |
обильный |
|
20 |
burdening |
обременяющий |
|
21 |
constituent |
составная часть |
|
22 |
covariance |
ковариация |
|
23 |
creep in |
подкрадываться |
|
24 |
crux |
основная проблема |
|
25 |
decoupling |
развязка |
|
26 |
deemed |
счесть |
|
27 |
define |
определять |
|
28 |
deliberately |
умышленно |
|
29 |
delineate |
описать |
|
30 |
detrimental |
вредный |
|
31 |
diligence |
старание |
|
32 |
discernable |
распознаваемый |
|
33 |
disparate |
несравнимый |
|
34 |
diversion |
отклонение |
|
35 |
elicit |
вызывать |
|
36 |
elict |
вызывать |
|
37 |
eloboration |
подготовка |
|
38 |
embedded |
встроенный |
|
39 |
embraced |
использовать |
|
40 |
endeavor |
усилие |
|
41 |
enumerable |
перечислимый |
|
42 |
essence |
сущность |
|
43 |
facet |
аспект |
|
44 |
feasible |
выполнимый |
|
45 |
frees |
освобождает |
|
46 |
further versatility |
еще большую универсальность |
|
47 |
granularity |
глубина детализации |
|
48 |
halt |
остановка |
|
49 |
humble |
скромный |
|
50 |
implicity |
неявно |
|
51 |
intimacy |
близость |
|
52 |
intimate |
личный |
|
53 |
intrinsically |
по сути |
|
54 |
invariant |
постоянный |
|
55 |
irretrievably |
безнадежно |
|
56 |
juncture |
положение дел |
|
57 |
laborious |
утомительный |
|
58 |
lynchpin |
краеугольный камень |
|
59 |
moochers |
попрошайки |
|
60 |
nail |
гвоздь |
|
61 |
negligible |
незначительный |
|
62 |
obviates |
устранять |
|
63 |
obvious |
очевидный, очевидный |
|
64 |
onerous |
затруднительный |
|
65 |
outset |
начало |
|
66 |
oxymoronic |
сочетание несочетаемого |
|
67 |
persistant |
постоянный |
|
68 |
pillar |
колонна |
|
69 |
piqued |
возбудил |
|
70 |
pithy |
лаконичный |
|
71 |
preamble |
предисловие |
|
72 |
precedence |
приоритет |
|
73 |
predicate |
утверждать |
|
74 |
prerequisite |
предпосылка |
|
75 |
preserved |
сохранился |
|
76 |
prone |
склонный |
|
77 |
refused bequest |
отказ от наследства |
|
78 |
regidity |
негибкость |
|
79 |
rejoice |
радовать |
|
80 |
reliable |
надёжный |
|
81 |
resilient |
упругий |
|
82 |
retrieve |
возвращать |
|
83 |
rigidly |
жёстко |
|
84 |
segregation |
изоляция |
|
85 |
snippet |
фрагмент |
|
86 |
spot |
какое-то определенное место |
|
87 |
stairway |
лестница |
|
88 |
superfluous |
излишний |
|
89 |
tangle |
путаница |
|
90 |
temptation |
искушение |
|
91 |
tethered |
привязан |
|
92 |
tradeoff |
компромис |
|
93 |
ubiquitous |
вездесущий |
|
94 |
unequivocally |
определённо |
|
95 |
viable |
жизнеспособный |
|
96 |
vigilant |
бдительный |
|
97 |
violated |
нарушенный |
References
1. Adaptive Code via C#: Agile coding with design patterns and SOLID principles, Gary McLean Hall, 2014
2. https://translate.google.com/
(zip - application/zip)
Статистика файлового архива
