Наскільки важливо очистити чужий код, коли стикається з дотриманням строгого терміну? [зачинено]

(Я говорю про HTML / CSS-код (не мови програмування), але думаю, що ми також стикаємося з тією ж проблемою, що і з програмістами.)

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

Я стикаюся з 2 проблемами:

1. Їх стиль кодування - дещо безлад.
2. Естетика - це не добре.

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

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

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

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

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

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

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

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

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

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

Я вже казав це раніше і знову скажу, що "робочий код є більш цінним, ніж гарний код".

Якщо ви змінили код, велика ймовірність, що ви зміните його поведінку, якщо це перевірений код, то ви щойно визнали недійсними всі зусилля тестування, і вам доведеться повторити тести.

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

• Коротка відповідь: ні. Коли важкі часи, іноді потрібно просто опустити голову і взяти естетичну кулю. ;)

• Більш прагматична відповідь - це встановити термін. Отримайте бюджет на годину, щоб пройти та очистити один конкретний аспект коду. Потім перевірте це та зробіть справжню роботу. Але будьте чесні з собою щодо того, щоб стримати це.

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

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

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

Під час виправлення коду та терміну, я зазвичай використовую два правила:

Код жахливий, але можна знайти проблему в розумний час та виправити її

Я вирішую проблему, а решту залишаю недоторканою .

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

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

Прикордонний випадок:

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

У такому випадку код має бути виправлений, але лише тоді, коли потрібно впроваджувати нові функції, впродовж простою, ніколи в час виправлення помилок перед терміном!

Мені було б цікаво дізнатися, в який момент вашого процесу ви знаходите цю проблему?

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

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

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

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

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

Для поточної партії очистіть код згідно з документом S&P під час рефакторації коду, але лише тоді, коли ви рефактор.

Я досить недосвідчений в програмуванні. Однак, будучи студентом, я часто зобов’язуюся проводити експертну перевірку та партнерські стосунки з проектами. Якщо буде достатньо часу, щоб закінчити проект, я піду і зачищу код учасника команди для ясності та читабельності. Найчастіше мені буде важко навіть просіяти перші 100 рядків. У цих випадках я більше ніж готовий простягнути руку, щоб допомогти навчити колегу-програміста кращим звичкам та кодуванню. Якщо часу просто не вистачає, я просто копіюю / вставляю і працюю над своїми проектами у велику картину, що стосується їх поганих інтерфейсів. Згодом я обов'язково запропону безліч порад щодо техніки кодування. Що стосується експертної оцінки, то конструктивна критика (незалежно від того, наскільки небажана) приносить користь лише йому та їй та мені в довгостроковій перспективі.

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

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

• Парне програмування працює як суп-версія огляду коду для розуміння того, як розвиватись - це як різниця між читанням та вмінням, розповіданням та показом. Спостереження за розвитком коду та швидким обговоренням змін надзвичайно корисно для розуміння не лише того, як, а й чому рефакторингу та хорошого коду. На мій досвід, це швидше, ніж розвиватись поодинці, оскільки ідеї постійно кидаються навколо, що закінчується загальним результатом більш високої якості та кращим розумінням як коду, так і мислення іншої людини.
• Інструменти для зв'язування можуть підтвердити, що дотримується стиль кодування. Це вчить усіх, як форматувати код, і помилки повинні швидко випадати, як тільки розробники запам'ятають стандарт.
  • Зробіть цю частину процесу збирання, щоб переконатися, що вона виправлена ​​перед початком вчинення.
  • Використовуйте мовні шаблони, щоб переконатися, що ваш CSS, HTML, JavaScript та код на стороні сервера можна перевірити окремо.
• Інструменти перевірки можуть перевірити, чи згенерований результат є здоровим. Вони також повинні бути частиною процесу збирання.

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

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

Для ваших людей є багато переваг, які:

• вивчити кращий стиль
• дотримуйтесь кращих практик
• навчитися досліджувати, що вони роблять

І деякими вигодами для себе ви будете:

• ефективніше під час налагодження в останню хвилину (що завжди буде)
• визнана як експертом, так і лідером як вашої команди, так і керівництва

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

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

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

Технологічна заборгованість - це слово. Він повернеться колись, і хтось заплатить за це.

Тож ІМО, я думаю, ви просто правильно виправляєте зламану конструкцію, а професіоналізм (спеціально для юніорів) також означає, що ви мусите знати критику та як навчитися на цьому, навіть якщо це не ввічливо. Насправді більша частина життя все одно не ввічлива.

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

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

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

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

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

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

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

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

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

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

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

По-третє, безліч цінних наборів стандартизованих середовищ розробки з попередньо налаштованими інструментами. Для цього чудовий TS-сервер. У кожного є однакові точні інструменти (та версії), однакові конфігурації та однакові оновлення. Встановіть інструмент рефакторингу на зразок CodeRush або Resharper, попередньо налаштований на ваші стандарти, і доручіть програмістам, що ви будете відхиляти будь-які зобов’язання, які все ще мають попередження. Тепер ви можете скористатися часом перегляду коду вашої команди, щоб фактично покращити набір правил, на основі їх відгуків, і ваша команда із задоволенням виправить себе, не потребуючи постійно прибирати. Також програмісту набагато простіше взяти критику коду від правильно налаштованого інструменту, ніж від колеги чи начальника, коли стандарти можуть здатися довільно визначеними або неправильно зрозумілими. Якщо IDE повідомляє вам, що ваш код недбалий, ніхто не буде сперечатися з цим, і це буде виправлено. Ви побачите, що якість коду різко зросте, і команда в цілому витратить МНОГО менше часу на реконструкцію та очищення через кілька тижнів. Програмісти також звикнуть до правил і перестануть писати лайний код.

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

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

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