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

Я начал свою карьеру в качестве разработчика .NET 3 месяца назад, и после долгого учебного плана по различным технологиям, шаблонам и концепциям разработчики, которые контролировали меня, решили, что я готов присоединиться к одному из многих проектов, которыми занимается компания.

Я очень рад, что наконец-то смог начать писать код. Команда, к которой я присоединился, довольно мала, потому что начинала с нового проекта, и это здорово, потому что я принимаю участие во всем жизненном цикле проекта. Это веб-проект SPA с резервной копией, использующий веб-API ASP.NET MVC / ASP.NET, а также интерфейс Durandal и связанные с ним библиотеки.

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

Я никогда не выполнял ни одной из созданных задач и не знаю, как мне поступить.

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

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

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

• Подумайте о проблеме и нарисуйте несколько диаграмм. Убедитесь, что вы знаете, в чем заключается проблема, которую вы пытаетесь решить.
• Изучите, что вы пытаетесь сделать. Интернет является ценным источником информации. Я не говорю, спрашивайте переполнение стека - я говорю, исследуйте, как другие люди уже решили проблему, подобную вашей, или подошли к ней. Вот что придумал Google: «Обработка исключений как системная проблема» . Лично я всегда стараюсь учиться у других.
• Наконец, и это может быть самым важным, поговорите с другими людьми в вашей команде, чтобы получить больше разъяснений и указаний о том, что делать. Я всегда хочу, чтобы новые инженеры приходили и просили руководства по проектам.

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

Вот почему я инженер; Я люблю выяснять новые вещи.

Никогда не прекращайте изучать новые вещи. Обучение - это то, что делает тебя лучше.

Идеального решения не существует, но некоторые вещи могут помочь:

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

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

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

• Обратитесь за помощью в выборе правильного задания и подхода к началу работы.

• Ищите наставника, который может дать вам постоянную (в идеале ежедневную) обратную связь в течение недели или двух.

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

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

• Не бойтесь задавать самые основные вопросы. Трудно оспаривать предположения других, но если вы не можете продолжить то, что вам дают, вам придется снова задавать вопросы.

• Если вы знаете цель, делайте как можно больше, пока не застрянете, а затем опубликуйте ход и вопрос в переполнении стека.

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

Лично я бы отодвинул это понятие. Написание чего-либо «общего» перед реализацией реальных требований пользователя почти всегда является пустой тратой времени. А поскольку он универсален , по определению он не специфичен для вашей компании или приложения, поэтому, возможно, уже есть что-то, что удовлетворит примерно 95% ваших потребностей.

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

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

=================

PS Есть некоторые программисты, которые думают, что способ начать любой проект - написать «платформу» для предоставления всех общих сервисов, которые будут необходимы модулям приложения. Это обычно превращается в месяцы тривиальной работы, переизобретающей вещи, которые уже доступны бесплатно. Пока вы не достигнете пределов производительности доступных решений, нет никаких оснований для написания «платформенных» сервисов. Также нет причин писать обертки вокруг существующих API. Если вы непрерывно проводите рефакторинг, то волшебным образом появится точная оболочка, требуемая вашим приложением.

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

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

Поиск - веб-поиск по общей обработке ошибок ничего не дал? Вы не можете найти полное решение. Вам все равно придется поработать над этим и привести его в соответствие с вашим приложением.

Прототип - измените свой взгляд на задачу от производства до прототипа. Просто заставьте что-то работать и строить оттуда. Когда вы дойдете до того, что сможете использовать, начните думать о нем как о производстве. Теперь вы не увидите задачу как нечто, чего вы даже не знаете, с чего начать.

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

Это старая шутка о врачах, которые все еще «практикуют» медицину; у них тоже нет ответов на все вопросы.

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

Мой личный процесс выглядит примерно так:

• Исследование. Узнайте, если и как эта проблема, или аналогичная проблема, была решена ранее. Даже если вы можете найти информацию только о решениях для разных языков или платформ, она все равно может быть чрезвычайно информативной.
• Прототип. Абсолютно лучший способ сделать что-то правильно - сначала сделать это неправильно. Создайте решение, составляя все по ходу дела, основываясь на ваших исследованиях. Постарайтесь привести его в соответствие с основными требованиями, учитывая вспомогательные требования. Не пытайтесь сделать его красивым или совершенным, расширяемым, гибким или производительным, просто заставьте его работать. Записывайте извлеченные уроки - что сработало, что не сработало, потенциальные препятствия и т. Д. Затем выбросьте код. Если вы беспокоитесь о том, чтобы выглядеть глупо из-за слишком долгого времени, делайте это в свое свободное время. Это приносит пользу вам лично, с точки зрения знаний.
• Дизайн. Объедините свои внешние знания (исследования) с личными знаниями (полученные уроки-прототипы) и сформулируйте план того, что, по вашему мнению, будет правильным способом сделать это.
• Сотрудничать. Найдите старшего члена команды, покажите им предложенный дизайн, получите обратную связь. Покажите это кому-то еще, получите их обратную связь. Уточните свой дизайн.
• Итерация. Если вы все еще не уверены в своем решении, убедитесь, что рецензирование является частью вашего цикла итерации. Регулярно доводите вашу реализацию до старшего члена команды для обратной связи.
• Будьте счастливы - вы продвинули свои знания и свою карьеру, и вам нужно сделать что-то новое и интересное, а не что-то старое и скучное, что вы делали тысячу раз раньше. Постарайтесь сделать ваш следующий проект еще более сложным.

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