Чи слід дотримуватися поганого стилю кодування лише для того, щоб дотримуватися встановлених умов на моєму робочому місці?


102

Я працюю на своїй роботі близько року. Я в основному працюю в інтерфейсі GUI, який використовує методи із серверного сервісу C, але я, як правило, не маю з ними справи, крім повернених значень. Наш графічний інтерфейс побудований досить розумно, враховуючи наші обмеження.

Мені було доручено додати функцію до частини командного рядка програми. Більшість із цих функцій схожі на 300 рядків і важкі у використанні. Я намагаюсь зібрати шматки з них, щоб отримати конкретну інформацію про тривогу, і я маю проблеми з організацією. Я знаю, що я ускладнюю тестування, роблячи його в одній довгій функції.

Чи варто просто тримати все у величезній функції відповідно до стилю існуючих функцій, або я повинен інкапсулювати тривогу у власні функції?

Я не впевнений, чи доцільно йти проти існуючих норм кодування або чи варто мені просто кусати кулю і зробити код трохи більш заплутаним для написання.

Підсумовуючи, я порівнюю

showAlarms(){
    // tons of code
}

проти

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Спасибі за пораду всім, я вирішив, що збираюся розробити свій код з урахуванням факту, а потім запитати, що вони хочуть, і якщо вони хочуть все це в один, я можу просто вирізати зі свого факторного коду і перетворити його на 1 велика функція. Це повинно дозволити мені записати його та перевірити його легше, навіть якщо вони хочуть, щоб він був усім кодом в одному визначенні.

ОНОВЛЕННЯ: Нарешті вони були задоволені фактичним кодом, і більше однієї людини подякували мені за встановлення цього прецеденту.


117
Дуже сумнівно, що компанія, в якій ви працюєте, займає позицію, згідно з якою ваші функції повинні бути тривалістю 300 рядків, тому що "так ми завжди робили". Це не "конвенції стилів кодування"; це просто поганий стиль.
Роберт Харві

64
Це та річ, яку ви повинні обговорити з іншими членами своєї команди, щоб зрозуміти, яку практику ви бачите - це конвенції, які вони вважають важливими для всіх, і які речі, що хтось робив один раз, а ви цього не робите потрібно наслідувати. Без сумніву, буде якась кількість обох.
Сервіс

17
@beginnerBinx Це якраз і зводиться до того, як ви їх формулюєте. Не озвучте це так: "X робить щось дійсно дурне, чи я також повинен робити цю дурну справу". а як щось на зразок: "Я помічаю, що X робить це одне, чи є певна причина, що він робить так, як це робить; чи буде це проблема, якби я не робив те саме, коли писав Y?" Тоді стає їх рішення про те, чи потрібно бити старий код, або пояснити, чому вони повинні були робити це саме так (будь то зухвало чи з ентузіазмом).
Сервіс

11
Про хороший чи поганий стиль часто сперечаються і нечасто погоджуються. Викладання в університеті полягає в тому, що функції повинні бути короткими, але якщо це затьмарює сенс, не робіть цього. Тест повинен бути чіткіше, а не бездумно слідувати набору правил.
quick_now

9
Випадкові люди в Інтернеті не можуть проти прочитати своїх товаришів по команді, тому всі відповіді, які ви отримуєте тут, - це лише особисті переваги людей. Ви повинні поговорити зі своєю командою. Чи довга функція - це цілеспрямований принцип проектування? Вони б хотіли, щоб ви продовжували стиль тривалої функції або хотіли б, щоб ви написали те, що вважаєте найчистішим?
ЖакБ

Відповіді:


102

Це дійсно між вами та вашими товаришами по команді. Ніхто більше не може сказати вам правильну відповідь. Однак, якщо я можу наважитися читати між рядками, той факт, що ви називаєте цей стиль «поганим», дає деяку інформацію, яка говорить про те, що краще брати його повільно. Дуже мало стилів кодування насправді є «поганими». Є такі, які я б сам не використовував, але у них завжди є рима або причина. Це говорить про мене, що в сюжеті є більше, ніж ви бачили досі. Розмовляти навколо було б дуже мудрим закликом. Хтось може знати щось, чого ви не знаєте.

