avva | о сложности и эстетике борьбы с ней (Reply)

Джонатан Блоу (автор знаменитых игр Braid - очень люблю - и The Witness - не играл) пишет в Твиттере интересное (перевод с английского):

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

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

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

Но, конечно, это недооценка реальной ценности такого навыка".

Добавлю от себя то, как я это понимаю.

Предположим, мы работали, дизайнили, кодили, и написали в конце концов какую-то софтверную систему (программу, библиотеку, сервис, приложение, неважно) A. У системы A есть какой-то дизайн, разные ее части как-то взаимодействуют итд.

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

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

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

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

Вот такого программиста немедленно нанял бы Джонатан Блоу.