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

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

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

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

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

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

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

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

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

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

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

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

Но сколько контекста, мнений и мыслей мы хотим обменяться, прежде чем это сделать? Это еще один сложный вопрос сам по себе.

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

Что дальше?

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

  • Что лучше - табуляции или пробелы?
  • Когда технический долг может быть погашен?
  • Какой код мы считаем чистым?

Подпишитесь на рассылку новостей

Если вам это интересно, вы можете подписаться на мою информационную рассылку, чтобы получать уведомления о публикации новой статьи. Никакой рекламы и спама, только статьи и время от времени полезные ресурсы.

Первоначально опубликовано на https://alexkondov.com.