Я особисто зіткнувся з цим, під час мого першого кроку в кодуванні критичної місії в реальному часі. Я побачив такий код:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Будучи яскравим і блискучим розробником OO C ++, я негайно викликав їх на ризик помилок, який вони мали, блокуючи та розблоковуючи мутекси, а не використовуючи RAII . Я наполягав, що це краще:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Набагато простіше і безпечніше, правда ?! Навіщо вимагати від розробників пам’ятати, щоб розблокувати їхні мьютекси на всьому шляху управління потоком, коли компілятор може зробити це за вас!

Що ж, я дізнався пізніше, що для цього є процесуальна причина. Ми повинні були підтвердити, що так, програмне забезпечення працювало коректно, і був обмежений перелік інструментів, якими ми могли дозволити користуватися. Моя підхід, можливо, була кращою в іншому середовищі, але в середовищі, в якому я працював, мій підхід легко міг би збільшити обсяг роботи, що бере участь у перевірці алгоритму в десятки разів, тому що я просто вніс C ++ концепцію RAII в розділ коду це дотримувалося стандартів, які були справді більш прихильні до мислення у стилі С.

Тож те, що виглядало як поганий, прямо небезпечний, стиль кодування для мене, насправді було добре продумане, і моє «хороше» рішення було насправді небезпечним, яке збиралося викликати проблеми в дорозі.

Тож запитайте навколо. Напевно є старший розробник, який може працювати з вами, щоб зрозуміти, чому вони роблять це так. Або є старший розробник, який може допомогти вам зрозуміти витрати та переваги рефактора в цій частині коду. У будь-якому випадку, запитайте навколо!


60
Імовірно, більш небезпечною частиною прикладу mutex є очевидний брак коментарів до коду, що пояснює, чому він не міг використовувати RAII. Зрозуміло, якщо це явне блокування / розблокування по всій кодовій базі, може бути непростим додати коментар для кожного примірника. У такому випадку, можливо, повинен бути написаний праймер-документ, про який потрібно ознайомити нових розробників.
Кельвін

10
Звичайно, спілкування зі старшим завжди добре, і рефакторинг потрібно робити обережно (і з тестуванням). І звичайно, паралельність / мютекс - це особливий звір сам по собі. Але бачачи функції з> 300 рядками, я б не вкладав занадто багато часу в пошук «прихованої технічної причини», чому ці функції занадто великі. Причина, чому функції стають занадто тривалими, завжди однакова, і вони не є технічними.
Doc Brown

8
@DocBrown Просто те, що вони не технічні, не означає, що вони не є причинами. Розробникам важливо пам’ятати, що вони є однією частиною більшої машини. (Я не можу порахувати, скільки разів мені доводилося вивчати цей урок)
Cort Ammon

4
@DocBrown Так чи інакше, з ким слід поговорити. Я вибрав той приклад, який я зробив, тому що легко знайти незліченну кількість аргументів, чому дурний код дурний. Пошук аргументів, чому код, який виглядає дурним, насправді не дурний, складніше.
Корт Аммон

3
@DocBrown З ваших коментарів та відповідей, я думаю, я можу сказати, що різниця наших думок полягає в тому, що ви починаєте з припущення, що код вже "поганий", виходячи з того, які дані вам дали, тоді як я вважаю за краще взяти шляхи, які досліджують, чи є код спочатку "поганим".
Корт Аммон

84

Чесно кажучи, чи вважаєте ви, що функції, які складно використовувати, на 300 рядків, - це лише питання стилю? Отже, наслідок поганого прикладу може підтримувати загальну програму в кращому стані через послідовність? Я думаю, ви не вірите в це, інакше ви б тут не поставили цього питання.

Я здогадуюсь, що ці функції такі довгі, тому що в нашому бізнесі є безліч посередніх програмістів, які просто купують функції над функціями, не піклуючись про читабельність, якість коду, правильне іменування, тести одиниць, рефакторинг, і вони ніколи не навчилися створювати належні абстракції . Ви самі повинні вирішити, чи хочете ви слідкувати за цим стадом, чи хочете бути кращим програмістом.

