Не соглашусь. Когда я прочитал абзац и приступаю к следующему, я часто даже не подозреваю о том, что прочитал секунд двадцать назад. А когда приступаю к новому абзацу, то содержание старого я уже знаю. Эдакий стек обработки смысла прочитанных предложений.
Я ожидал действительно чего-то «сложного», но для понимания хватило и одного прочтения статьи. Давно, ещё при игре в майнкрафт задавался вопросом генерации случайного лабиринта «на ходу», используя ненормальное программирование на командных блоках. Возможно, тогда читал что-то по этой теме, поэтому-то и статья легко «пошла».
Очень интересно почитать действительно сложные вещи, жду следующей статьи, спасибо.
Вот это действительно заряд бодрости! Правда, на ночь глядя, но всё равно потрясающая статья. Благодарю за перевод, уверенность в своих силах точно возросла на порядок!
В теории это может выглядеть хорошо. Но мне, как начинающему разработчику, больше интересны примеры, которые я пока что не могу придумать.
Например, когда я впервые сел писать в «ООП-стиле», как мне казалось, я быстро скатился до использования одного божественного объекта для всей задачи. Да, я как-то пытался разбивать её на мелкие части, как-то осмысленно объединять в блоки процедур, но конечный результат меня не порадовал.
В итоге я увидел, что код можно было бы написать короче и проще, используя несколько объектов, а не логических блоков с процедурами.
Конечно, цель статьи, как мне кажется, звучит так: «Пишите хороший код сразу, по возможности». Но об этом написана уже не одна серьёзная книга.
Можно спросить Вас о методах, которые Вы сами применяли для «постепенного» очищения не совсем приятного кода? Может быть, всё дело в шаблонах проектирования? В книге Стефана К. Дьюхэрста так и говорится: «Множество проблем сопровождения возникает из-за игнорирования общепринятых шаблонов проектирования».
Почему-то, зная русский язык, многоточие всегда ассоциируется с незавершённостью. Как вообще могла возникнуть мысль, что это не отличный символ для сокрытия в себе тонны полезной информации?
За статью спасибо — буду рекомендовать иностранным друзьям. Но я ожидал, что тема будет раскрыта намного шире.
Очень интересно почитать действительно сложные вещи, жду следующей статьи, спасибо.
Например, когда я впервые сел писать в «ООП-стиле», как мне казалось, я быстро скатился до использования одного божественного объекта для всей задачи. Да, я как-то пытался разбивать её на мелкие части, как-то осмысленно объединять в блоки процедур, но конечный результат меня не порадовал.
В итоге я увидел, что код можно было бы написать короче и проще, используя несколько объектов, а не логических блоков с процедурами.
Конечно, цель статьи, как мне кажется, звучит так: «Пишите хороший код сразу, по возможности». Но об этом написана уже не одна серьёзная книга.
Можно спросить Вас о методах, которые Вы сами применяли для «постепенного» очищения не совсем приятного кода? Может быть, всё дело в шаблонах проектирования? В книге Стефана К. Дьюхэрста так и говорится: «Множество проблем сопровождения возникает из-за игнорирования общепринятых шаблонов проектирования».
За статью спасибо — буду рекомендовать иностранным друзьям. Но я ожидал, что тема будет раскрыта намного шире.