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

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

Что ж, это правда, что цейтнот разработчиков приводит к тому, что они пишут сложный код. Однако сроки не должны усложнять работу. Вместо того, чтобы сказать: «Этот крайний срок не позволяет мне писать простой код», можно было бы также сказать: «Я недостаточно быстрый программист, чтобы сделать это простым». То есть, чем быстрее вы работаете как программист, тем меньше дедлайны должны влиять на качество вашего кода.

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

Нет, это вовсе не волшебство и не врожденное. На самом деле существует всего одно простое правило, соблюдение которого в конечном итоге полностью решит проблему:

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

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

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

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

Понимание

Буквально на днях мне потребовались часы, чтобы написать то, что должно было быть действительно простым сервисом. Я постоянно останавливался, чтобы подумать об этом, пытаясь понять, как он должен себя вести. Наконец я понял, что не понял одну из входных переменных основной функции. Я знал имя его типа, но я никогда не читал определение типа — я действительно не понимал, что это за переменная (слово или символ) означало.

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

Как только я просмотрел код и документацию типа, все стало ясно, и я написал этот сервис как демон (каламбур).

Это может произойти практически бесконечным количеством способов. Многие люди погружаются в язык программирования, не зная, что на самом деле означают (, ), [, ], {, }, +, * и % на этом языке. Некоторые разработчики не понимают, как на самом деле работает компьютер.

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

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

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

Рисунок

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

Вам нужно что-то, на что вы можете посмотреть или каким-то образом воспринять вне себя. Это форма понимания, но она настолько особенная, что мне захотелось выделить ее отдельно.

Начиная

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

Часто самый простой фрагмент кода, с которого можно начать, является «ядром» приложения.

Например, если бы я собирался написать приложение для YouTube, я бы начал с видеоплеера. Думайте об этом как об упражнении в непрерывной доставке — сначала напишите код, который фактически создаст продукт, независимо от того, насколько этот продукт глупый или маленький. Видеоплеер без какого-либо другого пользовательского интерфейса — это продукт, который делает что-то полезное (воспроизводит видео), даже если он еще не является полным продуктом.

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

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

Пропуск шага

Другая специализированная проблема понимания возникает, когда вы пропустили какой-то шаг в правильной последовательности разработки. Например, предположим, что наш объект Bike зависит от объектов Wheels, Pedals и Frame. Если вы попытаетесь написать весь объект Bike без написания объектов Wheels, Pedals или Frame, вам придется много подумать об этих несуществующих классах. С другой стороны, если вы пишете класс Wheels, когда класса Bike вообще нет, вам, возможно, придется много думать о том, как класс Wheels будет использоваться классом Bike.

Не перепрыгивайте этапы разработки вашей системы и не ожидайте, что вы будете продуктивны.

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

Физические проблемы

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

Это не так распространено, как описанная выше проблема «понимания», поэтому сначала всегда ищите то, что вы не совсем поняли. Если вы действительно уверены, что поняли все, то кандидатом могут быть физические проблемы.

Отвлечения

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

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

неуверенность в себе

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

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

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

Ложные идеи

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

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

Предостережение

Все вышеперечисленное — секрет того, как стать быстрым программистом, когда вы сидите и пишете код. Если вы целый день читаете электронную почту и ходите на встречи, то никакого программирования не происходит — это другая проблема.

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

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