Додаток, завдяки коментарям: "300 рядків" і "важко використовувати", є сильними ознаками IMHO для поганого коду. На мій досвід, малоймовірно, є якась «прихована технічна причина», чому такий код не можна реалізувати в більш читаному вигляді, порівнянні з прикладом відповіді Корта Амона. Однак я погоджуюсь з Кортом, вам слід обговорити це з відповідальними в команді - не знаходити незрозумілих причин, через які не можна змінити код або цей "тип стилю", а щоб дізнатися, як можна безпечно відновлювати код, не порушуючи речі .


127
Навіть грамотні програмісти вчиняють ці злочини, коли в строгі строки.
садок

13
@gardenhead, я можу зрозуміти, що не переробляти функцію 300 рядків, щоб заощадити час, але немає можливості, щоб написання функції на 300 рядків заощадило ваш час.
Дангф

39
@gardenhead: коли я йду до хірурга, тому що мені потрібна термінова допомога, я все одно очікую, що він знайде час, щоб вимити руки, перш ніж він почне виступати на мені. Це щось, чому люди мають навчитися в нашому бізнесі, щоб досягти реальної компетенції: завжди залишайте код у кращому стані, ніж це було раніше, і це також покращить можливість дотримуватися строків. 300 функцій рядків, як правило, зростають з кожним днем ​​людьми, яким не байдуже, і вони завжди використовуватимуть "термін" як привід.
Док Браун

17
@Dangph це економить час, коли ви додаєте до функції лише 5 рядків, а не рефакторинг. Зазвичай вони зростають, коли початкова функція довга (30+ рядків), і наступний програміст думає, що "це не мій код, я не буду рефактор, щоб не порушити його, просто додайте кілька рядків тут і там".
Джуріс

7
@Juris, наскільки я розумію, питання полягає у створенні нової функції, а не рефакторингу існуючих. Якщо ви пишете нову функцію, ви не заощадите час, перетворивши її в єдину функцію монстра.
Дангф

42

Немає.

У книзі « Прагматичний програміст» автор розповідає про теорію розбитих вікон .

Ця теорія констатує:

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

Або розглянути бруківку. Деяка підстилка накопичується. Незабаром накопичується більше сміття. Врешті-решт, люди навіть починають залишати мішки зі сміттям із ресторанів, що вивозять там, або навіть вриваються у машини.

У книзі автор пише паралель між цією теорією та кодом. Як тільки ви знайшли такий код, ви зупиняєтесь і ставите під сумнів саме це питання.

А відповідь: Ні.

Щойно ви залишите це розбите вікно - у нашому випадку поганий код - це створить ефект, що всі залишать зламані вікна позаду.

І одного дня код згортається.

Надайте всім копію чистого коду та чистого кодера .

І поки ви перебуваєте в темі, копія TDD також є хорошою.


6
Що робити, якщо база даних коду - це теплиця, окрім зламаних вікон?
Алан Шутко

8
@AlanShutko Тоді переконайтесь, що ваше резюме поточне? Знайдіть іншого роботодавця зараз .
Девід Монтгомері

12
Код рідко "руйнується". Додавати нові функції стає все складніше і складніше, забирає все більше і більше часу, а оцінки прибирання коду збільшуватимуться - а це означає, що отримувати будь-який бюджет часу на необхідне очищення стає ще складніше.
Док Браун

8
Нічого собі, якою є довільна аналогія теорії "розбитого вікна".
Самтер

4
TDD не мають до цього нічого спільного. Незалежно від того, чи збираєтесь ви їхати з драйверами для бізнесу / домену / тесту / ніщо, які нічого не змінюють, дотримуйтесь основ чистого коду. Вибачте, але насправді втомило бачити "TDD", котирується всюди, де навіть не в темі
Вальфрат

25

Так, іди. Структура! = Стиль

