Помогая тому, кто не является и никогда не будет профессиональным программистом, написать код, который будет более разборчивым и удобным для использования и интерпретации [закрыто]

Я Элвис, очень стараюсь научиться быть Эйнштейном. Я работаю на Морта.

О чем, черт возьми, говорит этот сумасшедший идиот!?!? (Вам нужно только прочитать первые несколько абзацев)

Если вы не хотите читать эту ссылку, я профессиональный программист, и мой начальник (это очень точно):

профессиональный бизнес-программист, которому не хватает степени в области компьютерных наук, но он хорошо знаком с Office и VBA и обычно пишет приложения для повышения производительности, которыми делятся его коллеги

Все это говорит о том, что большая часть моей работы состоит в том, чтобы собрать его собранный код и подготовить его к работе. Тем не менее, очень плохой стиль и грузовой культ делает это трудным. Это усугубляется тем фактом, что он не хочет читать книги по программированию или позволяет мне помочь ему рефакторинг своего кода.

Существуют ли другие стратегии, помогающие кому-то, кто не является профессиональным программистом, никогда не будет профессиональным программистом писать код, который будет более понятным и удобным для меня, чтобы я мог его использовать и интерпретировать?

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

Вместо того, чтобы жаловаться на ученого и ожидать, что он изменится, просто осознайте, что ученому не следует сильно заботиться о «качестве кода». Часто бывает трудно заставить других разработчиков программного обеспечения заботиться о «качестве кода», не говоря уже о ком-то, чьи основные интересы лежат в области, а не в программировании.

Откуда вы идете отсюда, во многом зависит от степени уверенности «ученого» в вашей способности понять их работу. Если они уверены, что вы можете понять их код и не испортите его, когда вы что-то измените, то обычно это не проблема. Они будут полагаться на ваш опыт.

Однако, если ученый не хочет, чтобы вы меняли их код, тогда весьма вероятно, что вы еще не «заслужили» их доверие. Если это так, то вместо того, чтобы сосредоточиться на исправлении ученого, вы должны сосредоточиться на «исправлении» себя. Под этим я подразумеваю шаги по завоеванию их доверия. Вероятно, самый простой способ сделать это заключается в следующем:

Как часть вашего процесса тестирования:

1. Начните превращать алгоритмы во что-то более простое для понимания (например, диаграммы, PDL, математические обозначения)
2. Научитесь понимать алгоритмы.
3. Обязательно определите крайние случаи.
4. Спросите ученого, правильно ли ваше упрощенное «альтернативное» представление
5. И НАИБОЛЕЕ ВАЖНО определить проблемы, которые вы обнаружили; И, не произнося «обвинительный», произнесите что-то вроде: «Я смотрел на алгоритм и заметил, что XYZ должен это делать или он должен это делать?». Ничто не получит их уверенность лучше, чем эта пуля.

Как только вы начинаете находить ошибки и проявляете интерес к их интересующей области, шансы становятся намного выше, чем, по крайней мере, они позволят вам изменить код, чтобы сделать его более «профессиональным». Зачастую они даже не чувствуют необходимости кодировать прототип больше. Они просто напишут что-то в одной из тех «альтернативных» нотаций, которым вы их научили (даже не осознавая этого), и они будут уверены, что вы поймете, что они имеют в виду.

Безусловно, моей первой попыткой было бы предложить несколько советов о том, как ученый может лучше всего помочь «лучше общаться», чтобы помочь вам; но звучит так, будто ты это пробовал. Таким образом, единственный шаг, который вы контролируете - это то, что вы делаете. Заработайте их доверие, и почти всегда эксперт по предметной области будет рад передать кодирование кому-то другому и не будет беспокоиться обо всех мелких деталях, которые входят в написание кода. Они бы предпочли сосредоточиться на улучшении алгоритмов.

Иногда все, что вы можете сделать, это предложить предложение и оставить его после этого. Вы не произведете впечатление на своего босса или старшего, если продолжите говорить о том, что они уже отвергли или решили, что не хотят этого делать, даже если вы на 100% правы. На самом деле, это повредит отношениям, будь вы предложителем или предложителем. Просто сосредоточьтесь на том, что ВЫ можете сделать, чтобы облегчить свою работу.

Когда вы действительно «кто-то, кто не является профессиональным программистом, никогда не будет профессиональным программистом», как вы говорите, и когда большая часть вашей работы действительно «берет его собранный код и делает его готовым к производству», это звучит как ваш Команда из двух человек будет более продуктивной, если он оставит вам программирование и сконцентрируется на управленческой части проекта.

Однако это предполагает, что вы правы. Мы, программисты, всегда склонны игнорировать код, написанный другими людьми, гораздо хуже, чем наш. Это предубеждение действительно трудно победить и приводит к тому, что мы недооцениваем наших коллег. То, что вы считаете «программированием культа грузов», может быть «проверенной передовой практикой» с его точки зрения, а то, что вы считаете «элегантным применением объектно-ориентированных шаблонов», может быть «ненужным переобучение» для него. Трудно сказать для меня, потому что я знаю только вашу сторону истории.

Презрение к чужому коду становится тем сильнее, чем более различаются наши стили программирования. В этом случае это позитивный инстинкт, потому что смешивание разных стилей программирования в одном проекте делает его очень трудным для поддержки.

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

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

Вы должны спросить себя: какова ваша конечная цель здесь? 1. чтобы помочь своему боссу? 2. помочь компании? 3. чтобы помочь себе? И прежде чем ответить «все вышеперечисленное», помедленнее. Ваша первая задача - четко определить вашу основную цель, потому что от нее зависит ответ.

Если ваша цель состоит в том, чтобы:

1. Помочь своему боссу? Брось это. Он, кажется, не просит об этом. Вы сказали: «Он знает, что его код плох, но он делает то, что ему нужно». Ну что ж, конец обсуждения. До тех пор, пока ваш начальник не будет недоволен текущей ситуацией, он не изменится, и он будет негодовать на ваши усилия, чтобы помочь ему. Если в какой-то момент в будущем он «почувствует боль» существующего положения, надеюсь, вы зарекомендовали себя как заслуживающий доверия наставник, и он будет знать, куда обратиться за помощью.

2. Помочь вашей компании? Угрожает ли текущая ситуация практическим результатам? Сроки в опасности? Верхнее управление увеличивает свою высокую температуру? Если нет, то откажитесь. (По сути, именно это высказал Джимми Хоффа в своем комментарии к вашему первоначальному сообщению.) Если, однако, текущая ситуация на самом деле представляет собой неприемлемый риск для вашего отдела / компании, тогда необходимо изменить процесс. В этом случае я бы предложил вам сесть и наметить другуюразделение труда. Ключевым моментом здесь является объяснение того, что время, потраченное на рефакторинг кода вашего босса, было бы лучше потратить на написание нового кода. Вы говорите, что у вас нет времени, чтобы написать все это самостоятельно, но это не то, что я предлагаю. Вы должны выяснить, как максимизировать свои сильные стороны. Перестаньте думать о нем как о Морте, и подумайте о нем, как о младшем разработчике с превосходным знанием предметной области. Это очень распространенное рабочее соглашение в отрасли, и вам следует научиться тому, как в нем процветать. Например, убедитесь, что он знает, что вы знаете, насколько важен его опыт (часто повторяйте этот шаг), а затемсмиренно предложите следующую стратегию (или что-то подобное) в качестве более быстрого пути, чтобы донести свои знания до рынка: (а) разбить работу на «гибкие» спринты, (б) активно сотрудничать заранее (в каждом спринте), определяя сверх -все требования и архитектура. (c) Позвольте ему уйти и создать прототип, чтобы выработать все алгоритмические решения, в то время как вы создаете инфраструктуру, с которой вы согласились на предыдущем шаге. (d) Реализуйте его алгоритмы в вашей структуре, пока он строит тесты для проверки. (e) Проведите ваше V & V вместе в среде однорангового программирования. (например, «Этот тест не удался; почему? ошибка алгоритмической логики или ошибка кодирования?»; итерация здесь).

3. Угощайтесь? Будьте честны здесь. Если все, что вы делаете, это жалуетесь, что вам не нравится ваша работа, я советую вам потратить больше времени на размышления о # 2 выше. Если вы не заботитесь о компании И вам не нравится ваша работа, начните распространять свое резюме. Если вы ДЕЙСТВИТЕЛЬНО заботитесь о своей компании, но не наслаждаетесь своей работой, то фокус на # 2 должен помочь в ОБАХ аккаунтах. Но в этом случае это «беспроигрышный вариант», только если всем ясно, что ваша страсть искренне проистекает из желания помочь Команде, а не только из-за эгоистичного разочарования в вашем назначении.

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

Я считаю, что у вас есть два основных варианта:

1. Пусть код запускается . Если код работает и делает то, что должен, если ваш начальник специально не просит вас исправить его код, просто оставьте его как есть. Это также может привести к тому, что он поймет, что ваш код выглядит лучше, и оставит вам работу (как также указал Данк в своем ответе).
2. Если вы полны решимости сделать код профессиональным, создайте библиотеку / фреймворк, которые он сможет использовать. Если есть шаблон ошибок, которые вы обычно исправляете, вы можете обернуть их в несколько библиотечных файлов и передать его ему в качестве «базовой библиотеки для компании» , которую вы также можете использовать как Общий интерфейс.