Как научиться мыслить как программист — отвечают эксперты

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

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

Исходя из опыта, могу выделить среди них следующие:

• Умение сформулировать/понять задачу.
• Умение упрощать.
• Умение декомпозировать, выделять главное, и выстраивать логическую цепочку.
• Умение выделять граничные значения и исключительные ситуации.

Спойлер: любой навык и любое умение нарабатывается только практикой.

Умение сформулировать/понять задачу

Фактически нас этому учат с детского сада — сначала выражать и формулировать свои желания, затем ставят все более и более абстрактные задачи, проверяя нашу способность понять их. И все здорово ровно до тех пор, пока вы общаетесь в одном информационном поле (школа, студенты одной специализации, специалисты одной предметной области). Проблемы начинаются тогда, когда вы взаимодействуете со специалистами из другой предметной области — медицина, страхование и т.д. Они говорят на своём языке, к которому привыкли, и вам придётся либо научится понимать, либо искать переводчика.

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

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

Умение упрощать

Из всех компонентов этот, наверное, самый близкий к коду. Упрощайте — используйте техники и подходы, которые позволят вам больше думать о бизнес-задаче, чем о том коде, который вы пишете:

• Early Exit — проверяйте условия в начале метода/функции и выходите, если вас что-то не устраивает.
• Разделяйте объекты на те, что содержат только данные и не содержат логики, и объекты, содержащие логику.
• Разделяйте логику по слоям (неважно, какой паттерн вы выберите).
• Механизм исключений — выбрасывайте исключения, если текущий слой не имеет возможности разобраться с исключительной ситуаций.
• Декларативное программирование (аннотации, декораторы и т.д., в зависимости от языка программирования, но тут важно знать меру).
• Любые другие, которые приведут к сокращению сложности восприятия кода (включая использование готовых библиотек, фреймворков и решений).

Умение декомпозировать, выделять главное и выстраивать логическую цепочку

Одно из ключевых умений, позволяет правильно расставлять приоритеты и проектировать системы. А также, что немаловажно, общаться с заказчиками и руководителями, которым важно все. Суть заключается в следующем — вы должны научиться из любой системы выделять ключевые компоненты, без которых эта система не имеет смысла, и определять их свойства и поведение.

Как с этим работать: опять же, только практика — выбирайте любую бизнес-систему и пытайтесь оставить в ней минимальное количество объектов и их взаимосвязей (если говорить терминами стартап-сообщества — MVP), позволяющих сохранить эту систему в работающем состоянии. Опишите весь процесс по шагам, посмотрите, какие объекты и как взаимодействуют.

Попробуйте понять, почему это взаимодействие устроено именно так. Например, почему процесс заказа или покупки устроен именно так, а не иначе. Можно ли организовать его по-другому? И почему в новых проектах,это взаимодействие иногда строится по-другому (они об этом любят писать в различных источниках).

Найдите changelog’и либо описание истории проекта, посмотрите как менялся проект со временем, с чего начинался, что в него добавлялось и почему.

Умение выделять граничные значения и исключительные ситуации

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

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

Вместо заключения

Как уже было сказано в спойлере, ключевое — это практика. Не бойтесь ходить на встречи с реальными заказчиками, не бойтесь задавать вопросы, не бойтесь браться за проекты из другой предметной области (но при этом трезво оценивайте свои силы — если вы ничего не смыслите в медицине, не стоит браться за написание ПО для какого-то аппарата жизнеобеспечения), не бойтесь пробовать новые подходы и методы (когда-то многие вещи из тех, что используются сейчас, высмеивались и считались в корне неверными).

Только через практику вы получите реальный опыт и на нём поймёте, что правильно, а что нет. Яркий тому пример: нас долгие годы учили тому, что нужно выполнить гигантский объём проектирования, нарисовать кучу схем и диаграмм, прежде чем написать хотя бы одну строчку кода. Сейчас всех учат тому, что нужно быстрее планировать и быстрее делать.

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

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

Самое важное качество разработчика, как и любого инженера — умение проектировать и прогнозировать возможные сценарии работы, отличные от стандартного. Что произойдет, если ответ от сервера не придет? А если придет, то вдруг он будет некорректный? Или будет идти слишком долго? Рассуждая таким образом и внося соответствующие изменения, разработчик может сделать код более стабильным. К тому же, сравнивая собственные прогнозы с проблемами, которые могут возникнуть при реальном использовании, он получает ценную обратную связь и понимает, какие из его сценариев оказались верными, какие нет, и почему это произошло.

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

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

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

Для программиста очень важно уметь фокусироваться на задаче и чем он лучше умеет это делать, и чем дольше способен оставаться в фокусе, – тем выше его результаты.

Чтобы понять, как научиться мыслить, как программист, нужно понять, как вообще мыслят программисты, и отличается ли это мышление, например, от журналистов.

Попытавшись вспомнить, как я становился программистом, а потом период, когда я им перестал быть, я пришел к следующим условным отличиям:

• Программист может найти несколько вариантов решения задачи.
• Программист может выбрать наиболее оптимальный из них.
• Программист обладает широким знанием инструментов в общем смысле (языков, алгоритмов и т.п.) для решения задачи.

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

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

Резюмируя:
1) Учимся мыслить системно. При этом обязательно помечать для себя неявные моменты.
2) Учимся выстраивать в голове (для начала можно потренироваться и на листке бумаги) цепочку (последовательность шагов действий) решения вопроса или задачи от начала и до конца.