Как избавиться от привычки усложнять задачу?

Есть привычка усложнять задачу больше чем надо. Как выработать чувство той границы на которой пора остановиться?

Например, были в таблице два текстовых поля Точка_1, Точка_2, потом мысль пошла... вроде как к полям надо даты... а почему бы их не выделить в отдельную таблицу с полями ID, Text, Date... но у точки есть значение Value... Значение может быть разных единиц измерения... их может быть несколько... Надо справочник единиц измерения... могут быть кг и граммы надо их привести... потом понимаешь, что ещё немного и наступит .опа , а не вернуться ли назад к текстовым полям в которых пользователь может написать все-что ему надо )))
  • Вопрос задан
  • 3510 просмотров
Решения вопроса 3
romy4
@romy4
Exception handler
Этот процесс называется определение milestones. Вы сперва определяете MVP (minimal valuable product) — то есть тот уровень завершённости (без рюшечек и плюшек), при котором можно получать выгоду и дальше вы уже строите отталкиваясь от MVP
Ответ написан
@MarkusD
все время мелю чепуху :)
Лично мне было бы интересно послушать подробности. В данной трактовке вопрос очень сложен из-за своей расплывчатости. :)
Конкретнее! Нужна иллюстрация хода мыслей и критерии, по которым у тебя создается ощущение усложнения задачи.
Так же очень важно понять, сам ты замечаешь усложнение или же тебе говорят об этом.
Александр Синицын , дополни свой вопрос.

Нередко в неадекватном усложнении задачи обвиняют именно те "соратники", кому попросту непонятна ни сама задача, ни ход твоих мыслей. Как правило это результат эффекта Даннинга-Крюгера.
Ответ написан
petermzg
@petermzg
Самый лучший программист
Разбивать задачу на более мелкие и им давать стоимость(временную и финансовую).
Scrum
Ответ написан
Пригласить эксперта
Ответы на вопрос 10
saboteur_kiev
@saboteur_kiev Куратор тега Программирование
build engineer
У вас слишком много свободного времени, вот и не знаете куда девать.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Делите на базовый и расширенный функционал.
Базовый - это тот минимум, без которого невозможно пользоваться системой.
Расширенный - то, что можно "навесить" после запуска основного.
Ответ написан
Rou1997
@Rou1997
Слишком мягкие дедлайны? Найдите подработку, вторую, третью, и так пока не станут жесткими! Еще и разбогатеете!
Не хотите богатеть, считаете себя и так достаточно состоятельным? Обратитесь скажем в Даймлер-Бенц, а лучше в Бугатти, и т.п., они вас быстро переубедят!
Ответ написан
Освоить методологию "ху*к-ху*к и в продакшен". Потом доработаете. Лучше сперва недоделать и получить порцию правок, чем сделать слишком много и потом вырезать ненужное.
Ответ написан
@Skit25
на всё воля Бога
Вчера читал статью.
Признак квалифицированного специалиста, его способность решать задачу просто.
Учиться и еще раз учиться. Выше TDD советуют, тоже тема! На самом деле, написал код и возрадовался. Через 15 минут, код похудел в три раза. Да будет так! И снова запустил тесты.
Ответ написан
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
Иногда усложнять нужно. Представь что ты не исполнитель, а заказчик. Задай себе вопрос - стал бы ты оплачивать вот эту повышенную сложность, увеличенные сроки и пр.? Нужны ли они на самом деле, или можно обойтись без них. В конце концов все мы делаем продукты и инструменты, которые должны облегчать жизнь людям, желательно с минимально возможными сроками и бюджетом с максимально возможным качеством и функциональность. Вот нахождение баланса в этой всей истории и есть цель.
Ответ написан
@coodan
Думаю, учиться. В том смысле, что пока есть время, пробовать и так и эдак. Посмотреть на подводные камни. Найти для себя лучшее решение. А потом воспроизводить его, не задумываясь, на автомате.

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

Одного не стоит делать - все время переписывать одно и то же когда оно действительно срочно нужно.
Ответ написан
lxsmkv
@lxsmkv
Test automation engineer
Полезно пытаться абстрагировать задачу от конкретных вещей ближе к математике. Шелуха килограммами отпадает.
Ответ написан
deemytch
@deemytch
linux root, ruby/perl programmer, sql, backend.
Волшебное слово TDD.
Силы и хитрость тратятся на написание (и отладку!) тестов. На написание кода остаётся ровно то, что нужно, чтобы обзеленить тесты.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы