Як зробити крок назад і подивитися на код свіжими очима? [зачинено]

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

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

Як я виходжу поза головою та поза кодом, щоб я міг отримати свіжий вигляд та покращити його?

Способи наблизитись до цього:

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

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

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

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

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

Користувачі почнуть скаржитися. Тільки коли ти думаєш, що все чудово ...

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

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

Визначивши сфери, над якими потрібно працювати, спробуйте з’ясувати, у чому полягає насправді проблема. Є книги, які систематично підходять до категоризації проблем дизайну. Подивіться на " Рефакторинг" Мартіна Фаулера, стандарти кодування Herb Sutter , " Чистий код" Роберта Мартіна тощо. Вони мають купу "правил", які дозволяють об’єктивно поглянути на ваш код.

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

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

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

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

1.) Точка зору користувача / замовника - використовуйте зворотний зв'язок

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

2.) Зробіть функціональний аналіз свого коду та візуалізуйте його

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

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

3.) Використовуйте загальні підходи до забезпечення якості

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

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

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

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

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

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

Не потійте дрібні речі.

Кожен міг краще кодувати. Ми робимо все швидко, а потім через кілька тижнів усвідомлюємо, що це можна було зробити ефективніше. Справа в тому, що 90% вашого коду, мабуть, досить хороші.

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

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

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

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

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

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

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

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

"Це менше питання, ніж я думаю, що це, або це проблема, яку відчувають і інші?"

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

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

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

Окрім інших відповідей, рекомендую перейти на конференцію розробників.

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

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

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

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

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

• Реалізуйте код таким чином, що все, що потрібно додатку, можна налаштувати та підтримувати

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

Я вважаю, що допомога "пішки навколо" з кількома розумними людьми допомагає. Потрібна конкретна інформація. Це веб-сайт 24x7x365? Додаток LoB? Де він працює чи розміщується?

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