Комментарии 24
Спасибо очень интересно!
А Стивен Кинг говорит что-нибудь о полезности четния других авторов, как это перекликается с IT?
А Стивен Кинг говорит что-нибудь о полезности четния других авторов, как это перекликается с IT?
Говорит. В частности, он пишет что надо много читать, очень много.
Говорят, что Кинг говорит, что «если у вас нет времени, чтобы читать, у вас его нет и чтобы писать».
Я тоже прочел эту книгу, и так же для себя понял, что писательство будь оно романом или кодом не такое уж и разное, с точки зрения подходов. И точно так же привожу подобные примеры собеседникам и рекомендую эту книгу к прочтению. При том она очень короткая, и благодаря отточенному слогу неторопливо проглатывается за вечер.
Еще раз убеждаюсь, самые лучшие книги являются самыми дешевыми книгами в книжном магазине. Всего 112 рублей она мне обошлась.
В любой деятельности полезна системность: структурирование работы и рабочий ритм.
А вот как и менно для себя это организовать и какими методами придерживаться — это работа кажого человека самим с собой)
А вот как и менно для себя это организовать и какими методами придерживаться — это работа кажого человека самим с собой)
Как раз недавно начал ее читать, хорошая книжка.
Хорошие параллели, кажется еще 37 signals говорили о том, что хорошего кодера видно из стиля его письма. Странно, если бы он хорошо владел кодом, не владея родной речью.
Я даже часто замечаю за собой в коде и в письмах схожие проблемы, такие как переусложненные конструкции, много оборотов выражающих разные степени уверенности (в коде это принимает вид избыточного «защитного программирования») и т.п.
Я даже часто замечаю за собой в коде и в письмах схожие проблемы, такие как переусложненные конструкции, много оборотов выражающих разные степени уверенности (в коде это принимает вид избыточного «защитного программирования») и т.п.
Что вы имеете в виду? Проверки наличия обязательных формальных параметров методов, возвращаемые значения, целостность данных, обилие if и throw, где казалось бы они не нужны?
Вроде того.
Ассерты пусть в тестах живут, а так, например, идет передача вызова с входными параметрами от публичного метода приватному, ясно, что валидацию входных данных и явное приведение типов (в основном пишу на «легких» языках) нужно делать только на внешней точке, но тут в голову закрадывается мысль, что через некоторое время что может быть вызов этого приватного метода из другого публичного метода и приватный тоже начинает обрастать проверкой.
Ассерты пусть в тестах живут, а так, например, идет передача вызова с входными параметрами от публичного метода приватному, ясно, что валидацию входных данных и явное приведение типов (в основном пишу на «легких» языках) нужно делать только на внешней точке, но тут в голову закрадывается мысль, что через некоторое время что может быть вызов этого приватного метода из другого публичного метода и приватный тоже начинает обрастать проверкой.
Это называется «концепция баррикады» — надо знать, где провести черту валидации, в «Совершенном коде» об этом писали.
Совершенный код очень хорошая книга.
Единственное, корнями она уходит во времена, когда объем сторонних библиотек, используемых при разработке, не был столь внушительным, а они сами не столь инвазивны (фреймворки, ормы и т.п.), то есть ты мог целиком строить архитектуру своего приложения в соответствии с принципами структурного программирования.
А так, например, есть данность, что конфигурация прокидывается через глобальный скоуп, соответственно обращения к ней не контролируются и каждый параметр нужно чистить при обращении из методов. Приходится либо идти на компромисс, допуская, что конфигурация более или менее корректная, если ее вызовы единичны, либо, для соблюдения баррикады, приходится писать менеджер конфигураций, который предоставит к ней «чистый» интерфейс или другие подобные прослойки для изоляции. Но при этом может получиться, что часть 3rd party обращается к ней через скоуп, собственный код через менеджер и баррикада начинает размываться.
Я к тому, что на практике достаточно сложно строго соблюдать подобные принципы.
Единственное, корнями она уходит во времена, когда объем сторонних библиотек, используемых при разработке, не был столь внушительным, а они сами не столь инвазивны (фреймворки, ормы и т.п.), то есть ты мог целиком строить архитектуру своего приложения в соответствии с принципами структурного программирования.
А так, например, есть данность, что конфигурация прокидывается через глобальный скоуп, соответственно обращения к ней не контролируются и каждый параметр нужно чистить при обращении из методов. Приходится либо идти на компромисс, допуская, что конфигурация более или менее корректная, если ее вызовы единичны, либо, для соблюдения баррикады, приходится писать менеджер конфигураций, который предоставит к ней «чистый» интерфейс или другие подобные прослойки для изоляции. Но при этом может получиться, что часть 3rd party обращается к ней через скоуп, собственный код через менеджер и баррикада начинает размываться.
Я к тому, что на практике достаточно сложно строго соблюдать подобные принципы.
А не проще тогда проверку, приведение, валидацию и прочую подготовку данных делать только в приватном методе? Пусть сам знает как готовить входящие данные и как реагировать на их отсутствие. А публичный метод может догадываться о реакции приватного по какому-нибудь сигналу. Например, по исключению или возвращаемому значению. Эта же тема затрагивается здесь habrahabr.ru/post/128397/
Для меня тут самое сложное чувствовать грань между поддержкой стабильности системы в целом и скатыванием в маниакальную проверку всего и вся.
(в основном пишу на «легких» языках) — А это на каких?
Для меня тут самое сложное чувствовать грань между поддержкой стабильности системы в целом и скатыванием в маниакальную проверку всего и вся.
(в основном пишу на «легких» языках) — А это на каких?
Как говорится, дурак умного не разумеет — подскажите мне, кто поопытней, как выбирать книгикод для чтения? В целом и применительно конкретно к C++. Как мне понять, что вот этот код — очень хорош? По части книг есть школа, родители, устоявшаяся классика.
Пример из ruby-мира: я захожу на гитхабчик, смотрю количество фолловеров у гема, смотрю примеры использования (и актуальность применения этих примеров — например, в отношении текущей версии руби) в README, смотрю частоту обновлений и объем открытых/закрытых тикетов по проекту.
Чаще всего хорошие гемы (библиотеки) не имеют конкурентов, регулярно обновляются, имеют десятки открытых и сотни закрытых тикетов и обладают большим коммьюнити. По этим параметрам можно с большой вероятностью утверждать, достоин ли код внимания.
Чаще всего хорошие гемы (библиотеки) не имеют конкурентов, регулярно обновляются, имеют десятки открытых и сотни закрытых тикетов и обладают большим коммьюнити. По этим параметрам можно с большой вероятностью утверждать, достоин ли код внимания.
Я бы тут опирался на то, как писали K&R, вроде у них даже где-то упомянается, что хороший код обязательно должен быть хорошо читаемым (не удивительно, его и поддерживать ведь надо будет). По большому счету их советы по оформлению кода для Си можно использовать и для С++.
Про «Извлечь артефакт из породы» — как я помню эту историю, у Огюста Родена однажды спросили, в чём, собственно, заключается мастерство скульптора, на что он ответил: «Берём глыбу мрамора и отсекаем лишнее».
Жаль, что нет опции «лучшее из избранного», а то, я бы добавил в такую папку.
Сам, как любитель писать разные статьи и на пол пути к изданию книги, во многом согласен с автором.
Есть процесс написания… научной фантастики, популярных статей, узко-специализированных публикаций или кода… и если этот процесс поставлен эффективно, то он подчиняется одинаковым принципам, которые диктует сама жизнь…
Как любитель фантастики и поклонник Стивена Кинга, восхищаюсь его книгой. Спасибо автору, за столь интересную аналогию.
Сам, как любитель писать разные статьи и на пол пути к изданию книги, во многом согласен с автором.
Есть процесс написания… научной фантастики, популярных статей, узко-специализированных публикаций или кода… и если этот процесс поставлен эффективно, то он подчиняется одинаковым принципам, которые диктует сама жизнь…
Как любитель фантастики и поклонник Стивена Кинга, восхищаюсь его книгой. Спасибо автору, за столь интересную аналогию.
Отличная книга! Прочитал взахлёб. Книга автобиографичная, но Кинг в ней довольно много пишет о личной эффективности писателя на собственном примере. О распорядке дня, концентрации и т.д. Да и вообще история жизни у него интересная, поэтому читаешь с удовольствием.
Тоже читал эту книгу.
Нравится мысль: Если вы хотите научиться писать — вам нужно научиться читать. Читайте всегда, везде, при первой возможности. Если у вас нет времени, чтобы читать — у вас не будет времени на написание.
Еще очень важная мысль из книги: Интенсивность важнее тщательности.
Пишите каждый день, уделяйте каждое утро, пишите строго какое-то время, но вы должны работать каждый день, пусть даже в какой-то день выйдет не очень плодотворная работа. И это правильно — как утверждает Стивен, если вы перестаете писать, вы забываете о созданном мире, вы теряете нить и больше не сможете вернуться к написанию. ну и обязательно работать с закрытой дверью, в любимом месте, чтобы ничего не отвлекало!
Ну ведь с кодом точно так же, верно?
Нравится мысль: Если вы хотите научиться писать — вам нужно научиться читать. Читайте всегда, везде, при первой возможности. Если у вас нет времени, чтобы читать — у вас не будет времени на написание.
Еще очень важная мысль из книги: Интенсивность важнее тщательности.
Пишите каждый день, уделяйте каждое утро, пишите строго какое-то время, но вы должны работать каждый день, пусть даже в какой-то день выйдет не очень плодотворная работа. И это правильно — как утверждает Стивен, если вы перестаете писать, вы забываете о созданном мире, вы теряете нить и больше не сможете вернуться к написанию. ну и обязательно работать с закрытой дверью, в любимом месте, чтобы ничего не отвлекало!
Ну ведь с кодом точно так же, верно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стивен Кинг «Как писать программный код»