Допомагати тому, хто не є і ніколи не буде професійним програмістом написати код, який є більш розбірливим і придатним для використання та інтерпретації [закрито]

Я Елвіс, дуже намагаюся навчитися бути Ейнштейном. Я працюю в Морті.

Про що, чорт забирає цей божевільний ідіот!?!? (Вам потрібно лише прочитати перші кілька абзаців)

Якщо ви не хочете читати це посилання, я, як правило, я професійний програміст, а мій начальник (це страшно точно):

професійний професійний програміст, який не має ступеня інформатики, але добре знайомий з Office та VBA, і, як правило, пише додатки для продуктивності, якими ділиться серед його колег

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

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

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

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

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

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

У рамках вашого тестового процесу:

1. Почніть перетворювати алгоритми на щось легше зрозуміти (наприклад, діаграми, PDL, математичні позначення)
2. Навчіться розуміти алгоритми.
3. Обов’язково визначте крайові випадки.
4. Запитайте вченого, чи правильне ваше «спрощене» подання
5. І НАЙБІЛЬШЕ визначте проблеми, які ви виявили; І не звучачи "обвинувально", скажіть щось на кшталт "Я дивився на алгоритм і помітив XYZ, чи це потрібно робити чи це робити?". Ніщо не здобуде їх впевненості краще, ніж ця куля.

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

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

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

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

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

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

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

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

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

Якщо ваша мета:

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

2. Допомогти вашій компанії? Чи загрожує нинішня ситуація поточною ситуацією? Чи небезпечні терміни? Чи збільшує тепло керівництво вище керівництво? Якщо ні, то віддайте. (Це, по суті, те, що Джиммі Хоффа висловив у коментарі до своєї первісної публікації.) Якщо, однак, поточна ситуація насправді становить неприйнятний ризик для вашого відділу / компанії, то зміна процесу в порядку. У такому випадку я б запропонував вам сісти та окреслити іншерозподіл праці. Тут важливо пояснити, що час, який ви витрачаєте на рефакторинг коду вашого начальника, краще витратити на написання нового коду. Ви кажете, що не маєте часу написати це все самостійно, але це не те, що я пропоную. Вам потрібно розібратися, як максимально використовувати свої сильні сторони. Перестаньте думати про нього як про Морта, і думайте про нього як про молодшого розробника, який має чудові знання про домен. Це дуже поширена робоча домовленість у цій галузі, і вам було б довідатися, як процвітати в ній. Наприклад, переконайтеся, що він знає, що ви знаєте, наскільки важлива його експертиза (повторюйте цей крок часто), а потімсмиренно запропонуйте наступну стратегію (або щось подібне) як швидший шлях до отримання своїх знань на ринок: (a) розбити роботу на "спритний" спринт, (b) сильно співпрацювати вперед (у кожному спринті), визначаючи над -всі вимоги та архітектура. (c) Дозвольте йому піти і побудувати прототип для розробки всіх алгоритмічних рішень, будуючи при цьому інфраструктуру, про яку ви домовилися на попередньому кроці. (d) Впроваджуйте його алгоритми у вашу структуру, поки він будує тести для його перевірки. (e) Проводити свої V&V разом у середовищі однорангового програмування. (наприклад, "Цей тест не вдався; чому? помилка алгоритмічної логіки або помилка кодування?"; тут ітерайте).

3. Допоможи собі? Будьте тут чесними. Якщо все, що ви робите, скаржиться на те, що ви не любите свою роботу, я пропоную вам витратити більше часу на роздуми над №2 вище. Якщо ви не переймаєтесь компанією, і ви не любите свою роботу, почніть розповсюджувати своє резюме. Якщо ви дбаєте про свою компанію, але не насолоджуєтесь своєю роботою, то акцентування уваги на №2 має допомогти на рахунках BOTH. Але в цьому випадку це "безпрограшний виграш", лише якщо всім зрозуміло, що ваша пристрасть справді випливає з бажання допомогти Команді, а не просто з самоцентричного розчарування у вашому завданні.

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

Я вважаю, що у вас є два основні варіанти:

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