Комментарии 18
Скажем так, довольно тривиальные вещи. Но в любом случае — спасибо, потому что повторение... что? правильно! мать учения! ))
Здорово! Лет пять-шесть назад статья была бы мне полезна.
Только лучше бы её отнести в блог учись работать, а то как-то в "Управлении проектами" она смотрится несолидно, выдавая младоразработчицкую сущность автора.
Только лучше бы её отнести в блог учись работать, а то как-то в "Управлении проектами" она смотрится несолидно, выдавая младоразработчицкую сущность автора.
Запомнить и не забывать.
Я однажды пробовал генерить код из UML с помощью целого ряда инструментов. Придя в себя после изучения результатов, выкинул их к черту и с тех пор кодирую из UML в Perl/Python вручную. Доверять такое идиотам или машинам — себе дороже.
P.S.: имхо, лучше по максимуму внедрять сторонние библиотеки и фреймворки для достижения того же результата — высвобождения времени на нетривиальные задачи. Ведь сама формулировка — доля кода, который может быть получен без участия квалифицированного разработчика, достаточно велика — должна настораживать. Во всяком случае, в правильно организованной системе, написанной на языке высокого уровня, подобная проблема вообще не возникает.
http://en.wikipedia.org/wiki/Elisp ;-)
а если серьезно - http://www.generative-programming.org/
а если серьезно - http://www.generative-programming.org/
Из средств кодогенерации могу порекомендовать бесплатную платформу, которую можно скачать тут http://bars-open.ru/Platforma.aspx
про п 9: там действительно имелось ввиду "... достаточно велика для того, чтобы написать самим ..." ? Мне кажется, что это немного "через край". Создание собственных систем генерации кода требует серьёзной базы и большого опыта в системном программировании. Это будет само по себе немаленьким проектом - мне никак не удается представить проект, в рамках которого реализация собственной кодогенерации имела бы смысл.
Какие-то средства "генерации кодогенераторов" были у Microsoft в Visual Studio SDK, а точнее в Tools for Domain Specific Languages - но возможно ли использование этой системы в большом проекте для разработки собственных средств генерации, мне не известно...
А вот с использованием существующих систем генерации полностью согласен. Сам активно использовал кодогенерацию Java-классов для Hibernate.
Какие-то средства "генерации кодогенераторов" были у Microsoft в Visual Studio SDK, а точнее в Tools for Domain Specific Languages - но возможно ли использование этой системы в большом проекте для разработки собственных средств генерации, мне не известно...
А вот с использованием существующих систем генерации полностью согласен. Сам активно использовал кодогенерацию Java-классов для Hibernate.
Статья честно говоря не очень интересна...
Едиственное что полезно я думаю пункт.2
Глобальный проект переделывается 1000 раз. Но больше всего времени уходит на анализ новых технологий и выбор их.
А про архитектуру я вообще молчу. Но надо стремиться к тому чтобы проект получился лучше чем вы задумали, иначе он устареет пока вы его сделаете. И самое главное все почему-то забыли про немаловажный пункт: РЕФАКТОРИНГ, но это уже по окончанию создания архитектуры и в принципе основ интерфейса. Только вы начнете рефакторить, вы столкнетесь с кучей узких мест, которые могут поставить весь проект на колени… особенно по «скорости» вот тут конечно п.2 очень помогает, т е надо заранее сделать «задел» для преодоления узких мест, иначе ппц может подкрасться незаметно, когда проект что называется готов. И тогда начинаются извращения и прочая лабудень… в итоге проект получается «как всегда» и как у всех.
И еще… Если проект глобальный, лучше делать вообще «новую» архитектуру (поверьте это не изобретение велика) или вообще не делать, а развить существующие — расширениями и дополнениями.
Едиственное что полезно я думаю пункт.2
Глобальный проект переделывается 1000 раз. Но больше всего времени уходит на анализ новых технологий и выбор их.
А про архитектуру я вообще молчу. Но надо стремиться к тому чтобы проект получился лучше чем вы задумали, иначе он устареет пока вы его сделаете. И самое главное все почему-то забыли про немаловажный пункт: РЕФАКТОРИНГ, но это уже по окончанию создания архитектуры и в принципе основ интерфейса. Только вы начнете рефакторить, вы столкнетесь с кучей узких мест, которые могут поставить весь проект на колени… особенно по «скорости» вот тут конечно п.2 очень помогает, т е надо заранее сделать «задел» для преодоления узких мест, иначе ппц может подкрасться незаметно, когда проект что называется готов. И тогда начинаются извращения и прочая лабудень… в итоге проект получается «как всегда» и как у всех.
И еще… Если проект глобальный, лучше делать вообще «новую» архитектуру (поверьте это не изобретение велика) или вообще не делать, а развить существующие — расширениями и дополнениями.
Думаю, чтобы эта тстатья действовала, при том не только на новичков, надо не просто сказать что надо делать, а описать, чем грозит невыполнение этих простых рекомендаций.
>РедактируемыйОбъект.Сохранить();
А разве объекты бизнес-логики должны зависеть от слоя доступа к данным?
Мне казалось, что должно быть так:
МенеджерРедактируемогоОбъекта.Сохранить(объект);
А разве объекты бизнес-логики должны зависеть от слоя доступа к данным?
Мне казалось, что должно быть так:
МенеджерРедактируемогоОбъекта.Сохранить(объект);
И не надоедает вам это мыло писать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десять рекомендаций разработчику программного обеспечения