Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Писать более понятный код. За счет хороших комментариев, правильного именования переменных, простого интерфейса и реализации.
Это вот все имеет мало смысла начиная с определенного уровня сложности. Сложность, в том числе, возникает, когда есть много вариантов, веток, связей, взаимодействий между компонентами, и т.п. В динамике, в том числе.
Хорошие комментарии и правильное именование возникновению такого рода сложности не мешают ни сколечки, потому что они описывают лишь статический аспект кода. А «простой интерфейс и реализация» — это вообще ни о чем, на этот глобус можно любую сову натянуть. Это совет из категории «чтобы снизить сложность, пишите проще». Ага, а то мы сами не знали?
Реальная же борьба со сложностью лежит скорее в другой плоскости — например, в строгой типизации, чтобы нельзя было (лучше с проверкой во время компиляции) вызвать один компонент из другого неправильным способом. Иммутабельность — чтобы нельзя было изменить значение (в том числе из другого потока) непредсказуемым образом. Чистые функции, которые помимо прочего дают нам уверенность, что некоторые преобразования кода можно проделать, и он останется валидным.
Человек честно пишет:
Она позволила структурировать знания, накопленные мною за 3 года работы разработчикомдумаю, еще лет через 7 он напишет уже более адекватную книгу :-)
Но неопытным его тоже не назовешь. Оустерхаут — разработчик скриптового языка Tcl. Может, на самом деле не 3 года, а 30? К моменту написания книги ему было 63 года.
Не, ну читать книги можно и с нулевым опытом. Другое дело, что 3 года возможно маловато, чтобы понять для себя все полезное, что в произвольной книге есть — потому что опыт нужен и для понимания того, что на самом деле важно.
В том то и смысл, чтобы искать решение, при котором связей между модулями будет меньше. Иначе придется поддерживать больше кода, при изменении кода в одной части, исправлять другую.
Простой интерфейс и реализация — это не бред. Сам часто встречаю в пулл реквестах слишком сложный интерфейс, когда например передают лишние данные в метод. Или приходится всегда вызывать несколько методов по очереди у одного объекта, хотя можно было сделать только один.
С реализацией тоже самое. Например, бывает иногда добавляют проверки, которые никогда не сработают. И зачем тогда они нужны, в них придется больше вникать при попытке понять реализацию и возникнет больше вопросов, почему это здесь.
На самом деле да, нужно просто писать проще. Очень банально, но этого и не хватает для хорошего дизайна. А уже как писать проще, об этом книга.
Простой интерфейс и реализация — это не бред. Сам часто встречаю в пулл реквестах слишком сложный интерфейс, когда например передают лишние данные в метод. Или приходится всегда вызывать несколько методов по очереди у одного объекта, хотя можно было сделать только один.
С реализацией тоже самое. Например, бывает иногда добавляют проверки, которые никогда не сработают. И зачем тогда они нужны, в них придется больше вникать при попытке понять реализацию и возникнет больше вопросов, почему это здесь.
На самом деле да, нужно просто писать проще. Очень банально, но этого и не хватает для хорошего дизайна. А уже как писать проще, об этом книга.
>Он выделяет 2 пути борьбы со сложностью:
Ну выже сами выделили вот это. Я предполагаю, что в хорошей книге эти два пункта будут раскрыты далее и будут реальными путями борьбы. А они не — во всяком случае я написал, почему первый не.
>Простой интерфейс и реализация — это не бред.
Нет конечно. Но дело в том, что этот совет неконструктивен, именно потому, что не определяет, что такое сложный. Не показывает, как измерять. А то что нельзя померять — нельзя ни повысить толком, ни понизить.
>А уже как писать проще, об этом книга.
Ну то есть дальше все же раскрыто, что такое проще?
Ну выже сами выделили вот это. Я предполагаю, что в хорошей книге эти два пункта будут раскрыты далее и будут реальными путями борьбы. А они не — во всяком случае я написал, почему первый не.
>Простой интерфейс и реализация — это не бред.
Нет конечно. Но дело в том, что этот совет неконструктивен, именно потому, что не определяет, что такое сложный. Не показывает, как измерять. А то что нельзя померять — нельзя ни повысить толком, ни понизить.
>А уже как писать проще, об этом книга.
Ну то есть дальше все же раскрыто, что такое проще?
Проще — значит менее сложно. Я в этих заметках описал что значит сложно через то, как она проявляется и по какой причине возникает.
Проще, значит разработчику легче работать с этим кодов в будущем, легче его понять, меньше и быстрее переделывать и меньше ошибок возникнет в процессе использования модулей. Автор приводит много примеров разных ситуаций когда можно сделать проще.
Проще, значит разработчику легче работать с этим кодов в будущем, легче его понять, меньше и быстрее переделывать и меньше ошибок возникнет в процессе использования модулей. Автор приводит много примеров разных ситуаций когда можно сделать проще.
>Автор приводит много примеров
Ну возможно. Я не утверждаю, что книга плохая, я лишь говорю о том, что вы (с автором или сами) этот вопрос раскрыли на мой взгляд слегка не с той стороны. И неполно. Опять же — я сужу по обзору, а не по тексту книги.
Это не значит, что все прям плохо — мой первый коммент был скорее дополнением, попыткой взглянуть на сложность с другой стороны.
Ну возможно. Я не утверждаю, что книга плохая, я лишь говорю о том, что вы (с автором или сами) этот вопрос раскрыли на мой взгляд слегка не с той стороны. И неполно. Опять же — я сужу по обзору, а не по тексту книги.
Это не значит, что все прям плохо — мой первый коммент был скорее дополнением, попыткой взглянуть на сложность с другой стороны.
-
Ну это хорошая идея, без дураков. Просто даже если вы не порождаете ненужных сущностей, в крупном проекте вполне может быть дофига сущностей нужных. Сложность — она иногда объективно имеет место.
Ну т.е. я что имел в виду:
— нужно контролировать не только сущности, но и число связей между ними, и минимизировать и его тоже (тем более что у него тенденция расти быстрее). Ну или просто не забывать считать и связи тоже при оценке сложности проекта
— делать эти связи более формальными и верифицируемыми (строгая типизация где-то из этой оперы)
— упрощать жизненный цикл сущностей (иммутабельность тут применима)
— чистые функции — потому что связь между функцией и потребителем более очевидна и проста
Очевидно, есть и другие способы контроля сложности. Я просто отвечал на фрагмент текста, где говорилось о именовании переменных и комментариях, и на мой взгляд это немного низкий уровень.
Ну т.е. я что имел в виду:
— нужно контролировать не только сущности, но и число связей между ними, и минимизировать и его тоже (тем более что у него тенденция расти быстрее). Ну или просто не забывать считать и связи тоже при оценке сложности проекта
— делать эти связи более формальными и верифицируемыми (строгая типизация где-то из этой оперы)
— упрощать жизненный цикл сущностей (иммутабельность тут применима)
— чистые функции — потому что связь между функцией и потребителем более очевидна и проста
Очевидно, есть и другие способы контроля сложности. Я просто отвечал на фрагмент текста, где говорилось о именовании переменных и комментариях, и на мой взгляд это немного низкий уровень.
Что-то мне кажется, что слово «философия» в названии добавлено исключительно для хайпа (и, скорее всего, даже не автором). Что бы претендовать на такое название в книге должен быть хотя бы намек на систему знаний, а судя даже из минимальной рецензии ее нет.
И критиковать надо прямо с базового понятия. Непонятно с чего автор считает понятие «сложность» присущем коду (кстати, код, автор, тоже не определил, но тут хоть более-менее понятно, что речь про что-то привычное ООПшное, а не, например, SQL). Но это явная ошибка, сложность тут однозначно выступает как проблема восприятия исходников человеком, а это вынуждает говорить не только о коде, а еще и о самих программистах. Дальше больше. Не определив метрику «сложности» (и, похоже, даже не попытавшись) автор пытается давать советы, как ее уменьшить. А уж после этого неизбежно возникнут вопросы, с чего бы мне следовать совету (к примеру, про комментарии), если я считаю, что это наоборот, усложняет код (ага, привет, потерянная часть «человек»)?
В общем надо было назвать книгу «Бест практис» и не выдумывать про сложность и пытаться сделать умное лицо.
И критиковать надо прямо с базового понятия. Непонятно с чего автор считает понятие «сложность» присущем коду (кстати, код, автор, тоже не определил, но тут хоть более-менее понятно, что речь про что-то привычное ООПшное, а не, например, SQL). Но это явная ошибка, сложность тут однозначно выступает как проблема восприятия исходников человеком, а это вынуждает говорить не только о коде, а еще и о самих программистах. Дальше больше. Не определив метрику «сложности» (и, похоже, даже не попытавшись) автор пытается давать советы, как ее уменьшить. А уж после этого неизбежно возникнут вопросы, с чего бы мне следовать совету (к примеру, про комментарии), если я считаю, что это наоборот, усложняет код (ага, привет, потерянная часть «человек»)?
В общем надо было назвать книгу «Бест практис» и не выдумывать про сложность и пытаться сделать умное лицо.
Непонятно с чего автор считает понятие «сложность» присущем коду
2.1 Complexity defined
For the purposes of this book, I define “complexity” in a practical way. Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
вся глава 2.1 на эту тему
2.1 Complexity defined
For the purposes of this book, I define “complexity” in a practical way. Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
вся глава 2.1 на эту тему
Сложность это все, что мешает понимать и модифицировать. Раз «все», значит стройка за окном тоже мешает? Или недосып? А отсутствие профильного образования? И ведь любая из этих причин может оказать гораздо большее влияние, чем непосредственно архитектура кода. И я не придираюсь, без осознания того, что же такое «сложность» нельзя ее измерить, а следовательно и сравнивать два варианта, можно только какими-то субъективными ощущениями оперировать, типа так лучше, чем эдак.
Книга может и хорошая, не знаю. Но явно не более чем сборник советов.
Книга может и хорошая, не знаю. Но явно не более чем сборник советов.
С практической точки зрения, чтобы уменьшить сложно не нужно её измерять. Достаточно понимать, что один подход в решении проще другого. У сложности есть множество граней, их автор и показывает. В чем то код может быть сложнее, а в чем то проще. Меньше зависимостей — это проще, поэтому если я могу их уменьшить, значит я уменьшаю сложность.
Насчет стройки и недосыпа, автор в книге же четко написал
Т.е. он пишет про сложность связанную со структурой IT системы.
Насчет стройки и недосыпа, автор в книге же четко написал
Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
Т.е. он пишет про сложность связанную со структурой IT системы.
С практической точки зрения, чтобы уменьшить сложно не нужно её измерять. Достаточно понимать, что один подход в решении проще другого.
Так я и говорю, сборник советов.
Ну да, слона-то
related to the structure of a software systemя и не приметил :) Но даже в этом случае выбросив человека автор неявно подразумевает наличие у программиста определенных знаний и навыков (наверняка близких к тем, которыми он сам обладает). А это на сложность понимания и модификации очень сильно влияет, опять вспомню пример про комментарии.
Да, здесь достаточно много советов, но это не говорит о том, что это только сборник советов. Вы указали что это это
не более чем сборник советовНа основании чего вы так решили?
Отзыва, конечно. Разве это не очевидно?
Но вообще, чем дальше, тем больше убеждаюсь, что системы знаний там нет.
Но вообще, чем дальше, тем больше убеждаюсь, что системы знаний там нет.
«там» это где?
В книге.
а вы ее читали?
Нет.
слушайте я конечно знаю анекдот про рабиновича котормоу хаим карузо по телефону напел и рабинович понял что карузо — халтурщик, фальшифит, сипит и вообще в ноты не попадает. но не ожидал что этот анекдот только что воплотится в реальность
Ну я же не виноват, что вы вместе с автором поста очень успешно выступаете в роли Рабиновича.
я?????
Ну а кто цитату из книги кинул?
так это ж всего два предложения из книги. которую вы не читали.
С удовольствием послушаю какие понятия рассматриваются в книге, как они взаимодействуют и как это все отражается на сложности.
Ну вот для примера возьмем «тактическое программирование» и «стратегическое программирование». Судя по «определениям» если я на секунду задумался (но не факт что сделал) над выделением копипасты в отдельную функцию, я уже стратегически программирую? А если я бездумно леплю в новом типовом проекте MVC, то это уже тактическое?
Вот что-то мне кажется, что все сложнее.
Ну вот для примера возьмем «тактическое программирование» и «стратегическое программирование». Судя по «определениям» если я на секунду задумался (но не факт что сделал) над выделением копипасты в отдельную функцию, я уже стратегически программирую? А если я бездумно леплю в новом типовом проекте MVC, то это уже тактическое?
Вот что-то мне кажется, что все сложнее.
> С удовольствием послушаю
нет уж вы лучше почитайте
нет уж вы лучше почитайте
Мои заметки возможно действительно выглядят как набор советов, но какой смысл описывать всю систему знаний.
Если я начну все это расписывать, то ещё одна книга получится. Если вам это правда интересно, прочтите книгу.
Если я начну все это расписывать, то ещё одна книга получится. Если вам это правда интересно, прочтите книгу.
Злые вы :) Вот как вообще читать книгу после такой антирекламы? :)
С моей точки зрения, если бы книга претендовала на научность, в ней должно было бы быть что-то типа такого (могу ошибаться, просто направление мысли).
Сложность меряется в затраченном времени на поддержании работоспособности системы на всем в течении всего жизненного цикла.
Стратегическое и тактическое программирование — парные категории (т.е. не имеющие смысла друг без друга) и характеризующиеся смещением объема сложности к началу и соответственно концу жизненного цикла, в чистом (предельном) виде на практике, естественно, не встречаются.
И вот из трех определений сразу можно делать выводы, хочешь быстрее — используй тактическое, хочешь дешевле — используй стратегическое (обычно так получается). Аналогично с использованием старого кода, если нужно прототип, используй тактическое. Сразу становится понятно почему стартапы тяготеют к тактическому.
Дальше делим приемы и методики на тактическое/стратегическое, можно с проставлением различных коэффициентов.
Можно еще как-то делить приемы, например по степени загруженности отделов (проектирование, программирование, тестирование и т.д.) или еще как-то.
С моей точки зрения, если бы книга претендовала на научность, в ней должно было бы быть что-то типа такого (могу ошибаться, просто направление мысли).
Сложность меряется в затраченном времени на поддержании работоспособности системы на всем в течении всего жизненного цикла.
Стратегическое и тактическое программирование — парные категории (т.е. не имеющие смысла друг без друга) и характеризующиеся смещением объема сложности к началу и соответственно концу жизненного цикла, в чистом (предельном) виде на практике, естественно, не встречаются.
И вот из трех определений сразу можно делать выводы, хочешь быстрее — используй тактическое, хочешь дешевле — используй стратегическое (обычно так получается). Аналогично с использованием старого кода, если нужно прототип, используй тактическое. Сразу становится понятно почему стартапы тяготеют к тактическому.
Дальше делим приемы и методики на тактическое/стратегическое, можно с проставлением различных коэффициентов.
Можно еще как-то делить приемы, например по степени загруженности отделов (проектирование, программирование, тестирование и т.д.) или еще как-то.
> Раз «все», значит стройка за окном тоже мешает? Или недосып?
и даже то что вы книгу не читали а пытаетесь выводы делать — тоже мешает
и даже то что вы книгу не читали а пытаетесь выводы делать — тоже мешает
книга хорошая. сам хотел сделать обзор и рекомендовать ее, но вот как всегда меня опередили.
Согласен со всем, кроме наследования. Не понимаю, почему его «не рекомендуют». Для меня всегда очевидно, должен ли обьект наследовать другой или нет. Например, груша должна наследовать фрукт, а яблоко не должно наследовать грушу. Иная реализация (например композиция) в случае, когда нужно наследовать, только усложняет код.
Проблема в том, что если у вашего фрукта 100500 наследников, то при изменении фрукта, может непредсказуемо измениться поведение какого нибудь из наследников. И тогда придется переделывать ещё и их.
Конечно бывают понятные примеры, когда можно использовать наследование, но это часто не так. Например, стоит ли делать родительский класс для репозиториев сущностей из базы данных? А если у дочернему классу не нужны методы родителя? Скорее всего нет.
Конечно бывают понятные примеры, когда можно использовать наследование, но это часто не так. Например, стоит ли делать родительский класс для репозиториев сущностей из базы данных? А если у дочернему классу не нужны методы родителя? Скорее всего нет.
Хоть миллион наследников будет, если все по-прежнему фрукты — проблем не будет. Если возникает проблема у наследников, значит либо фрукт уже не совсем фрукт, либо в наследники уже капуста затусовалась.
Делать ли родительский класс для репозиториев — зависит от задумки реализации, но когда есть сомнения — значит наследования не нужно.
Делать ли родительский класс для репозиториев — зависит от задумки реализации, но когда есть сомнения — значит наследования не нужно.
но когда есть сомнения — значит наследования не нужноя согласен, об этом и говорится в заметках. Понятное дело, что от наследования бывает польза. Просто пример с фруктами очень простой. Часто не так очевидно, что наследование здесь подходит. Поэтому и нужно быть с ним очень осторожными. От неправильного использования наследования может сильно усложниться код.
Прямо сейчас читаю эту книгу. Удивительно, но сама книга читается гораздо проще чем все краткие выжимки по ней. При том, что она на английском.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заметки по книге «Философия разработки ПО»