![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
как он дышит, так и пишет
Давно уж я заметил, что по коду можно много сказать о том, кто его написал. Видел я коды параноидальные, которые стремились проверить все возможные условия, поймать все возможные внештатные ситуации, включая случай, если единица равняется нулю. Видел я коды, страдающие рассеянием внимания, в которых ни одна функция не делала что-то одно, а делала несколько не связанных дел. Попадались коды, чрезмерно полагающиеся на окружение, и коды, страдающие аутизмом в той или иной степени. Имена переменных многое могут рассказать, и названия функций. В одном коде все сущности именовались "чего-нибудь handler", а в другом - "чего-нибудь engine", хотя в них очень мало что двигалось на самом деле. Видел и восхищался кодами, кристалльно ясными и четкими; видел коды безумно путаные, сводившиеся к почти ничему.
Про себя я знал, что мой код несколько излишне педантичен и страдает гигантоманией. Если я программирую велосипед, то у него будет трехдюймовая броня и возможность легко приделать пятое колесо и вертикальный взлет, хотя даже до мопедного моторчика стартап порой не доходил. Поскольку пишу я быстро, то пользы от такого подхода обычно выходит заметно больше, чем затрат. За что меня и ценят. Но на первых порах довольно трудно мне отвечать на вопрос, чем именно я вот сейчас занимаюсь - что это за набор утилит такой, и почему иерархия суперклассов такая развесистая, а сами суперклассы почти пустые.
А вот сегодня напарники открыли мне глаза на такой интересный факт. В моем коде частенько попадается то, что назвали мне "артефактами". Это, конкретно, когда функция внутри себя делает что-то совсем неочевидное для ее пользователя, и если пользователь этого не знает, как он и должен не знать, то он может столкнуться с довольно неприятными сюрпризами. Какое-нибудь свойство в аксессоре своем скрыто инициализируется, и для того, чтобы проверить, не проинициализировалось ли оно - например, чтобы его высвободить - приходится публиковать частное поле, стоящее за этим свойством - согласитесь, дизайн, мягко говоря, странный. Но он совершенно не был странным для меня, когда я это писал.
То есть, в мире моего кода предметы слишком много на себя берут, и тем, кто этими предметами пользуется, становится малость не по себе. Слишком умные предметы, заумные даже.
Я сказал: наверно, это говорит о склонности делегировать ответственность. Мне сказали, что это само по себе стремление для программиста правильное, но вот так все-таки делать не надо. Надо переделать, сделать код более прозрачным и управляемым.
Вот, пошел думать.
Про себя я знал, что мой код несколько излишне педантичен и страдает гигантоманией. Если я программирую велосипед, то у него будет трехдюймовая броня и возможность легко приделать пятое колесо и вертикальный взлет, хотя даже до мопедного моторчика стартап порой не доходил. Поскольку пишу я быстро, то пользы от такого подхода обычно выходит заметно больше, чем затрат. За что меня и ценят. Но на первых порах довольно трудно мне отвечать на вопрос, чем именно я вот сейчас занимаюсь - что это за набор утилит такой, и почему иерархия суперклассов такая развесистая, а сами суперклассы почти пустые.
А вот сегодня напарники открыли мне глаза на такой интересный факт. В моем коде частенько попадается то, что назвали мне "артефактами". Это, конкретно, когда функция внутри себя делает что-то совсем неочевидное для ее пользователя, и если пользователь этого не знает, как он и должен не знать, то он может столкнуться с довольно неприятными сюрпризами. Какое-нибудь свойство в аксессоре своем скрыто инициализируется, и для того, чтобы проверить, не проинициализировалось ли оно - например, чтобы его высвободить - приходится публиковать частное поле, стоящее за этим свойством - согласитесь, дизайн, мягко говоря, странный. Но он совершенно не был странным для меня, когда я это писал.
То есть, в мире моего кода предметы слишком много на себя берут, и тем, кто этими предметами пользуется, становится малость не по себе. Слишком умные предметы, заумные даже.
Я сказал: наверно, это говорит о склонности делегировать ответственность. Мне сказали, что это само по себе стремление для программиста правильное, но вот так все-таки делать не надо. Надо переделать, сделать код более прозрачным и управляемым.
Вот, пошел думать.