Як слід описати процес вивчення чужого коду? (У ситуації виставлення рахунків.) [Закрито]

Редагувати: Джастін Кейв добре підкреслив, що такий тип спілкування повинен бути передовим у моїх цитуваннях / оцінках. Це такий випадок, мені все одно цікаво дізнатись, якою мовою користуються люди для опису діяльності "існуючого вивчення коду". Особливо компанії, яка раніше не займалася підрядниками програмного забезпечення. Закінчити редагування

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

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

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

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

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

Чи існує стандартний спосіб опису такого виду діяльності при оплаті за роботу?

Я б виставив рахунки за такі завдання, як "Перегляд існуючої функціональності" та / або "Перегляд існуючого коду". Залежно від складності нових функцій, я б додав завдання "Дизайн xxx", який би включав час, який я витрачаю на з'ясування точок інтеграції в існуючий код.

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

Діагностика проблем.

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

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

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

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

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

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

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

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

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

Виправлення помилки: аналіз першопричини.

Нова функція: аналіз, проектування, інтеграція та тестування.

Представляємо нові помилки: безпека роботи. :)

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

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

• Planning Phase

• Intervention Planning

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

• Тоді, можливо, ... Solution Planning

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

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

Мій механік надсилає мені рахунок "Замініть масло, іскри плюс, перевірити фільтри, обертання шин. Виправлення брязкальця двигуна, тест на дорозі .....

Запчастини (деталізовані),

Праця x @ $ y / година = z)

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