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

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

Нечасто можно услышать, что разработка программного обеспечения — это уже решенная проблема. Ваша конкретная инженерная проблема или что-то подобное уже было обдумано и решено кем-то более умным, чем вы. Инженерия обычная, проверенная, известная, прямолинейная и простая. Красивый код — это то, что нельзя сделать более ясным и простым. Креативность и оригинальность должны быть на более высоком уровне. Несмотря на это, я был во многих ситуациях, работая с кем-то старше меня, когда было очевидно, что этот человек был умен. Это лишь вопрос времени. Вопрос в том, как обращаться с Clever Design?

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

Что искать в Clever Designs:

  • Решение сформулировано с точки зрения производительности без каких-либо фактических числовых доказательств. Было доказано, что интуиция людей о производительности невероятно неточна, особенно опытные инженеры.
  • Решение сформулировано в абсолютном выражении: «другого способа сделать это нет». Всегда есть альтернативы, идеальных решений не бывает.
  • Решение принимается без рассмотрения альтернатив. Доказано, что люди, рассматривающие одну альтернативу, редко выбирают наилучшую.
  • Решение принимается без учета чужого мнения.
  • Решение основано на аргументе авторитета. «Это правильно, потому что я знаю, что это основано на моем обширном авторитете и опыте».

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

Это может быть формой продажи вашей души. Жизнь коротка, вы должны делать то, что вам нравится. Вы действительно хотите создать что-то, что вам не нравится, а затем поддерживать и отлаживать это? Точно нет. Тем не менее, есть ощущение, что вы хороший член команды, помогаете и идете на компромисс, особенно когда это не такая уж большая проблема. Одна неделя работы? Один месяц? Эти сроки стоят того, чтобы я мог построить хорошие отношения с членами команды, но это зависит от обстоятельств.

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

Спасибо за чтение, хотелось бы услышать, что вы думаете.