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

Легко для кого?

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

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

Преследуя простой

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

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

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

В заключении

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

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

Если вы хотите послушать это выступление, перейдите по этой ссылке (1:01:26).

Типа к вам скорее!