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

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

Забороняється підтримувати код.

1. Кожен раз, коли мені доводиться налагоджувати тисячу рядків погано написаного методу зі змінними, використані повторно, я повністю втрачаю.
2. Деякі зміни або рефакторинг я вносив помилки в інших місцях програми.
3. Відсутність будь-якої документації, тестів або архітектури, що спостерігається, і поєднана з погано названими методами, я відчуваю, що я заповнюю всю свою наявну робочу пам'ять. Не залишилося місця для всіх інших речей, які я повинен запам'ятати, щоб зрозуміти код, який я повинен змінити.
4. Постійні перебої на робочому місці мене турбують і сповільнюють.
5. Я не можу запам'ятати більше двох-трьох завдань одночасно без системи відстеження помилок, і я забуду їх усіх у вихідні.

Мої колеги, схоже, не мають подібних проблем.

1. Їм вдається налагодити погано написані методи набагато швидше, ніж я.
2. Вони вводять менше помилок, ніж я, коли змінюють базу коду.
3. Вони, здається, добре пам’ятають все, що потрібно для того, щоб змінити код, навіть коли для цього потрібно прочитати тисячі рядків коду у двадцяти різних файлах.
4. Їх, схоже, не турбують електронні листи, дзвінки телефонів, люди, які розмовляють навколо, та інші люди, що задають їм питання.
5. Вони не хочуть використовувати систему відстеження помилок, яку ми вже маємо, оскільки ми використовуємо TFS. Вони вважають за краще просто запам'ятати кожне завдання, яке вони повинні виконати.

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

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

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

Просто потрібен час для адаптації до бази коду, наприклад, тієї, яку ви описуєте. У ваших колег, напевно, було набагато більше часу, щоб перерости в це, і, можливо, вони взяли участь у конвенціях, зразках та конструкціях, які не вискакують на «початківців базі коду». Хаосу може бути більше структури, ніж ви можете собі уявити. Поговоріть з колегами, попросіть їх паруватись з вами деякий час і виберіть їх мізки про те, як вони підходять до вирішення одного з помилок, призначеного вам. Коли вони просять вас відкрити блок X, Y або Z, запитайте їх, чому саме той, про що він говорить їм, що це може бути доречно і т.д.

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

Рефакторинг без запобіжних мереж одиниць тестів - це відстріл себе в ногу. Не варто. Просто ні.

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

я бачу 3 основні моменти:

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

для пункту 4 протистояти перебоям, не дозволяйте невідкладним справам виводити вас із зони , для того, щоб повернутися в неї після перерви, потрібно тривалий час; встановіть чат компанії зайнятим, спробуйте запланувати в довгих блоках (повний післяобідній час) просто кодування

для пункту 5 секунди створіть аркуш "excel" із помилками, над якими ви зараз працюєте, як ваш особистий список todo (або використовуйте можливості управління завданнями у вашому IDE), я готовий зробити ставку на те, що деякі ваші колеги роблять те саме

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

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

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

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

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

5. Якщо мати на увазі дві-три помилки, це не погано, краще було б три-чотири, але замість того, щоб намагатися покращити це, відмовтесь і запишіть це. Папірець, дошка, tfs, excel, слово чи блокнот - просто запишіть його. Гадаю, що так роблять ваші колеги. Або це, або виправлення речей навмання.

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

CAVEAT / ОНОВЛЕННЯ: Прочитавши відповідь нижче, я відчув, що це може бути занадто суворо. Не мій намір, оточення, яке ви описуєте, жахливе, і воно зачіпає більшість людей (напевно, навіть кращі програмісти це страждають, але вони "кращі" порівнянням з іншими в тому ж середовищі). Моя відповідь - це лише покрокове відображення у ваших питаннях, припускаючи, що оточення не зміниться (навіть якщо це повинно бути).

Цілком прийнятна відповідь:

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

2) Це те саме, що число 1, але з використанням іншої метрики. Та сама відповідь.

3) блокнот і ручка. Або документ word / excel. Не так важко вирішити.

4) це особисте питання концентрації. Не впевнений, чи здатний сам покращити його.

5) використовувати систему квитків або не слід визначати не програмісти, а керівник проекту. Запитайте його думку / презентуйте свої моменти. Якщо він проти, блокнот і ручка знову.

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

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

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

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