Після написання коду, чому я відчуваю, що «я б написав краще» через деякий час? [зачинено]

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

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

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

Це загальне почуття для багатьох людей? Чи є ця мова специфічними явищами? (Тому що в C ++ можна писати одне й те саме по-різному).

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

Це явище дуже поширене і не характерне для програмістів. Щоразу, коли ви виконуєте інтелектуальне завдання, ви помітите десятки місць, де можна було б удосконалитися - після того, як пройдете деяку відстань. Запитайте будь-якого мудрого () людини WO - хто коли - небудь писав дисертацію, і вони скажуть вам одне: «Не дивіться на нього Ви будете знайти помилку на перший погляд.»

В основному є дві речі, щоб уникнути циклу рефакторингу:

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

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

Єдине, що ви можете передбачити щодо виробничого коду в реальному світі, це те, що ВИНАГО зміняться. Не намагайтеся вгадати, як це зміниться, які нові методи ви навчитесь завтра. Словом, не намагайтеся зробити свій код "ідеальним". Просто зробіть це так добре, як ви можете, з вашими нинішніми знаннями. Також переконайтеся, що ваш код ретельно перевірений та розширюваний.

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

Підсумовуючи це, це звичайне відчуття в моєму досвіді, але воно не є негативним.

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

Це загальне почуття для багатьох людей? Чи є ця мова специфічними явищами?

Це означає, що ви розширюєте свої знання та погляди.

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

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

Коли ви проходили курс програмування, ви дізналися про If-then-else, який робив багато речей, поки ви не дізналися про комутатори. Коли ви дізнаєтесь щось нове, ви проходите цей прогрес, все роблять.

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

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

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

Якщо у вас немає цього почуття, це означає одну з двох речей:

1. Ви все ще на тому ж рівні майстерності.
2. Ваш код уже ідеальний (навряд чи).