Як я (тактовно) скажу своєму керівнику проекту або провідному розробнику, що кодова база проекту потребує серйозної роботи?

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

Проект (внутрішня лінія бізнес-додатків середнього та великого розміру ASP.NET WebForms), через відсутність більш описового терміна, - катастрофа. Існує три негайно помітні проблеми зі стандартами кодування:

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

Щодо пункту 3, можливо, це мене більше турбує, тому що я взяв час, щоб отримати свій MCPD з акцентом на веб-додатки (зокрема, ASP.NET). Я також єдиний сертифікований професіонал Microsoft у своїй команді. Через те, що я навчився в усьому моєму навчанні, самонавчанні та навчанні на роботі (включаючи мою підготовку до іспитів на сертифікацію), я також помітив декілька примірників у коді проекту, коли речі просто не робляться в Кращий спосіб.

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

Чи повинен я (і якщо так, то як я) запропонувати керівнику проекту та команді вести, що проект потребує капітального оновлення?

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

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

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

Редагуйте також ознайомтеся з ефективними роботами за допомогою Legacy Code

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

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

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

Однозначно не махайте своїм MCSD навколо, люди просто будуть насміхатися над вами цілком відверто, MS certs приємно мати, але вони аж ніяк не є професійною кваліфікацією!

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

Зачекайте, поки ви отримаєте грунт землі, перш ніж збивати код команд.

Ви можете подумати, що проблема у вас. НІКОЛИ з трьох згаданих вами речей не варте повного перегляду програми. Вони - просто нерозумні деталі.

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

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

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

Ці речі добре турбуватись, але якщо ви новачок у команді, ще не качайте човен, поки ви не набудете з ними певної довіри.

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

• Чи добре задокументований код?
• Чи дотримується код специфікацій / дизайнерських документів?
• Чи працює код?
• Чи легко зрозуміти, що робить код?
• Ви розглядаєте можливість подання великих фрагментів цієї бази коду до TheDailyWTF?

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

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

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

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

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

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

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

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

Хоча я можу оцінити бажання виправити незадовільну базу коду, це потрібно зважити, щоб з точки зору бізнесу це мало сенс робити.

Наразі ви не в змозі запобігти поганому коду, тому вам доведеться з'ясувати, як його містити.

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

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

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

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

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

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

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

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

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

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

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

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

Не переходьте безпосередньо до управління з цією «проблемою».

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

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

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

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

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