Просматриваем старую базу кода, как начать взаимодействовать с командой разработчиков?

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

Не очень короткая версия:

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

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

1-Задавайте вопросы о конкретных частях кода (у меня есть большая куча заметок, полных ими)

2-Узнайте о функциях и деталях, которые, по моему мнению, в основном незакончены.

3-Спросите о проблемах с ремонтопригодностью, которые я поднял.

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

5-Попросите лучшую документацию.

Примечания к контексту:

  1. Я подозреваю, что они чрезмерно защищают свой код
  2. Я знаю, что они не привыкли иметь менеджера (не для проверки/критики или соблюдения сроков)
  3. Я их плохо знаю лично, и я им не начальник, мы не работаем в одной комнате и не обедаем вместе.
  4. Я знаю, что у них было много проблем с их разработкой, и большинство из них не по их вине, но я не совсем рядом, чтобы помочь.
  5. У них есть некоторый ограниченный процесс рецензирования, который в основном сводится к проверке, работает ли код на чужой машине. Они не привыкли к тому, что кто-то проверяет качество кода.
  6. Они часто дают пренебрежительные ответы на вопросы во время совещаний ( «есть ли у вас функция для выполнения Х?» — «У нас есть функции для всего, что мы хотим» ). Другие люди даже указывали на это во время встреч.
  7. Их продукт сильно отстает от графика.
  8. Я не заметил ни настоящей ошибки, ни чего-то явно неправильного. Полагаю, мне нечего предложить им в обмен на их внимание. В идеале предпочтителен ответ, не предполагающий вмешательства руководства.
  9. Большинство частей, которые должны были бы добраться до интерфейса между нашими продуктами, видимо, не сделаны, но они не сообщают об этом.

Таким образом, несколько практических подходов могут быть следующими:

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

2. Я мог бы запланировать встречу с младшим разработчиком и пройтись с ним по своим заметкам. Обстановка встречи позволила бы больше сосредоточиться на разговоре, но я бы понял, если бы он чувствовал, что его слишком критикуют. Я мог бы разделить записи на несколько встреч, но тогда каждая встреча была бы сложнее предыдущей.

3. Я начинаю публиковать сообщения о проблемах в инструментах управления версиями и/или делать глупые запросы на включение в их кодовую базу (исправлять опечатки, вставлять лучшие комментарии и т. д.). Я думаю, это будет раздражать всех, и если они действительно отклонят или приостановят запрос на вытягивание без объяснения причин, я буду очень оскорблен. Но некоторые из моих жалоб могут потребовать ответа «тогда сделай сам» .

Чего я хочу/должен достичь, так это: я хочу относительно хорошо знать их кодовую базу и заставить их признать это. Мне нужно иметь возможность задавать деликатные/конкретные вопросы и получать честные, конкретные ответы. Я бы хотел, чтобы они со временем улучшили свои стандарты кодирования и документацию.

Знают ли они, что вам поручили проверить их код? Если нет, то какое-то введение и объяснение было бы хорошим началом.
Какова коммерческая цель этого обзора? Это то, что вы делаете как часть своей работы, или что-то, что вы решили делать самостоятельно?
Может быть, они не слишком бережно относятся к коду и ждут, пока кто-нибудь расскажет о пресловутом слоне.
@ sf02 они знают, что мне нужно просмотреть (хотя бы часть) их кодовую базу, мне даже пришлось напрямую просить младшего, чтобы получить доступ к системе управления версиями. Я также попросил документацию, которая помогла бы создать интерфейс, на что мне ответили, что ее практически нет. Это не значит, что они ожидают, что я буду придираться к качеству кода.
@StephanBranczyk они не всегда разговаривают с не кодерами, а в другой ситуации они ответили: «мы определяем интерфейсы с системой X в документе Y» (тогда я не участвовал), но документ был как высокого уровня ( без кода, переменных и т. д.) и отсутствуют некоторые части (только заголовки). Это то, с чем я не могу позволить себе столкнуться. И да, моя миссия не в том, чтобы повышать качество кода, но то, что мне нужно делать, было бы намного проще, если бы они улучшили свои стандарты и документацию. Мне также нужно будет принять участие в интеграции продуктов.
@StephanBranczyk относительно проблем с открытым исходным кодом, проблема в том, что кодовая база является частной и должна соответствовать некоторым минимальным стандартам, инструменты с открытым исходным кодом имеют очень разные стили и уровни документации. Некоторые из них были изменены, а некоторые будут изменены, однако не было создано никакой документации (даже журнала изменений), и при интеграции этих инструментов с открытым исходным кодом не применялись никакие стандарты кодирования, даже модифицированные.
Моя работа @PlayerOne — создать еще один инструмент и интегрировать его с ними. Из-за отсутствия документации и из-за того, что они не могли/не желали предоставлять непротиворечивую информацию в прошлом (пренебрежительные ответы, изменение ответов, заявления о том, что вещи более готовы, чем они были на самом деле), я решил сначала ознакомиться с кодовой базой ( что все, включая руководство, знают, что в конечном итоге мне все равно придется это сделать).
По какой причине вы думаете, что вам нужно «относительно хорошо знать их кодовую базу» и почему им нужно «улучшать свои стандарты кодирования», предположительно, до тех стандартов, которых вы придерживаетесь? Может пропустил, но не вижу причины. Просто кучка пальцев. :)
@Cypher: Вы не ошибаетесь, в какой-то степени это справедливо. Я всегда был убежден, что «качество кода» должно навязываться либо людьми, которые к этому привыкли, либо реальными менеджерами. Я никогда не преуспевал и не видел, чтобы кто-то преуспел в обучении новоиспеченным выпускникам вне этих условий. В основном потому, что существует достаточно серой области, чтобы все попало в категорию «пошевелить пальцем». Я мог бы высказать по этому поводу большое «это не моя проблема» и просто пропустить любой соответствующий комментарий.
@Cypher: Чтобы ответить на ваш другой вопрос, поскольку мне нужно будет использовать и работать с их кодом (и, вероятно, самому изменять его части), поэтому мне нужно знать его в некоторой степени. Я считаю, что, зная его «относительно хорошо», я могу избежать пренебрежительных ответов и иметь возможность независимо оценивать их прогресс в частях, имеющих отношение к интерфейсу (хотя, если бы я знал, как лучше поступить, я бы не задавал здесь этот вопрос). ).
@Cypher: Самая деликатная часть заключается в том, что я также обеспокоен тем, что из-за их отсутствия доставки интеграция моего продукта с их продуктом не будет продвигаться, поэтому я не смогу доставить свои поставки, ситуация, которую я не могу ни принять пассивно, ни винить их. Из-за этого их улучшение качества облегчило бы мою жизнь (и проект компании в долгосрочной перспективе).
@Mefitico, а, вы говорили о библиотеках с открытым исходным кодом. Хорошо, сейчас я понимаю. Кроме того, ваши другие пункты хорошо приняты.