Ви говорите про структуру, а не про стиль. Вказівки щодо стилів не (як правило) передбачають структуру, оскільки структура, як правило, вибирається відповідно до конкретної проблеми, а не відповідності організації.

Будь обережний

Будьте впевнені, що ви не спричиняєте негативних наслідків в інших сферах, які, можливо, у вас не траплялися. Наприклад,

  • Переконайтеся, що ви не ускладнюєте diff або злиття коду, оскільки ви усунули будь-яку схожість з існуючим кодом.
  • Переконайтесь, що винятки потоки бульбашки правильно і стеки сліди не забруднені величезною купою нерозбірливих дурниць.
  • Переконайтеся, що ви випадково не виставляєте громадські точки входу, які можуть викликати проблеми при безпосередньому виклику (не вкладайте їх на карту та / або не експортуйте їх).
  • Не захаращуйте глобальну область імен, наприклад, якщо всі ваші менші функції потребують якогось глобального контексту, який раніше був оголошений у локальній функції.
  • Обов’язково перегляньте будь-які журнали та запитайте себе, чи були ви в команді підтримки, якщо журнали, згенеровані вашим кодом, будуть заплутані, коли побачите, що переплетені з журналами з будь-якого коду, який ви не торкаєтесь.
  • Переконайтеся , що ви дійсно дотримуватися існуючого стилю, наприклад , навіть якщо вони використовують стару школу угорську нотацію , і це робить ваші очі кровоточити, перебування в відповідно до загальної кодової базою. Єдине, що більш болісне, ніж читання угорських позначень - це читання коду, який використовує десяток різних типів позначень залежно від того, хто що написав.

Будь ніжним

Пам’ятайте, що ви є частиною команди, і хоча хороший код важливий, також дуже важливо, щоб члени вашої команди вміли підтримувати речі, які ви написали, коли їдете у відпустку. Спробуйте дотримуватися течії, яка матиме сенс для людей, які звикли до старого стилю. Тільки тому, що ти найрозумніший хлопець у кімнаті, це не означає, що ти повинен говорити вище всіх!


"Спробуйте дотримуватися потоку, який матиме сенс для людей, які звикли до старого стилю". - Так, чи є ваша порада програмувати так само, як будь-який некомпетентний клоун робив раніше? Додавання функції 300 рядків не спростить її.
BЈович

11
Я не казав дотримуватися потоку, який схожий. Я сказав дотримуватися потоку, який вони зрозуміють.
Джон Ву

2
Хороша порада. Коли я відновив одну команду на 5 функцій у цій відповіді, я тонко змінив семантику, попередньо обчисливши значення всередині логічного виразу, які спочатку були обчислені лише умовно. Рецензенти це схопили ;-). Серйозна порада - ретельно переглянути та протестувати. Кожна зміна може вводити помилки, і це може бути основною причиною того, що ніхто їх не допустив.
Пітер А. Шнайдер

6

Я не вважаю це умовою коду. Я розглядаю це як хтось не розуміє, як писати постійний код, який легко зрозуміти. Я б розбив ваш код на різні функції, коли ви пропонуєте та навчаєте свою команду про переваги цього, намагаючись зрозуміти, чому вони вважають, що 300-рядкові функції є прийнятними. Мені було б дуже цікаво почути їх міркування.


1
" Причин немає, це лише наша політика. "

5

Відповідь - у огляді коду.

Справжнє питання полягає в тому, що якщо ви введете добре розроблений код, чи будете ви єдиним, хто бажає працювати з ним?

Я, як і більшість людей тут, вважаю, що 300 лінійних функцій - це гидота. Однак вивезення Windex на сміттєзвалище не принесе багато користі. Проблема не в коді, це в кодерах.

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

Почніть з малого. Поцікавтесь і дізнайтеся, чи хтось більше віддає перевагу меншим функціям. Ще краще прогляньте базу коду і подивіться, чи зможете ви зрозуміти, хто пише найменші (ви можете виявити, що найгудніший код - це найстаріший код, а поточні кодери пишуть кращий код). Поговоріть з ними про це і подивіться, чи є у вас союзник. Запитайте, чи знають вони когось іншого, хто почуває себе так само. Запитайте, чи знають вони того, хто ненавидить невеликі функції.

