2 мая 2009 в 18:52

Архитектура ПО

Здравствуйте!

Я являюсь программистом-фрилансером и в будущем хочу выполнять больше заказов в то же время.

Для этого мне нужно научиться проектировать ПО так, чтобы система состояла из нескольких, относительно независимых друг от друга блоков, которые могут разрабатываться разными людьми (причём разработчик того или иного блока не должен будет знать, как работает ВСЯ система).

Если это действительно будут независимые друг от друга блоки, то их разработку можно будет поручить менее квалифицированным (следовательно, с меньшей зарплатой) разработчикам.

Тогда разные блоки одной системы могут разрабатываться одновременно несколькими разработчиками — вот и будет повышение производительности.

Вопрос: Как этому научиться (кроме тех вариантов, которые я привёл ниже)?

Мои ответы:

  1. Взять большую, удачно спроектированную систему (к которой я имею доступ) и изучить её.

Некоторые утверждают (пока я это ещё не успел проверить), что OpenOffice.org является образцово-показательным проектом — там всё сделано по канонам объектно-ориентированного проектирования.

  1. Проработать книгу «Software Architect Bootcamp», Raphael Malveau, Thomas J. Mowbray.

Заранее благодарен

Дмитрий Писаренко

622
Комментарии (27)
  • 11 мая 2009 в 10:53 • #
    Максим Еременко

    ИМХО есть еще вариант поучаствовать в каком нибудь (не обязательно OpenOffice) Open Source проекте, не обязательно очень масштабном.

  • 11 мая 2009 в 11:01 • #
    Владимир Шелухин

    Разумеется, последнее — от этого хотя бы будет толк. :-) А также ещё пару источников того же уровня и на том же языке, начав вот с этого: http://www.ozon.ru/context/detail/id/1861855/ . Не исключено, что заодно сами собой отомрут идиотские идеи.
    Заставить разработать отдельные модули, не имея представления о целом нереально — на интеграцию системы вы потратите на пару порядков больше сил, чем если бы всё писали с нуля самостоятельно, причём в результате убедитесь, что систему сбыть всё равно не получится, так как она непригодна к коммерческой эксплуатации. Даже чтобы были написаны отдельные модули, по каждому пришлось бы готовить настолько основательное техническое задание, что, опять же, сам модуль написать было бы куда легче. Система оттого системой и зовётся, что её разработчики начинают с определения общей логики и архитектуры, и действуют как одна команда, исходя из этого знания.
    То есть нанять быдлокодеров — замечательная мысль сама по себе, только с той поправкой, что английское выражение code monkey имеет несколько иной смысловой оттенок, чем принято считать в этой стране. На практике получается, что в вашем случае это должен быть вполне квалифицированный программист, но лишённый коммерческой жилки. Таковые существуют, однако отыскать их — задача сама по себе нетривиальная по той простой причине, что у них не хватает ума грамотно позаботиться о своей видимости для потенциального нанимателя. Они не имеют собственных сайтов и не регистрировались в значимых социальных сетях, а даже если и сделали хоть что-то, то так, что увиденное работодателя скорее отпугнёт. И так далее, так далее и так далее.
    Поступите проще: позаботьтесь о себе самом, представьте себя как достойного доверия подрядчика, и займитесь поиском специалистов на обозначенную вами зарплату. Сам по себе поиск тоже адова работёнка, однако здесь уже можно надеяться на успех. Но в любом случае вам предстоит собирать команду.

  • 14 июня 2009 в 01:09 • #
    Профиль Удален

    > вы потратите на пару порядков больше сил, чем если бы всё писали с нуля самостоятельно

    Для этого люди и используют Continuous Integration

  • 14 июня 2009 в 01:42 • #
    Владимир Шелухин

    Используют. Только чаще всего уже по прочтении книжек.

  • 14 июня 2009 в 01:48 • #
    Профиль Удален

    Не книжки надо читать, а статьи и блоги, и общаться напрямую. Хоть информация будет посвежее.

  • 14 июня 2009 в 02:17 • #
    Владимир Шелухин

    Одно другому не мешает. Книга даёт систему, к тому же просто удобна в эксплуатации: чтение статьи в метро или на ходу я себе представляю плохо. Далеко не у всякого есть хотя бы под рукой принтер, позволяющий печатать длиннючие статьи для брошюровки внакидку, чтобы сразу и спуск полос делал, ну и степлер для этой цели (уж не говоря о том, что, скажем так, далеко не всякий вообще понял, что это только что было сказано).
    И не скажу, чтобы наличие этого оборудования и даже полностью бесплатная его эксплуатация сильно меняли дело. Я именно так и поступаю, в результате чего, чтобы освежить в памяти какой-то момент, нужный материал проще наново найти в браузере, чем в нескольких кипах так и норовящих расползтись по всему дому аккуратненьких тощеньких брошюрках формата A5. Хотя первый раз читать удобно, что есть, то есть. :-)

  • 14 июня 2009 в 11:27 • #
    Профиль Удален

    Хех, тоже смутно вспоминается, как в голодные студенческие годы на обычном принтере по-хитрому печатались статьи в формате 2 страницы на A4 и потом это все вручную степлером скреплялось)) Впоследствии забил и просто привык читать с экрана

    Последующим поколениям будет легче - A4 eBooks будут.

    Насчет системы согласен. Но пока видел только одну единственную книгу, которая давала хорошую систему, да и та - PMBoK.

  • 11 мая 2009 в 13:42 • #
    Руслан Равильевич Лайшев

    Вероятно имеет смысл порешать учебные задачи: как кушать слона по частям, ну , или не кушать, а как разобрать , а потом его и собрать сердешнаго. Анализ и синтез - две собственно методологии проектирования ПО. Боюсь, что без наживания опыта вам не приобресть этого знания и умения.

    Возможно хорошим учебным примером будет разбор модели OSI, функциональность слоёв, почему так, а не иначе, а можно ли по другому...

    Архитектор - не человек, писующий ежедневно по н строчек кода в опен-проекте, но ежедневно анализирующий рациональность сделанного с большим кол-вом критериев: от оптимальности цикла, до стиля кодирования, до оценки эксплуатационных затрат сваво творения...

    Сложно всё это, нонче этому и в ВУЗ-ах не учат.

    Успехов вам!

  • 11 мая 2009 в 14:45 • #
    Борис Вольфман

    Дмитрий!
    Нужно то и второе и третье:
    изучать теорию
    изучать хорошие примеры
    проектировать,реализовывать, внедрять, проектировать.
    Но главное, не переусердствовать в разбиении на независимые компоненты.
    Один бездарный исполнитель независимого компонента и весь проект неработоспособный.
    Также-Вы не должны разрывать архитектуру от аналитики, тестирования и испытаний.
    Один идеальный архитектор с бездарными требованиями, недостаточным тестированием и отсутствием квалифицированного менеджмента проекта - успех проблематичен.

    Владимир Шелухин другими словами, но высказал ту же идею: должна быть команда проекта: а команда, то можно использовать офшор, рабочих лошадок, отдавая им архитектурно незначащие модули и т.п.

  • 11 мая 2009 в 16:37 • #
    Владимир Шелухин

    Да и в этом случае можно в ответ запросто получить то, что в России именуется индийским кодом.

  • 11 мая 2009 в 16:58 • #
    Андрей Архангельский

    Я бы для начала предложил прочитать две книги:
    Дж.К.Джонс "Методы проектирования" М., Мир, 1986г
    Дж.Фокс "Разработка программного обеспечения", М.Мир, 1982г

    После этого нужен практический опыт (лет 10) и можно прочитать еще некоторые книги.
    Как результат - останешься без заказчиков.
    По крайней мере, что что писали эти авторы в начале 80-х расцветает до сих пор.

  • 11 мая 2009 в 20:48 • #
    Геннадий Беседин

    К сожалению, научиться предмету по книгам практически невозможно. Однако замечу, что в корне рассуждений есть "бомба": независимость модулей тоже кое-чего стоит. Конечного пользователя интересует сам продукт, его не интересует архитектура. Так что выбирайте, что вам ближе: оркестровка независимыми разработчиками или конечный продукт.

  • 12 мая 2009 в 08:41 • #
    Андрей Архангельский

    Как пишет Роберт Гласс в книге "Факты и заблуждения профессионального программирования" разработка повторно используемой программы стоит в 3 раза больше, чем программы, которая используется один раз.
    Я думаю, что разработка независимого универсального модуля стоит как минимум в 3 раза больше чем разработка повторно используемой программы.

  • 14 июня 2009 в 01:50 • #
    Профиль Удален

    Универсальных модулей не бывает.

    А вот повторное использование существующих компонентов (aka Component-Driven Development) в разы повышает эффективность разработки новых систем (не говоря уж об снижении трудозатрат на поддержу всех систем, т.к. codebase - общая).

  • 14 июня 2009 в 08:23 • #
    Андрей Архангельский

    Никто не спорит, что использование готовых компонентов (кирпичей) в разы повышает эффективность и т.д.
    Только никто не хочет платить за их разработку, никто не хочет тратиться на исследования - ты сделай, а если получится мы возьмем и моет спасибо скажем.

    2) Я готовою только о том, что желание отдать разработку модулей малоквалифицированным разработчикам в корне неправильно. Это должны быть более квалифицированные разработчики, чтобы могли увидеть максимум вариантов использования будущего модуля.

  • 14 июня 2009 в 11:30 • #
    Профиль Удален

    1. Знаю людей которые начинали забесплатно (и даже aka Open Source). Это окупалось.

    2. Ни один даже самый квалифицированный разработчик не сможет увидеть и просчитать варианты использования модуля. Просто потому, что у них нет квалификации, опыта и стиля мышления, пригодного для оценки бизнес-возможностей. А те из разработчиков, у кого они есть, на зарплату уже не работают))

  • 11 мая 2009 в 22:56 • #
    Рыжков Сергей

    Действительно нужно знать теорию или я бы сказал историю (ООП, паттерны, SOA, проектирование (UML и т.п.) ) и инструменты, но без практики невозможно понять глубинные связи. Только на практике применяя подходы и смотря на систему с разных сторон можно отточить свое мастерство.
    Вывод: Теория + Практика. В вашем случае, имхо, нужно начать делегировать часть работ одному фрилансеру, потом двум и т.д. с постоянной коррекцией подходов к процессу разработки и архитектуре. Ну и конечно прочитать классику.

    Позволю себе небольшой оффтоп.
    Ваша цель – выполнять больше заказов в тоже время, т.е. становиться больше менеджером, нежели архитектором. Или цель делать более крупные проекты за то же время, тогда, да это архитектор-тимлид.
    Вопрос передачи работ менее квалифицированным разработчикам тоже не тривиальный, много ли таких задач, которые можно отдать менее квалифицированным разработчикам, чтобы они сделали работу действительно дешевле и так чтобы заказчик еще раз к вам обратился?
    Здесь вопрос в правильном делегировании и специализации, если у меня есть фрилансер который отлично знает, например, платежные системы, то нам остается с ним договориться о стандартах кодирования и интеграции, а далее за счет своей узкой специализации он сделает быстро-дешево-качественно-в срок платежный модуль. А вот неквалифицированный может сделать и дешевле, но значительно дольше и вы потратите на него столько времени, что в совокупности будет дороже.

  • 12 мая 2009 в 07:20 • #
    Максим Смирнов

    Дмитрий, добрый день.

    На мой взгляд, декомпозиция системы на модули и организация совместной разработки - не одно и то же. Конечно, в классической работе Фила Крайтчена "4+1" написано о том, что один из архитектурных видов предназначен для распределения работ между разработчиками ("development view"), но это когда было :-)

    Думаю, для ваших целей полезно посмотреть материалы по организации совместной разработки ПО, причем не методологии, а именно практические вопросы: как организовать версионное хранилище, автоматизированную сборку и, возможно тестирование, как договориться о правилах кодирования и т.п.

    Ответ на вопрос, как этому научиться зависит от средства разработки. Согласитесь, есть разнича что вы пишите. В EJB вы будете проектировать сущности и обработчики очередей сообщений, в web-приложении на PHP серверные страницы и вероятно базу данных и т.д.

  • 12 мая 2009 в 14:32 • #
    andrzej14 lesnewski

    ok! #

  • 12 мая 2009 в 14:34 • #
    andrzej14 lesnewski

    Ok!!! #

  • 13 мая 2009 в 10:52 • #
    Адель Чепкунов

    Присоединяюсь ко всем, предложившим поучавствовать в опенсурс-проектах. Это даст хорошую практику, принесет пользу людям :) и будет что писать в портфолио.

    К сожалению, нормальных русскоязычных оренсурс-площадок мне не попадалось. Есть ребята, создавшие одну такую - fireforge.net, но они как-то слабо ее раскручивают, критическая масса разработчиков еще не набралась.

  • 14 июня 2009 в 01:10 • #
    Профиль Удален

    Нормальных русскоязычных open-source проектов не существует в принципе.

  • 15 июня 2009 в 01:55 • #
    Адель Чепкунов

    я знаю. :( но это пока ;)

  • 27 мая 2009 в 12:48 • #
    Сергей Синица

    Считаю что научиться проектированию ПО можно быстрее всего поработав в команде под руководством опытного архитектора. Устройтесь на хорошую работу.

  • 14 июня 2009 в 01:17 • #
    Профиль Удален

    На такой работе ничему не научишься. Особенно в России.

  • 14 июня 2009 в 01:16 • #
    Профиль Удален

    Целиком самостоятельно спроектируй и разработай систему со сложностью за пределами твоих возможностей, но с четкими целями и жесткими временными рамками.

    Система должна разрабатываться не на продажу, но полностью, как если бы это было так (потом ее можешь поместить в портфолио).

    Я сам так начинал. Убил почти два месяца (половину времени на планирование и прототипы). По итогам чисто для себя написал отчет.

    http://abdullin.com/storage/uploads/2008/02/3_1-project-report.pdf

    Благодаря этому отчету следующий проект уже был коммерческий и с привлечением разработчиков со стороны.

  • 6 июля 2009 в 23:42 • #
    Георгий Камнев

    Почитал посты, и сам вопрос
    Одобряю ваше желание, но не согласен с подходом:

    1) Научиться проектировать ПО - это сложно и долго, ни книги, ни общение не помогут, без опыта

    Спроектированные системы - это хорошо, но они не вами сделанны а их изучение не даст опыта проетирования

    Книги - тоже хорошо, там идеи, но снова без опыта как можно судить что вы правильно их поняли?

    Согласен с Владимир Шелухиным - Система а нато и система - что она представлена вся целом и всем разработчикам. Так что с компонентным подходом - это все сложно.

    ООП - это конечно хорошо, но если почитать посты и посмотреть на разработки, то можно явно заметить что идут перемены в области подходов, очень много заимствуется из функционального проектирования, создаются новые системы как мета программирование.

    Из классических подходов более мение были и применяются такие как IDEF и UML, но они не являются канонами.

    А что говорить о метологиях, то там вообще полный разлет фантазии....

    Хороший пост Геннадия Беседина: "Конечного пользователя интересует сам продукт, его не интересует архитектура. Так что выбирайте, что вам ближе: оркестровка независимыми разработчиками или конечный продукт." - что ближе?

    Так все же как научится: Теория + Практика (пост Рыжкова Сергея)


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
1970