elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
О программистах и компромиссах программирования
elizarov

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

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

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

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

При увеличении степеней свободы программиста, пространство возможных решений значительно увеличивается. Поставите одну и ту же нетривиальную задачу двум группам программистов, и получите существенно различный код. Будет ли какое либо из этих решений лучше? Совершенно необязательно. Вся сложность в том, что понятие "хорошего кода" невозможно формализовать (один из аспектов этого я затронул в заметке "Эффективный vs хороший"). Аспектов, по которым одно программное обеспечение отличается от другого, очень много, и зачастую решение, которые выигрывает в одном аспекте, проигрывает в каком-то другом. Программисту всегда приходится принимать компромиссные решения.

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

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

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

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


  • 1
А есть ли какие-то реальные примеры вот этих вот мыслей? Я с ними согласен полностью, но вокруг много (в том числе и людей, которые рядом работают), которые считают иначе и которые приходят к этим же мыслям очень медленно и болезненно.

А были бы примеры, веселые и грустные истории из жизни — будет проще рассказывать

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

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

  • 1
?

Log in

No account? Create an account