Зберіть разом цю невелику групу і поговоріть про внесення змін. Покажіть їм тип коду, який ви хочете написати. Будьте впевнені, вони зможуть це прочитати. Будь-які заперечення сприймайте серйозно. Внесіть зміни. Підтвердьте свій код. Тепер у вас є сила зустрічі позаду вас. Ще кілька з них, і ви можете створити документ на одній сторінці, який явно приймає новий введений вами стиль.

Зустрічі - це напрочуд потужні речі. Вони можуть виробляти клоутинг. Clout - це те, що ви використаєте для боротьби з тими, хто проти цього руху. І ось що це на даний момент. Рух. Ви боретеся за право покращити статус-кво. Люди побоюються змін. Вам потрібно буде солодко поспілкуватися, погладитись і продати. Але з невеликою долею ви перетворитесь на те, що вас прийняли.


5
Якщо потрібно стільки спілкування та кількох зустрічей, щоб переконати розробників у тому, що метод 300 рядків занадто довгий, то я не думаю, що розмова не допоможе. Проблема вищезгаданого підходу полягає в тому, що якщо ви попросите дозволу на написання хорошого коду, ви перебуваєте в обороні. Але якщо ви просто пишете хороший код і витрачаєте час на рефакторинг існуючого коду, то будь-хто, хто заперечує, стоїть на обороні, щоб пояснити, чому метод рядка 300 хороший, і виправдати витрачання часу на його повернення.
Брендон

3
Я можу вам сказати, що якби мене запросили на серію зустрічей, щоб обговорити рядки коду за лімітами функцій, я знайшов би спосіб уникнути таких зустрічей. Немає правильної кількості, і ви ніколи не змусите людей погодитися. Іноді людям потрібно показати кращий спосіб.
Брендон

