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


26

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

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

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

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


2
Чи можете ви пояснити, що це за "лабіринтні залежності, що пов'язують різні артефакти"? Чи будують вони залежності, які можна було б вирішити за допомогою інструменту збирання типу Maven? Чи є вони вхідними залежностями, де один із цих артефактів залежить від певного входу, який не є очевидним чи зрозумілим? Чи є вони ключовими залежностями між таблицями баз даних?
FrustratedWithFormsDesigner

Система PLSQL, Unix bash, OWB тощо, тому існують всілякі залежності. Іноді потрібні дані певного формату, в певному місці, в певний час, певним модулем, але це далеко не очевидно від коду і можна виявити лише двома способами: пройшовши гору коду, зайнявши, можливо, дні, щоб дізнатися, що деякі дані мали розмежувальну крапку в частині системи, про яку ви навіть не знали, що вона посилається, оскільки вона була похована в 10 шарах рекурсивно названого коду або запитуючи когось, усі час, кожен раз. Це не сприяє незалежності.
Christs_Chin

4
Буквально всі вони
Miles Rout

3
Маленька дотична: Оскільки Haskell лінивий, ви фактично не вказуєте порядок операцій, коли пишете код. Ви вказуєте лише залежності. Функція C залежить від результатів функцій A і B. Отже, A і B потрібно запускати перед C, але вона може працювати однаково добре, якщо A запускається першим, або якщо B виконується першим. Я просто думав, що це цікаво.
GlenPeterson

1
Є книга під назвою «Шаблони дизайну» (книга смокче, але більшість того, що там сказано, добре, крім частини одинакових). Він має кілька розділів щодо управління залежностями.
ctrl-alt-delor

Відповіді:


19

Відкриття

Його відсутність нападає на багато організацій. Де той інструмент, який Фред знову побудував? У сховищі Git, звичайно. Де?

Модель програмного забезпечення, що спадає на думку, є Model-View-ViewModel. Для непосвячених ця закономірність є повною таємницею. Я пояснив це своїй дружині як "п’ять віджетів, що плавають над столом, розмовляючи один з одним через якусь таємничу силу". Зрозумійте схему, і ви розумієте програмне забезпечення.

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

Це обов'язок команди створити обґрунтовану організаційну архітектуру та задокументувати її. Сюди входять такі речі, як

  • Організація папок
  • Посилання на проект
  • Документація по класу (що це таке, що вона робить, чому вона існує, як вона використовується)
  • Проект, модуль, збірка, будь-яка документація.

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

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


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

1
Де той інструмент, який Фред знову побудував? У сховищі Git, звичайно. Де? - Саме так! Шаблон MVC занадто специфічний для передового розвитку (я думаю), і шаблони корисні лише в тому випадку, якщо всі в команді їх знають, так що це просто пересуває проблему від залежностей, не очевидних, до них очевидним, якщо кожен знає, як знайти їх. Але проблема передбачає, що це не так. Як такий, я сподіваюся, що є щось, що сприяє дійсно очевидному способу пояснення залежностей, що не потребує використання інших вивчених концептуальних рамок.
Christs_Chin

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

5
@RobertHarvey: Чув зовсім недавно: "Ми пишемо код, який не потребує документації". Неправильно. Ви пишете код без документації.
gnasher729

3
Деякі хороші речі тут. Примітка: існує різниця між написанням коду, який не потребує коментарів, та написанням супровідної документації.
Роббі Ді

10

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

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

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


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

1
Чудові речі. Мої труди часто були менш важкими для кількох старанних душ, у яких є можливість додавати інструмент / віджет тут і там, щоб створити порядок із хаосу. Хоча я не прихильник шахрайства та доробку документації, добре написаний шпаргалка чи список загострених кулею списків / особливостей може значно допомогти.
Роббі Ді

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

2

Архітектура.

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

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

В ідеалі ці правила уніфіковані особливістю розуму.

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

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

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


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

Я думаю, що ваш пункт у цій відповіді - це найбільший спосіб боротьби / запобігання типу речі, про яку йдеться в ОП. Це стосується навіть успадкування безладу, як це має ОП.
GWR

1

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

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

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

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

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


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

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

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

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