Ответы (5)

Если вам нужно интегрироваться с их кодом, почему бы не рассматривать его как черный ящик?

Если вы укажете, каких результатов вам нужно достичь, и попросите их описать, как взаимодействовать с их кодом для достижения желаемых результатов, а не просматривать сам код. Другими словами, попросите их предоставить подробную спецификацию (аналогично контракту на обслуживание с точки зрения API), а не объяснять, как работает их реальный код на подробном уровне.

Это жизнеспособно?

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

У вас нет причин изучать старый код или подвергать сомнению все это. Не похоже, что есть бюджет, чтобы пойти и переписать/рефакторить все это, не так ли? Хотя, если бы это было так, я бы все равно сосредоточился не на существующей реализации, а на сборе бизнес-требований и последующей проверке того, соответствует ли им код. Это также создаст четкие точки действий о том, что и как нужно улучшить, а по мере написания нового кода — это время для внедрения лучших методов кодирования с помощью проверок запросов на вытягивание.

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

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

Вам вообще не нужно смотреть на их код, и качество кода не должно иметь для вас значения. Что вам нужно, так это четко документированные интерфейсы. И если этих четко документированных интерфейсов нет, кто-то должен их создать.

Что вам нужно сделать, так это поговорить с кем-то, кто отвечает за то, как вы получите то, что вам нужно. Кто-то, кто может сказать команде: «xyz нужно задокументировать, и это имеет более высокий приоритет, чем задачи a, b и c». И вы, вероятно, были бы подходящим рецензентом для этой задачи.

Какова ваша цель здесь? Все, что я вижу из вашего вопроса, - это личное обучение, поскольку я не вижу бизнес-цели (например, мне нужно изучить базу кода, потому что я буду разрабатывать продукт с группой, писать тестовые примеры и т. д.). У разработчиков есть только определенное количество времени в день, и, учитывая выбор между целями, поставленными перед ними их боссом, ИЛИ удовлетворением вашего интеллектуального любопытства, какую из них они выберут?

Сообщите о своих целях, почему вы делаете то, что делаете, и если разработчики увидят какие-то положительные стороны этой идеи, они, скорее всего, будут работать с вами, чтобы добиться этого.

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

Эта документация представляет собой не просто список классов/функций, не просто сгенерированный doxygen список комментариев из кода, она должна иметь хороший общий обзор архитектуры, модулей приложения, а затем переходить к следующему и следующему. уровень, компоненты, классы, их взаимодействие и т.д. и т.п.

Если такой документации нет, то это первый момент, который нужно исправить — они должны это сделать.

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

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

Если компания не дала им на это время, а теперь вы приходите и просите их об этом, им (по понятным причинам) это не понравится.

В ситуациях, когда разработчики все время хотели поступать правильно, но им не позволяли, для них неплохо иметь кого-то, кто заставляет их поступать правильно сейчас.
Просматриваем старую базу кода, как начать взаимодействовать с командой разработчиков?
СпросиСетьПолитика конфиденциальности1y, 0v