Іноді розбиття величезної функції (а також іменування речей краще, а також додавання коментарів та документації, як я вважаю, це необхідний перший крок перед тим, як безпечно виконувати зміни.
JDługosz

@Brandon Ви, мабуть, не означаєте, що це звучить так, але я чую, що ти маєш рацію, і всі інші можуть просто з цим впоратися. Поки ваш код працює, не має значення, якщо інша частина команди не розуміє цього. Це, звичайно, не варте часу, щоб заважати їх чомусь навчати. Ви абсолютно раді дивитися, як вони продовжують створювати 300 лінійних функцій, поки ви пишете код по-своєму.
candied_orange

1
@CandiedOrange Я, звичайно, не мав на увазі йти проти команди. Я мав на увазі те, що деякі теми найкраще вивчати, бачачи їх у дії, але намагання змусити команду прийняти демократичне рішення щодо стилю не буде результативною. Я бачив послідовність, яка використовується як привід для написання нечитабельного коду. Результат? Більш нечитабельний код. Я міг би створити ряд зустрічей, щоб поговорити про це, або я міг просто виправити це, а потім показати людям результати.
Брендон

3

Іноді доводиться йти з потоком.

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

Незалежно від безладу, і я розумію, прибирати його спокусливо. але в діловому світі не завжди є шанс змінити код рефактора.

Я б сказав, просто робіть те, що вас попросили зробити, і рухайтеся далі.

Якщо ви вважаєте, що варто переробити або переписати, ніж потрібно, щоб піднести це для обговорення з командою.


2
Якщо ви попросите дозволу на кожен маленький рефакторинг, у вас назавжди з'явиться нездійсненний код, який небезпечний для бізнесу. Менеджери дивляться лише на вартість змін, але рідко дивляться на вартість не зміни.
Брендон

5
ОП попросили написати функцію, не змінюючи сотні рядків коду
meda

2
@meda саме! У мене дуже однакова ситуація. Я розробляю нові модулі для внутрішньої мережі компанії, і я знаходжу те, що можна охарактеризувати як "роки занедбаності після ремонту", оскільки серверне програмне забезпечення та бібліотеки зовсім не оновлюються з 2006 року. Я не повинен прибирати цей безлад , але мені потрібно довше кодувати через обмеження. (Уявіть, MySQl 5.2, MySQL 5.0). Я не можу нічого оновити, оскільки, ймовірно, існуючий код не працюватиме на новіших версіях через застарілий код.
roetnig

3
"Якщо він не зламався, не виправляйте." У мене 20-річний автомобіль, який просочує трохи масла. Варто витратити гроші на? Ні Надійна? Так.

3

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

Тоді вам потрібно буде переконатися, що покриття тесту є досить високим або справді високим (наскільки ви можете пройти без капітального рефакторингу). Якщо цього немає, я б працював над тим, щоб покриття було дійсно високим, навіть якщо ви не написали код. Це допомагає налагодити звіт, і ваша нова команда поставиться до вас серйозніше.

Після того, як ви покриєте ці основи, ніхто з їх розумного розуму не оскаржить вас. Як бонусний предмет, зробіть мікро-бенчмаркінг, і це дійсно додасть вашій справі.

Часто шлях, який ви промовляєте, проходить довгий шлях до зміни культури коду. Подавати приклад. Або ще краще, зачекайте, коли ви можете написати фрагмент коду, який ви можете написати - рефактор і блок випробування чорта з нього та віоли - вас почують.


Я не перефактуюю поточний код, я просто пишу нову функцію, не впевнений, чи слід я просто слідувати «умові» і кодувати її в монструозності 300+ рядків або розбивати її на логічні фрагменти, як я б зазвичай робив, але має не виконано в цій частині бази коду.
Джастін

1
чи є в них правила, щоб забезпечити написання нових методів у 300+ рядках? як ні, я б написав це правильно. але я б абсолютно пішов зі свого шляху, щоб переконатися, що я перевіряю їх, включаючи гілки. Я переживав подібний досвід, і зазвичай ти їх перемагаєш. хитрість полягає в тому, щоб зробити це з часом і створити стосунки.
skipy

3

Цей тип запитань, в основному, " будь ласка, читайте моїх товаришів по команді ". Випадкові люди в Інтернеті не можуть цього зробити, тому всі відповіді, які ви отримаєте, - це лише особисті думки людей про стиль кодування. Консенсус коротший, ніж кращі методи, але ви, здається, вже так думаєте, тому не потрібно повторювати це.

Отже, схоже, що поточна база коду використовує інший стиль кодування, ніж той, який ви віддаєте перевагу. Що тобі слід робити? Спочатку потрібно розібратися:

  1. Це обдумане дизайнерське рішення підтримує ваша нинішня команда?
  2. Вони хочуть, щоб ви слідували цьому стилю?

Є лише один спосіб дізнатися це. Запитайте .

Причин тривалих функцій може бути кілька. Це може бути тому, що команда вважає, що довгі функції кращі, ніж кілька коротких функцій. Це може бути і тому, що це застарілий код, і команда вважає за краще, щоб новий код відповідав більш чистому дизайну. Тож будь-який вибір може поставити вас у біду як розробника, якщо ви не поговорите з командою і не зрозумієте їх міркування.


1
Я повністю погоджуюсь і додаю: "Можливо, вас звільнять або іншим чином зазнаєте неприємностей, якщо не слідкуєте за тим, що зробили інші?" Тоді відповідь - так! Слідом за кожною поганою справою, компанія вимагає від вас цього і впоратися.
Роб

1

Існують різні рівні "стилю".

На одному рівні, як правило, частина умов кодування, це означає, куди слід розміщувати пробіли, порожні рядки, дужки та як називати речі (змішаний регістр, підкреслення тощо).

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

Потім є бібліотеки та рамки, якими користується проект.

Іноді буде обмеження розміру функції. Але рідко є мінімальний ліміт! Отже, ви повинні з’ясувати, які з цих речей є повноваженнями, які вважаєте важливими, і спробувати це поважати.

Вам потрібно з’ясувати, чи є команда несприятливою для рефакторингу існуючого коду, що слід робити незалежно від додавання нового коду, коли це можливо.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.