NOTE: Apart from
(and even then it's questionable, I'm Scottish). These are machine translated in languages I don't read. If they're terrible please contact me.
You can see how this translation was done in this article.
Wednesday, 06 November 2024
//Less than a minute
Як розробник вільного програмування, одним з наборів навичок, які вам потрібно вивчити швидко, є спосіб ефективної роботи з існуючою базою коду. Мені пощастило, що я створив купу з - сракових систем; це JOY як досвідчений розробник, але це не завжди так.
Спадкові системи мають значні проблеми. Особливо, якщо ключові розробники / архітектори (якщо вам пощастило їх отримати) пішли далі.
Часто про це не звертають уваги, особливо в менших компаніях. Загалом кажучи, вам слід встановити 4 типи документації:
Документація - це одна з речей, яку ми, як розробники, часто ненавидимо (це не код), але це важливо. Як бачите, я ЛЮБОВ Markdown, з такими, як Мерміль і Плант UML, ви можете створити дуже гарні діаграми і блок-карти, які можна включити до вашої документації.
Це має бути CURRENT; розробники часто говорять про біт- рот; там залежності проекту стають застарілими або зовсім зовсім ризикованими для безпеки. Це також стосується документації; якщо вона не є поточною, вона не корисна.
Є різні рівні документації, але загалом кожного разу, коли ви змінюєте код, на який посилається документ, вам слід оновити цей документ.
Це часто нелегко, особливо якщо система існує якийсь час. Вам слід знати, яка версія вузла /.NET тощо, яка версія бази даних, яка версія основи тощо. Часто на це не звертають уваги, але КРУЦІЙ - це для того, щоб швидко встати і бігти.
Я часто бачив, як розробники казали, що це не має значення в ці дні хмарних систем і великих програм, але я не погоджуюсь з цим; ви повинні вміти керувати системою локально, щоб знеохочувати проблеми швидко і ефективно.
Response.Write У класичній аспіранції все скінчено. Для навіть скромної складної програми (особливо тих, які ви не писали) вона має вирішальне значення для "пройти крізь" код. Щоб прослідкувати за просьбою від її започаткування за допомогою служби, щоб визначити, що відбувається, які винятки можуть бути не спіймані і т. д.LogInformation на кожне прохання. Можливо, вам слід скористатися нетиповим Процесором телеметрії, щоб відфільтрувати запити, які ви не хочете записувати.У КОЖНОМУ проекті я працюю над першим кроком, щоб система (або його велика частина) працювала в місцевому місці. Подивившись на код, запустивши код, усування вад, ви зможете отримати уявлення про те, як працює система.
У кожній системі це ваш джерело правди, байдуже, що лікар каже, те, що інші кажуть вам про те, як він повинен працювати це є спосіб, яким він працює.
Це часто складно, це те саме, що знайти дорогу в новому місті без картотеки. На щастя, у програмах ви маєте точку запису (сторінка завантажує / передній виклик API тощо) обрати точку і почати з неї.
Використовуйте все необхідне, щоб взаємодіяти з ним, чи то PostMan, чи Їздець HtpClient, чи навіть веб-сторінка. Гачок у вашому зневаднику, зробіть виклик і слідкуйте за ним. Висипляйте і повторюйте для кожної частини системи.
В обычном случае, ты не можешь разорвать СИСТЕМ. Це ALWYS спокусливо "викинути його і почати знову, незважаючи на цю спокусу. Особливо для запущеної системи ВОНА ДІЄ Відновлення / навіть реорганізація системи - це ризик HUGE. Так, це FUN, але кожен рядок коду, який ви змінюєте, ризикує впровадити нові захоплюючі вади.
Подібно до всього іншого (особливо під час контракту) тобі потрібно виправдовувати роботу, яку ти виконуєш у системі. Або на одне з таких оправдань треба звернути увагу:
Часто ми забуваємо про це, особливо про розробників. Ви повинні мати можливість виправдати роботу, яку ви виконуєте у системі. Особливо це стосується системи контракту, де вам платять за годину. В конце концов, это не твой код, а не твои деньги. ЧОМУ ви робите зміни часто є важніше від самої зміни.
Я працюю підрядчиком вже більше десяти років, це не EASY; як підрядчик кожної години ваш час є "вартою" для клієнта. Вам слід додати до системи рухове значення, ніж вам потрібно. Якщо ні, то швидко шукатимеш новий контракт.
Як розробники, ми схильні бути паршивими діловими людьми, яких ми зосереджуємо на "досконалості" на кожному кроці. Насправді, вам не потрібно робити систему "досконалою" (я б сказав, що такої речі немає); вам просто потрібно доставити цінність клієнтові.
При довшому терміні, це заохочення, яке забезпечує будь-кого. новий Код можна підтримувати, а вартість - ефективна для запуску. У спадкових системах це дуже важливо. Часто вам доводиться прогулюватися болотистим болотистим дном, занепокоєні тим, що, дізнавшись про цю систему, ви не можете нічого зробити. I'm not making any changes ви думаєте I'm just learning the system.
Це помилка; ви вчите систему, щоб зробити її кращою. Ви вчите систему, щоб зробити її більш ефективною. Ви вчите систему, щоб зробити її більш стійкою. Якщо клієнт не може прийняти цей крок, вам слід бути дуже обережним щодо того, як ви спілкуєтеся з цим (або шукаєте новий контракт).
Знову ж таки, ви часто не звертаєте уваги на те, що багато часу у вас, як підрядчика, тому що якась ключова людина пішла (не втручайтеся в політику цього; це не ваша справа). Потрібно вміти працювати з людьми, які є там, щоб досягти цілей проекту. У контракті ви, як правило, маєте терміни вашого заручення (у моєму поточному контракті це "здобути надійність і зменшити пропускні витрати"); зосередити увагу на цьому. Якщо ви не впевнені, що це означає, то підпишіться.
Пам'ятайте, хто ваш прямий контакт, особливо в перші кілька місяців. Тримайте їх в курсі (очевидно, у вас не буде нових рис, щоб хвалитися, коли ви дізнаєтеся, як працює система). Зазвичай, я відсилаю електронну пошту щотижня або два тижні моєму безпосередньому контакту; це добрий спосіб інформувати їх про те, що ви робите і що знаходите.
Пам'ятайте, що це та людина, яка схвалить ваш рахунок; не повинно бути сюрпризів на рахунку. Після того, як ви регулярно перевіряєте в кодах, це менше питання; у вас є запис про те, що ви зробили і який вплив це мало. А до того часу треба тримати їх у курсі. Они должны знать, что ты сделал и почему они должны платить тебе за это.
Знову ж таки, назад до застарілого коду; якщо ви зміните в загальному, вам слід його втілювати. Навіть найкращі з нас час від часу висміюють це, особливо у застарілих кодових системах, це має бути щось. ти не міг знати. Когда будешь раскрываться. За допомогою цього пункту можна повернутися до журналу, - якщо на вашому сервері встановлено можливість ведення журналу LOT (але цей сервер зберігається на короткий час), ви зможете отримати докладніші відомості щодо помилки.
Независимо от того, насколько ты хорош, как много местного тестирования ты сделал, мы все люди. Це ключова частина правила "не втілюватися в п'ятницю," очікуючи появи нового питання на системі. Будьте готові працювати, поки це не буде вирішено. Якщо ви не знаєте, чому він зазнав невдачі, додайте більше тестів, щоб відтворити цю проблему, і більше лісозаготівель, щоб у майбутньому ви могли помітити подібні проблеми.
Особливо для виробничих систем ваша система блокування може не бути 1: 1 (особливо, якщо потрібно завантажити), інструмент на зразок к6 може допомогти вам імітувати завантаження (навіть краще локально, якщо ви можете виконати правильне профілювання, про яке ми вже згадували раніше).
Знову ж таки, причиною цього часто є недооцінення в галузі комп'ютерного та комп'ютерного програмного забезпечення. Простіше простого; ти будеш трахатися. Дуже швидкий і ефективний спосіб виявлення системи означає, що, коли ви зробите перерву, ви зможете виправити її швидше. Якщо ваша система рецензування коду означає, що потрібно 2 дні, щоб отримати PR об'єднану, то це найшвидший варіант, який можна максимально запустити у системі. Якщо ваша система КД означає, що ви знешкоджуєте систему, звикайте до довгих ночей.
Ефективний механізм фіксації і розгортання коду є необхідним для ефективного трубопроводу для розвитку. Якщо потрібно більше часу, щоб розробити фіксацію, ніж потрібно, щоб знайти і реалізувати те, що фіксується в коді, тоді ви менш ймовірно, що ви все полагодите.
Я записую це в лапках, як це питання; для застарілих застосувань (особливо, коли великі зміни є поза межами) є два основних підходи.
Це процес простого виправлення існуючого коду. Знову ж таки, переконайтеся, що ви ретельно перевірили всі процеси, які мають призначення для скасування або пришвидшення виправлення будь- яких виправлень. Я не буду брехати, що такий тип розвитку рідко коли виникає, оскільки ви все ще, ймовірно, проходите через болотище існуючої кодової бази. Проте, у багатьох випадках це є потрібне зло.
Як завжди, вам слід переконатися, що у вас є якісь FORM тесту, щоб виділити поточний код; ідеали також повинні перевіряти на провал за питання, яке ви намагаєтеся вирішити, перш ніж зробити виправлення . Вони мають IDYL для цього, щоб мати одиничний тест, який тісно цікавиться площею коду, яку вам потрібно виправити, але це часто поза межами роботи для великих, розподілених систем.
Зазвичай я використовую систему тестів у такому порядку пріоритетів:
Для того, щоб ви могли оновити частину системи, ви можете визначити компоненти, які можна розділити з існуючого моноліту на мікрослужбу (для певної якості " мікро "). Це може стати чудовим способом почати модернізацію системи без ризику повної переробки. Звичайні приклади можуть розділяти кінцеві точки API на нові проекти, які використовують більш оновлені елементи. Але тут може з'явитися страх ДРІ. Погане структуроване рішення часто має багато компонентів " помічник " або " сервіс," які мають бути в різних проектах (або навіть у пакунках nuget для більш глобального використання).
Я розповім про цей підхід далі в наступній статті, оскільки він є ключовим елементом того, як я працюю над застарілими системами, і це не так вже й очевидно для багатьох розробників.
Тепер, коли ми маємо все це для того, щоб розв'язати проблему сплати. У мене загальне правило:
Будь-яка платіжна проблема, яка мені потрібна.
Якщо вони запізнюються, залежить від вашого контракту, але на LEAST через 30 днів, але загалом ближче до 7; це поганий знак. Якщо у вас є бляшанки на рахунку, подумайте про те, чи зможе компанія платити за ваші послуги на постійній основі.
Не переймайся цим; якщо ти зробив свою роботу, тобі потрібно вчасно заплатити. Не має значення, наскільки вам це подобається; якщо поганий клієнт може використати вас. Это никогда не стоит этого.
Будьте чесні; займайте тільки час, який ви працювали; переконайтесь, що це ясно, що ви зробили і чому ви це зробили.
Я очолив команди розробників і я був розробником; я був підрядчиком і був клієнтом. Я бачив всі сторони цього і я можу сказати вам, якщо вам не платять вчасно, то вам треба йти далі. З іншого боку, якщо у вас є підрядчик (або FTE), який не доставляє, тоді вам потрібно негайно звернутися до цього. Кожен особисто бореться, але особливо в умовах контракту, ви повинні доставляти цінності або не платити за час, коли ви цього не зробите.
Що стосується швидкості; ви знайдете ваш рівень; особисто я стягаю більше грошей на проекти, де я маю більшу відповідальність (або яка не виглядає весело). Я заряджаю менше за проекти, де вивчаю нову технологію або стартапи. Я також менше працював, але моя ставка була стабільною. Але не погоджуйтесь на низьку ставку; ви професіонал і вам слід заплатити ось так.
Ну ось і все. Я сьогодні не працюю, а завтра на похороні моєї бабці, і щиро панікую трохи, що мені потрібно вивчити застарілу систему HUGE, тому я подумав, що виплюну свої думки про те, що працює над цими системами, це виклик.