Ответ
Начну с уточнения требований, чтобы убедиться, что полностью понимаю задачу. Разберу её на подзадачи, оценю сложность и возможные риски. Если есть неясности — сразу задам вопросы, а не буду гадать.
Пример подхода:
// 1. Уточняю детали (например, API контракт)
public interface IOrderService
{
Task<Order> ProcessOrderAsync(OrderRequest request);
}
// 2. Предлагаю варианты реализации
public class OrderService : IOrderService
{
// ... логика с валидацией, логами и т.д.
}
// 3. Согласую MVP (минимальную рабочую версию)Всегда держу постановщика в курсе прогресса, особенно если обнаруживаю отклонения от изначального плана. Если задача требует итераций — разбиваю на этапы и согласую приоритеты.
Ответ 18+ 🔞
Да, ну вот смотри, как обычно бывает: приходит задача, а там нихера не понятно. И вместо того, чтобы сразу спросить, начинаешь сам додумывать, а потом оказывается, что клиент хотел совсем другую хуйню. Так что первое правило — не будь мудаком, уточни всё до запятой.
Вот смотри, как я делаю. Беру эту задачу и начинаю её разбирать, как честный человек, а не как какой-нибудь распиздяй, который сразу в код лезет.
Шаг первый: уточняю, что от меня хотят.
Например, если мне говорят «сделай обработку заказа», я не начинаю писать public void ProcessOrder(). Я лезу и спрашиваю: «Слушай, а что там с валидацией? А логировать надо? А если сервис оплаты сдохнет — что делать, повторять или сразу в ошибку?». Потому что если не спросить — потом самому же и расхлёбывать, когда окажется, что «ой, мы забыли про отмену, надо переделать». А это, блядь, время, нервы и овердохуища переделок.
Шаг второй: предлагаю варианты, как это можно сделать.
Не просто «сделаю», а «вот смотри, можно так — быстро, но криво, а можно эдак — дольше, зато надёжно». Выкладываю всё на стол, как карты. Пусть заказчик сам выбирает, что ему важнее: скорость или качество. А то потом скажет: «А чё так долго?» или «А чё так глючно?». Ну так сам же и выбрал, ёпта!
Вот, например, накидаю пример интерфейса, чтобы было понятно, о чём речь:
// 1. Уточняю детали (например, API контракт)
public interface IOrderService
{
Task<Order> ProcessOrderAsync(OrderRequest request);
}
// 2. Предлагаю варианты реализации
public class OrderService : IOrderService
{
// ... логика с валидацией, логами и т.д.
}
// 3. Согласую MVP (минимальную рабочую версию)Шаг третий: договариваюсь про MVP.
Чтобы не получилось, что ты полгода делаешь какую-то монструозную хуету, а заказчику уже вчера нужно было что-то простое, чтобы хотя бы запуститься. Говорю: «Давай сначала сделаем вот этот базовый функционал, который будет работать. А потом, если надо, нарастим остальное». Это спасает от кучи проблем, поверь.
И главное — не молчи, как Герасим из «Муму»! Если что-то пошло не так, или сроки горят, или требования поменялись — сразу говори. Держи всех в курсе, даже если новости хуёвые. Потому что если промолчишь и сорвёшь дедлайн — тебе же потом и влетит, причём по полной программе. А так — все в курсе, все понимают риски, можно вместе искать решение.
Короче, суть в том, чтобы работать с головой, а не как попало. Потому что иначе получится та ещё история, в рот меня чих-пых.
