Вы считаете разработку программного обеспечения трудной задачей? Что ж, вы не одиноки.
Вы можете винить язык, противоречивые принципы и методологии. Виноват постоянно меняющийся технологический ландшафт. Может быть, дело в бизнесе, который сам не знает, чего хочет. Может быть, вам слишком сложно определиться с технологическим стеком. Виновата устаревшая библиотечная документация, если хотите.
Разработка на основе предположений - это самая главная причина, по которой разработка программного обеспечения затруднена.
Сколько раз вы думали про себя или слышали, как ваш коллега говорил: "этого не может быть", "я знаю, что данные структурированы таким образом", "я знаю все возможные входы", или наоборот "мне нужно учесть все возможные входы", или просто "я уже делал это раньше" - только для того, чтобы доказать, что вы ошибаетесь.
Если вы позволите своим предположениям руководить вами, это неизбежно отразится на вас и на всей команде. Часто бывает слишком поздно, когда пузырь лопается, и вы (или кто-то другой) понимаете, что вся выполненная работа в корне ошибочна.
Программирование на основе предположений может проявляться по-разному, но я обычно нахожу такие общие черты:
Простые задачи внезапно становятся трудновыполнимыми или даже трудно приступить к их выполнению
Код становится чрезмерно многословным
Сложные техники и конструкции используются без необходимости
Дико неточные оценки, как по времени, так и по затратам.
Вы слишком много думаете о решении, его угловых случаях, счастливом пути и т.д.
Есть ли противоядие от собственных предположений?
Да, и, к счастью, оно простое.
Задавайте вопросы. Постоянно. Чем больше, тем лучше. Чем быстрее вы подтвердите свои предположения, тем лучше.
Что делать, если вы не понимаете описание пользовательской истории? Спросите владельца продукта. Что делать, если вы не совсем понимаете, зачем нужна та или иная функция? Спросите владельца продукта. Сомневаетесь, как подойти к настройке кода? Спросите старшего разработчика или эксперта по языку.
Иногда просто не стоит копаться в чужих мозгах - ведь они могут дать вам ответы, основанные на предположениях. В этом случае вам придется проверить все самому.
Вам говорят, что данные организованы определенным образом? Откройте DataGrip или SSMS и напишите SQL-запросы, подтверждающие это.
Пожертвуйте своим эго на начальном этапе, чтобы потом получить славу и известность. Поверьте, люди скорее ответят на один и тот же вопрос дважды, чем дважды переделают задачу.
То же самое относится и к командной работе, основанной на предположениях.
Скорее всего, вы будете координировать свою работу с другими людьми, если только вы не соло-предприниматель или просто кодите для удовольствия без какого-либо межличностного сотрудничества.
Я гарантирую дополнительную работу, если вы предполагаете, что другие точно знают, как выполнить задачу, что для этого необходимо, какие условия нужно учитывать и какие нефункциональные требования должны быть выполнены.
Конечно, все это можно было бы прояснить заранее в описании пользовательской истории, документации, вики или еще где-нибудь. Однако реальность такова, что не все пользовательские истории идеально проработаны, обсуждены, или, возможно, не все известно на момент написания.
Постарайтесь взять за привычку обращаться к своим соразработчикам, если они берут задачу, в которой вы разбираетесь. Это, несомненно, будет очень полезно. Не думайте, что другие обладают таким же объемом знаний, как и вы, по любой задаче.
Подводя итог...
Не полагайтесь на свои предположения. Не стоит полагаться и на чужие предположения.
Если что-то сложно, не имеет смысла или заставляет вас прыгать через обручи, то это, скорее всего, потому, что вас вводят в заблуждение ваши ошибочные предположения.