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

20

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

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

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

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

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

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

durron597
источник
3
Похоже, что там есть хороший вопрос для workplace.stackexchange.com , но я не уверен, что этот вопрос будет хорошо принят в его нынешнем виде.
Барт ван Инген Шенау
2
@BartvanIngenSchenau Я подумал о том, чтобы опубликовать это там, но я выбрал здесь, потому что проблемы очень специфичны для программирования. Я считаю, что это (из-за помощи) разработка методологий и процессов и управления разработкой программного обеспечения . Я не спрашиваю об общих проблемах на рабочем месте, о политике в офисе , я спрашиваю: «Какие стратегии разработки программного обеспечения я могу использовать для работы с таким человеком».
durron597
3
@gnat Я думаю, что это не дубликат, за исключением одного существенного различия: в этом дубликате плохой код уже был написан. Здесь вопрос заключается в том, как предотвратить этот плохой код, в первую очередь, кем-то другим.
Эйфорическая
6
Вопрос в том, можете ли вы что- нибудь сделать, если вы в этой ситуации подчинены?
Филипп
4
Я не вижу проблемы, которая будет решена здесь. Вы получаете проблемы от других людей в компании из-за его низкого качества работы? Вы пропускаете важные сроки из-за затрат на обслуживание, или программное обеспечение постоянно ведет себя плохо, вызывая проблемы у вас и у него у ваших пользователей? Если ничего из вышеперечисленного нет, то я думаю, что низкокачественная работа, которую вы и ваш начальник производите, - это именно то, чего хочет и нуждается бизнес, и на самом деле нет никаких проблем, кроме того, что вы хотите другую работу. В этот момент только вы можете решить , насколько сильно вы хотите другую работу, если это стоит риска
Джимми Хоффа

Ответы:

8

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

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

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

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

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

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

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

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

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

Замочить
источник
19

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

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

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

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

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

Philipp
источник
2
Я хотел бы сделать это. Проблема в том, что если каждый из нас работает по 40 недель, это превратит разделение труда в более чем 20 и 60, и он будет иметь мало общего с остальным временем. Нам нужно больше персонала (чтобы он не программировал) - это то, что мы оба хотим, но в данный момент есть финансовые проблемы.
durron597
4
Это не то, что мы делаем, но представьте, что вы работали над проектом, который анализирует ДНК. Ваш начальник пишет дрянную программу, которая анализирует один небольшой набор данных для различных вещей, проверяет правильность, а затем ваша задача - запустить эту программу во всей базе данных проекта Human Genome. У меня не просто стиль очистки, я также должен улучшить алгоритм работы. Но его работа (причина, по которой он получает зарплату) - опыт в области «правильности», которая на самом деле не является проблемой программирования, и у меня нет такого опыта.
durron597
2
@ durron597: Звучит так, будто он вырубает грубое доказательство концепции, а затем заставляет вас сделать его красивым, отшлифованным и готовым к производству.
FrustratedWithFormsDesigner
4
@ durron597 Если он эксперт по предметной области, способный проверить правильность, будет ли он открыт для идеи написания модульных тестов, которые бы полностью указывали все? По сути, вместо того, чтобы создавать прототипы функциональности, вы, ребята, делали бы форму TDD, где он пишет тесты, чтобы убедиться, что все правильно, и вы выполняете фактическую реализацию?
Evicatos
4
@ durron597 (после дикого зайца, спровоцированного одним из комментариев :), не могли бы вы написать (n E) DSL, который позволил бы ему более кратко выразить свою логику таким образом, чтобы не требовалось переписывания с вашей стороны? ?
Пол
3

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

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

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

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

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

kmote
источник
1
Отличный ответ. Это определенно №2, и ваше описание того, что нужно сделать, похоже на то, что мы обсуждали в последние несколько дней. Мы определенно недостаточно общаемся.
durron597
Я только что добавил одно последнее предложение в третьем пункте. Пожалуй, самый важный из всех. Перечитайте свой пост и, честно говоря, спросите себя, так ли это, как вы сталкиваетесь с другими.
kmote
2

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

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

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