Comments 4
Очень хороший перевод, спасибо!
Самый главный враг любой грязи — это солнечный свеВот про этот самый солнечный свет и хотелось бы прочитать больше всего, потому как, наука, получается, ничего не смогла дать индустрии разработки программного обеспечения. Если бы существовала теория создания программных систем, то на практике применялись бы её методы и модели. А так, получается, что годы усилий в отрасли под общем названием Computer Science прошли впустую. А если взять публикации за различные годы, то можно обнаружить обсуждения практически одних и тех же вопросов (с точностью до замены названий операционных систем, языков программирования, программных библиотек и текущих модных аббревиатур).
КОМОК ГРЯЗИ в программном коде всегда начинается с КОМКА ГРЯЗИ в размышлениях и рассуждениях, когда себе можно позволить любую сентенцию, любое произвольно взятое сравнение и соединение очередного ужа с очередным ежом и, при этом, не нести никакой ответственности за свои слова. Сколько было высказано всяких предложений и предложено всяких методик разработки программного обеспечения, но никто не может признаться, что в провале проекта повинно либо усиленное рвение по исполнению методики, либо неполная реализация той же методики, и всё это — при отсутствии какого-либо теоретического (хотя бы) критерия качества предлагаемой методики!
Но если критерием истины, всё-таки, является практика, то почему мы не читаем (вместо рекламных релизов и, так сказать, историй победителей) подробные изложения реального опыта разработки программного обеспечения? Почему здесь не применяются те же подходы, что и при публикации результатов научных исследований? Представьте, Вы читаете о том, с какими реальными вопросами и проблемами сталкиваются конкретные разработчики, к каким решениям они приходят, какие, вообще, возникают варианты, какие критерия отбора оптимальных вариантов предлагается и что позволяет, наконец, достичь хорошего результата. При этом, отрицательный опыт (которого будет сначала очень много) будет служить хорошую службу, поскольку он позволяет будущим разработчикам не ходить по тупиковым дорожкам. Но кто будет рассказывать о своих неудачах?
А задача-то ставится до ужаса просто и «примитивно»: что такое компонент? чем использование компонентов лучше, чем создание приложений? как следует разрабатывать программное обеспечение, чтобы собирать его из компонентов?
Универсальной теории разработки всего, к сожалению не придумали. Как минимум, потому что теория основывается на уже существующих наработках, а надо писать новые приложения, в новых условиях и с новыми требованиями.
Если синтезировать мысль автором на тему разработки (как я её понимаю) у разработки ПО должно быть 2 фазы — фаза набора функционала и фаза рефакторинга. Во время фазы набора функционала мы исполняем новые хотелки заказчика. Они всегда новые, неожиданные и даются с минимальным пониманием того, как устроена конкретно ваша программа. Поэтому их реализация почти всегда ломает структуру и логику нашего ПО и вставляем костыли и хаки, чтобы оно заработало. Какое-то время ПО выдержит такое издевательство, потому что оно soft. Однако хорошие разработчики (и их менеджеры) выделяют время на рефакторинг, чтобы привести текущую архитектуру приложения в более-менее нормальный вид, сохранив при этом текущий требуемый функционал. С приходом новых требований цикл повторяется заново, и мы пишем новые костыли.
Что касается света — во-первых в самой статье есть ссылки, на множество паттернов, а во-вторых на эту тему выпущено достаточно много книг, многие переведены на русский. В качестве примера можно назвать
Если синтезировать мысль автором на тему разработки (как я её понимаю) у разработки ПО должно быть 2 фазы — фаза набора функционала и фаза рефакторинга. Во время фазы набора функционала мы исполняем новые хотелки заказчика. Они всегда новые, неожиданные и даются с минимальным пониманием того, как устроена конкретно ваша программа. Поэтому их реализация почти всегда ломает структуру и логику нашего ПО и вставляем костыли и хаки, чтобы оно заработало. Какое-то время ПО выдержит такое издевательство, потому что оно soft. Однако хорошие разработчики (и их менеджеры) выделяют время на рефакторинг, чтобы привести текущую архитектуру приложения в более-менее нормальный вид, сохранив при этом текущий требуемый функционал. С приходом новых требований цикл повторяется заново, и мы пишем новые костыли.
Что касается света — во-первых в самой статье есть ссылки, на множество паттернов, а во-вторых на эту тему выпущено достаточно много книг, многие переведены на русский. В качестве примера можно назвать
- Working Effectively with Legacy Code, Michael Feathers
- Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma и другие
- Refactoring: Improving the Design of Existing Code и Patterns of Enterprise Application Architecture, Martin Fowler
- Code Complete: A Practical Handbook of Software Construction, Steve McConnell
Спасибо за перевод! Неделю пытался читать оригинал, сдался, уж больно сложный для меня английский :)
Нашел пару опечаток, надеюсь хабр пропустит ссылку на гитхаб: gist.github.com/theyoprst/c5236f35b235bdd8bd1b84ab6e2cb184
Нашел пару опечаток, надеюсь хабр пропустит ссылку на гитхаб: gist.github.com/theyoprst/c5236f35b235bdd8bd1b84ab6e2cb184
Sign up to leave a comment.
Большой комок грязи