Як би ви відреагували, якби хтось сказав, що ваш код - безлад?

Я хороший програміст, або так я думав раніше. Я завжди люблю програмувати. І я хочу дізнатися багато речей про програмування, щоб зробити мене кращим програмістом. Я навчався програмуванню 1 рік, і зараз працюю програмістом майже 2 роки. Отже, коротко, у мене майже 3 роки досвіду програмування.

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

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

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

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

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

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

Прочитайте http://www.perlmonks.org/?node_id=270083, якщо ви не знаєте, про що я говорю.

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

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

Відмова від відповідальності: нічого з цього не слід читати як "поганий код нормально".

Код усіх - безлад, і хороших програмістів немає.

Існує:

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

Вони навряд чи, якщо і колись, опиняться тим самим людиною.

І є програми, які хочуть виростити:

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

Це не мистецтво, це ремесло.
Ми даємо вам зрозуміло, що ви розумні: ви програмуєте комп’ютери, боже.
Все-таки AMD64і x86не вимушені силою вашої прози. Зробити все просто.

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

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

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

Чи переходили ви про деякі старіші частини написаного вами коду? Напевно, ви можете бачити речі, які зараз хочете зробити по-іншому, або рефактор.

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

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

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

Але здається, що я не геніальний програміст, як у фільмах.

Не впевнений, які фільми ви дивитесь, але 90% програмістів у фільмах настільки фальшиві, що до кінця послідовності у мене сльози.

Чи можете ви дати мені поради, як бути кращим?

Читайте та практикуйте. Перевірте такі книги, як Code Complete або Прагматичний програміст . Подивіться на Amazon подібні книги.

Ви коли-небудь відчували щось, що критикує ваш код, і ви відчуваєте себе справді боляче? Що ти робиш на тих заходах ..

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

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

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

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

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

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

Вони зобов'язані відповісти вам, і ви зможете:

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

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

Our team is composed of 5 programmers, and 4 of us are new

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

Для швидкого огляду деяких досить стандартних рекомендацій щодо кодування, Стандарти розробників спільноти Linux повинні дати вам уявлення про рівень відповідальності, до якого слід прагнути свого продукту. Зверніться до ПОЛУЧЕННЯ КОДУ ПРАВА.

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

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

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

I feel so sad and hurt. 

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

Ви відповіли на свою проблему ... Не тестуйте!

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

У цьому лежить руб

"Ми розгорнули нашу програму в програмі без ретельного тестування."

Cribbing UML Creator Grady Booch ...

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

Alistair Cockburn надає на своєму сайті багато інформації про використання спритних методологій для підвищення продуктивності та якості для вас та вашої команди.

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

Зовнішнє ... Твоє добре - просто не скуголить. Просувайтесь вперед у розвитку свого ремесла і нехай ваша пристрасть до програмування продовжує продовжувати свою діяльність. Щасти :-)

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

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

Ваш код - це не ви. Пам'ятайте, що.

Я буду тут хуй і раджу на основі .. ну, очевидний. Очевидно, ваш код - це безлад або питання, яке ви задаєте: "ЧОМУ хтось каже, що мій код - безлад?" Але ви не оскаржуєте це припущення. Ти просто болиш і, відверто кажучи, може плакати, але немає почуття, коли йдеться про виправдання програмування.

Але насправді, чому ви питаєте? Ви знаєте, що ваш код відстійний або вам зададуть інше питання. Якби хтось сказав мені, що мій бек-код веб-коду застряг, я б сміявся і сказав "гаразд, що з цим погано?" Якби вони сказали мені мій JavaScript, я б дав їм соціальний програміст, еквівалент жирної губи, і я ніколи не прошу поради, як реагувати, тому що маленькі сучки явно! @ # $ Ing неправильно.

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

Пам'ятайте це: найгірший код, який ви коли-небудь побачите, це ваш власний!

Джефф Етвуд із codinghorror.com написав багато про цю тему, ви можете почати тут: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Якщо ви хочете вдосконалитись, починайте читати матеріали про стиль кодування, шаблони, робочі процеси, в основному все, що можна отримати на пальцях. Також вивчіть більше мов програмування, подивіться, як вони працюють. Якщо ви робите OOP, прочитайте це: http://en.wikipedia.org/wiki/Design_Patterns

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

Припуститися помилок неминуче, повторювати їх є.

Більшу частину часу ви повинні сказати "Спасибі" тому, хто вам це сказав.

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

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

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

Спробуйте подивитися код, який ви написали на початку своєї кар'єри. Як це тобі зараз схоже? Це виглядає так добре, як ви думали, що це робилося, коли ви це писали;)

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

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

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

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

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

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

Чи можете ви дати мені поради, як бути кращим?

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

Минуле:

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

Присутні:

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

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

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

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

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

Це зміна культури, яку ви не можете змусити самостійно, але ви можете допомогти просунути речі в правильному напрямку!

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

Чи можете ви дати мені поради, як бути кращим? Ви коли-небудь відчували щось, що критикує ваш код, і ви відчуваєте себе справді боляче? Що ти робиш на тих подіях.

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

How to be better? 

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

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

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

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

Чи можете ви навести конкретні приклади того, що було названо "безлад"?

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

Будова

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

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

Стиль

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

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

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

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

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

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

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

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

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

1. Визначте характер порушених питань і що вам слід з цього навчитися

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

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

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

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

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

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

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

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

Я пережив цю ситуацію і можу зрозуміти.

TL; DR

Як би ви відреагували, якби хтось сказав, що ваш код - безлад?

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

• Старий хороший експертний огляд. Попросіть різних екіпажів з різними колективними менталітетами, рівнем досвіду та / або рівнем агресивності переглянути свій код.
• Просто для того, щоб трохи детальніше розібратися, що я маю на увазі під "різними" групами однолітків: діаспора StackExchange - це, мабуть, найбільш згуртована, професійна та найцікавіша група через відносні труднощі стати її частиною порівняно з, скажімо, Reddit. Reddit, як правило, є дуже агресивним у більш популярних субредітдітах, але як не дивно, програмування subreddits є досить доброзичливими (з того, що я відчував).

Хороший, мабуть, найкращий приклад агресивного, гангста-типового менталітету - це натовп Форумів XDK, а найгірший з найгірших трофеїв я передаю CyanogenMod для форумів Android / IRC-каналу.

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