Хороший разработчик и его образ мышления, часть 1

Перевод статьи «Learn the fundamentals of a good developer mindset in 15 minutes».

«Сложно сделать даже маленькое изменение».

«Исправляешь один баг – тут же появляется другой».

«Из-за сложности кода практически невозможно добавить новый функционал».

«Придется все переписывать с нуля».

Знакомые мысли, не правда ли?

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

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

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

Вот ключевые вещи, характерные для типа мышления хорошего разработчика.

1. Понимание предназначения программного обеспечения

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

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

Разработчики, которые не понимают назначения программ, пишут плохие программы. Что такое плохие программы? Это сложные системы, которые не очень-то полезны людям.

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

2. Цели проектирования программного обеспечения

Каждый программист является проектировщиком.

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

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

Это подводит нас к главному предназначению проектирования ПО.

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

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

3. (Не)понимание

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

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

Понимание это ключевая разница между плохим и хорошим разработчиком.

Плохие разработчики не понимают, что делают, а хорошие понимают. Вот и все.

4. Простота

«Простота это высочайшая сложность», – Леонардо да Винчи.

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

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

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

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

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

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

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

Сложность не имеет ничего общего с интеллектом, в отличие от простоты», – Ларри Боссиди.

Насколько простым нужно быть? До идиотизма.

5. Сложность

«Контролирование сложности это самая суть программирования», – Брайан Керниган.

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

Но и это не конец.

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

Итак, как же вы стали жертвой этой истории? Да какая разница. Лучше выяснить, как избежать подобных ситуаций в дальнейшем.

Как предотвращать нарастание сложности проекта

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

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

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

Ваша главная задача – контролировать сложность, а не создавать ее.

6. Поддержка

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

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

Все изменения нужно будет поддерживать.

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

Необходимо иметь в виду простое правило:

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

7. Последовательность

Последовательность это важная составляющая часть простоты. Если вы в одном месте делаете что-то определенным образом, поступайте так же везде. Например, если вы называете переменную thisIsVariable, то все ваши переменные должны именоваться сходным образом (otherVariable, anAnotherVariable и т. д., но не other_variable).

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

«В любом командном спорте лучшие команды обладают последовательностью и «химией»», – Роджер Стобак.

8. Расстановка приоритетов

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

Есть три важных фактора, которые помогут вам ответить на эти вопросы и выбрать правильное направление:

• Желательность изменения (D) (насколько сильно вы хотите внести это изменение?)
• Ценность изменения (V) (насколько это изменение поможет вашим пользователям, насколько большую пользу оно им принесет?)
• Усилия, необходимые для осуществления изменения (E) (сколько работы потребуется для осуществления этого изменения?)

Формула довольно проста: D=V/E

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

Расставляя приоритеты в своей работе, следуйте правилу:

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

9. Решение проблем

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

«Если вы не можете объяснить что-то простыми словами, вы это «что-то» не понимаете», – Ричард Фейнман.

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

Прежде чем действовать, думайте.

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

10. «Достаточно хорошо» это прекрасно

«Лучшее – враг хорошего», – Вольтер.

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

Разработчики не отдают себе отчета в том, во что обойдется их стремление к совершенству, и не фокусируются на том, что именно от них ожидается.

И я скажу вам, к чему это приводит. С таким подходом вы:

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

Вам это нужно? Я думаю, нет. Как же следует поступать?

Начинайте с малого, а затем расширяйте.

Вам поможет непрерывное проектирование. Вот как вы могли бы применить его в разработке калькулятора:

1. Планирование системы, выполняющей только сложение и ничего больше.
2. Реализация.
3. Улучшение уже существующего дизайна системы, чтобы можно было добавить другие операции.
4. Планирование реализации вычитания и повторение шагов 2 и 3.
5. Планирование реализации умножения и повторение шагов 2 и 3.
6. Планирование реализации деления и повторение шагов 2 и 3.

Продолжение читайте здесь.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]