2
Точно мій досвід: ви повинні дати членам вашої команди зрозуміти, що вони роблять. Я бачу людей, що змішують MVVM і MVC, інші використовують елементи керування WPF таким чином, як це було нормально для Windows Forms (а точніше: VB6), люди, які програмують на C # без основного розуміння орієнтації на об'єкти ... Навчіть їх. Навчіть їх знову. Будьте розчаровані. Навчіть їх знову, ... Часто думаючи відмовитись. І вчити їх знову ...
Бернхард Хіллер

1

Мені подобається @ RobertHarvey ідея конвенцій і думаю, що вони допомагають. Мені також подобається ідея @ KarlBielefeldt "документувати, як ти йдеш", і знаю, що це важливо, тому що це єдиний спосіб підтримувати актуальну документацію. Але я думаю, що ідея надмірного архівування полягає в тому, що документувати, як знайти всі фрагменти коду, створити та розгорнути їх, важливо!

Нещодавно я надіслав електронний лист про важливий проект з відкритим кодом, який мав деяку конфігурацію XML, що генерував код, був повністю недокументований. Я запитав у обслуговуючого персоналу: "Де задокументований цей процес генерації коду XML? Де документально налаштовано налаштування тестової бази даних?" і він сказав: "Це не так". Це в основному проект з одноразовим внеском, і тепер я знаю, чому.

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

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

У висновку

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


2
Я підозрюю, що частина культурної проблеми полягає у прихильній вірі, що "якщо вона не є частиною Історії користувачів (тобто вона не сприяє безпосередньо цінності зацікавлених сторін), це не важливо". Хогваш. Тут пов'язана розмова: По-спритному, як плануються та розподіляються основні інфраструктурні завдання на початку проекту?
Роберт Харві

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

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

1
@Christs_Chin Стільки спілкування базується на контексті. Без цього контексту більшість комунікацій майже безглузді. Я відчуваю твій біль. Але я думаю, що важко написати (англійською), щоб інші могли вас зрозуміти. Іноді ранні специфікації для системи мають той контекст, який потрібно зрозуміти, навіть якщо вони жахливо застаріли, контекст зазвичай допомагає.
GlenPeterson

1

Щоб відповісти на поставлене запитання (замість того, щоб давати вам поради для вашої конкретної ситуації):

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


0

Кожен сховище даних є різним, але можна багато зробити, щоб полегшити для себе речі.

Для початку кожен рядок у базі даних мав стовпець DATE_ADDED та DATA_UPDATED, щоб ми могли бачити, коли він був доданий до бази даних та коли він був змінений. У нас також був стовпець SOURCE_CODE, щоб ми могли відслідковувати, де кожен біт даних вводився в систему.

Далі у нас були спільні інструменти, які поширювались на всі наші сховища даних, такі як сорти, настільні сірники, фрези та димери тощо.

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

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

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


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

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

0

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

  • Уникайте глобальних змінних, використовуйте замість них параметри. Це стосується і мовних розмов.
  • Уникайте змін / мутування значень змінних, наскільки це можливо. Створіть нову змінну та використовуйте, коли потрібно змінити значення, якщо це можливо.
  • Зробіть код модульним. Якщо неможливо описати, що (а не як) частина насправді робить у простому реченні, розбийте її на модулі, які задовольняють умові.
  • Назвіть належним чином свої частини коду. Коли ви можете фактично описати, що робить частина коду простими словами, ці терміни стають назвою частини. Таким чином, код стає самодокументованим через назви модулів / класів / функцій / процедур / методів тощо.
  • Перевірте свій код. Перевірте, чи юридичні особи у вашому коді виправдовують свої назви, про які йшлося у попередньому пункті.
  • Журнал подій у коді. Принаймні підтримуйте два рівні журналу. По-перше, це завжди ввімкнено (навіть у виробництві) і реєструє лише критичні події. І використовуйте інший, щоб входити в систему в основному все, але його можна вмикати або вимикати.
  • Знайдіть і використовуйте підходящі інструменти для перегляду, підтримки та розвитку вашої кодової бази. Навіть проста опція "Пошук у всьому" в коді Visual Studio полегшила моє життя в певних випадках.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.