Проектирование ПО
Книги уже нашёл, буду работать...
Толку от Enterprise Architect действительно никакого, ибо, во-первых, это виндовозная хрень, во-вторых, ещё и платная... Время у меня есть, а ещё вроде есть мозги, учитывая наличие последнего въеду в проектирование... :)
Книги уже нашёл, буду работать...
Толку от Enterprise Architect действительно никакого, ибо, во-первых, это виндовозная хрень, во-вторых, ещё и платная... Время у меня есть, а ещё вроде есть мозги, учитывая наличие последнего въеду в проектирование... :)
Могу предложить личную помощь. Я программирую системы разных размеров с 1980 год...
Книги уже нашёл, буду работать...
Толку от Enterprise Architect действительно никакого, ибо, во-первых, это виндовозная хрень, во-вторых, ещё и платная... Время у меня есть, а ещё вроде есть мозги, учитывая наличие последнего въеду в проектирование... :)
А не скажешь, что именно нашел, какие книги? Область тоже интересует.
З.Ы. может гуру что умного скажут, в духе "это читай, это - не читай" :)
Чтобы научиться воспринимать проектирование, надо бросить сисадминство и хотя бы пару-тройку лет поработать программистом. В обычной компании -- учиться от противного, в хорошей -- на примерах.
Проектирование -- это как вождение машины. Можно прочитать тучу книжек, выучить наизусть все правила, но пока не сядешь за руль -- ты не водитель.
Сигналом, что ты готов к проектированию, станет желание писать в блоге словами, а не скриптами.
Проектирование -- это как вождение машины. Можно прочитать тучу книжек, выучить наизусть все правила, но пока не сядешь за руль -- ты не водитель.
Сигналом, что ты готов к проектированию, станет желание писать в блоге словами, а не скриптами.
[offtop]
перевод: "не лезь со свинным рылом в калашный ряд"
[/offtop]
UPD: про много практики я подозреваю, но лучше ведь начинать пораньше, не? хотя бы в теоретическом плане
В этой теме речь про проектирование ПО, про него и высказался.
А если рассматривать проектирование вообще, то бывает ещё проектирование сетей, разных там распределённых систем -- это тоже проектирование. Для них нужна своя практика.
Начинать никода не поздно. Но по моим личным наблюдениям, написанное в учебниках часто плохо согласуется с суровой российской действительностью. Где-то больше, где-то меньше.
В любом случае, проектирование начинается с умения описать задачу словами. С этого любой учебник начинается. Применимо и к самому проектированию. Типа, "я хочу научиться проектированию <того-то>, потому что это мне интересно" (вариант, "принесёт много денег"). Реакция в первом случае: "О, а для чего <эта> фигня нужна, мне же это интересно, надо рыть", во втором: "Чувак, тебе <эта> фигня принесёт много денег, давай рой, нафига она вообще нужна?". Дальнейшие действия легко угадываются.
Скажем, когда я только начинал программировать, никак не мог понять, в чём профит от баз данных. Ну данные и данные, нафига для них ещё какую-то базу городить? Напридумывают всякого, лишь бы голову морочить...
Потом уже, столкнувшись с реальными задачами, понял, что большие объёмы данных по-другому, кроме как в базе, не сохранишь. Стало интересно. Начал изучать реляционную модель, декомпозицию и пр.
Задача из учебника -- автоматизация продажи авиабилетов. Реальная задача, над которой пришлось работать параллельно с обучением -- система анализа медицинской статистики. И тут, опа: статистика (по крайней мере та, с которой пришлось работать) отличается от продаж тем, что вводятся и исходные данные, и итоговые. Разрыв шаблона. Потом между ними считается разница, и тётки пишут пространные отчёты, почему они различаются.
Как правильно спроектировать БД для этой системы, мы с ведущим программистом поняли только после сдачи первой версии в опытную эксплуатацию...
Это вы про российскую действительность сильно загнули. Это у юристов, бухгалтеров, финансистов и бизнесменов, у них там все упирается в сугробы и в медведей с гармошками, а у нас работа техническая и везде сильно одинаковая...
Есть много способов хранения данных в зависимости от требованиям к результату хранения. Базы данных далеко не единственный способ... Вопрос до сих пор активно совершенствуется... Те же тексты с форума - это конечно тоже базы данных, но это т.н. мемо поля, которые с точки зрения своей структуры далеки от классических принципов реляционных баз данных...
В любом случае, проектирование начинается с умения описать задачу словами....
Вот это правильно! Самое важно - инженерный подход к вопросу (в противовес эффективному менеджменту).
А если рассматривать проектирование вообще, то бывает ещё проектирование сетей, разных там распределённых систем -- это тоже проектирование. Для них нужна своя практика.
мне таки непонятны все эти намеки про админство, проектирование сетей и т.д. я же вроде говорил тебе на канале, что завязал? :)
а так желательно бы по теме, я полагаю, что должны быть книжки. в которых некоторые базовые принципы описаны, например проектирования дизайна приложения. Kogrom уже подкинул одну, приду домой, отпишусь какую.
Крэг Ларман. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку.
Можно ещё книжки Мартина Фаулера почитать, но сам он (Фаулер) рекомендует начать с названной.
Мне эта книга нравится тем, что написана доступным языком, рассматриваются конкретные примеры.
Возможно, начало книги (про итеративный процесс) можно пропустить. Как раз этот процесс можно считать трудноприменимым в большинстве компаний России, где ПО принято создавать как попало, кем попало. Ну и надо помнить исследования Стива Макконнела, которые показывают, что итеративный процесс не всегда эффективен.
ПО в процессе выросло с простого текстового парсера в большую систему клиент-сервер.
ПО в процессе выросло с простого текстового парсера в большую систему клиент-сервер.
Слово доступно тоже имеет свой подвох, но я пожалуй прицеплюсь к слову грамотно. "Грамотное описание" подразумевает наличие определенного стандарта. Вы имели ввиду какой то конкретный стандарт описания? Может быть это и будет ответом на изначально заданный вопрос по инструмента проектирования - ведь важен прежде всего стандарт, а ПО для него уж найдется...
Типичный взгляд интегратора из Москвы. :) Высаживается такой десант нечто за многие тыщи внедрять, и пошло-поехало: тут переделать, здесь переподчинить, бизнес-процесс изменить, и т. п. Не заказчик диктует требования, а заказчику диктуют требования. С таким проектированием каждый сможет. :)
Я рад, что тема не выродилась во флуд о хранении данных. Все прошлые темы об обучении/ликбезе почему-то скатывались в УГ.
Нет, не говорил. Тогда поздравляю, первый шаг сделан, ура. Терь словами в блоге пиши, тренируйся. :)
Осмелюсь предположить, что речь идёт об описании задачи в терминах задачи, а не кто что делает, какие отчёты нужны и т. п. Грамотный технолог нужен, да. Тот, с которым можно разговаривать на одном языке. В суровой действительности встречается, но не так часто, как хотелось бы.
У меня самого вопрос: как учатся успешные проектировщики? Ведь практическое проектирование подразумевает определённый кругозор, чтобы иметь возможность при решении задачи выбирать из нескольких вариантов. И кроме как из опыта (читай, запоров пару-тройку проектов), этот кругозор не получишь, сколько книжек не читай. Или я чего-то не понимаю тогда.
...
У меня самого вопрос: как учатся успешные проектировщики? Ведь практическое проектирование подразумевает определённый кругозор, чтобы иметь возможность при решении задачи выбирать из нескольких вариантов. И кроме как из опыта (читай, запоров пару-тройку проектов), этот кругозор не получишь, сколько книжек не читай. Или я чего-то не понимаю тогда.
Да нет - все правильно... На тему о том, что с этим у нас плохо (на примере ERP систем) я в свое время писал статью в компьютерру. В журнале она называлась "ERP в трудные времена", т.к. вышла в начале 2009 года...
PS: А некто тут похоже занимается пеаром...
На счёт MDA не скажу, но могу привести простой пример проектирования с помощью UML:
http://forum.codenet.ru/threads/52913-Совместно-используемые-данные-в-c/page2
После составления эскиза ТЗ у меня начинаются два вида проектирования: проектирование юзабилити (рисую картинки и описываю варианты использования) и проектирование структуры ПО (упрощенные диаграммы классов и диаграммы взаимодействия). Всё это рисую в тетрадке, часто карандашом.
Далее к этому подключается программирование, в котором местами даже юнит-тесты присутствуют (для Python классические, для C++ - кривые велосипеды). При этом многие диаграммы и эскизы юзабилити переделываются (ибо сразу не могу верно спроектировать).
Далее начинается "дедлайн". Диаграммы используются по минимуму, новых юнит-тестов не пишется, вносится много быдлокода, который уродует программу, но позволяет увеличить скорость её завершения. "Дедлайн" занимает наверное процентов 20 от всей работы... то есть сроки часто срываются.
Один раз уговорил начальство сделать рефакториг проекта уже после сдачи: для устранения ошибок и для подготовки частей проекта для использования в другом проекте. Было интересно бороться со своим же быдлокодом.
Вот я описал модель работы, далёкую от совершенства. Некая гибридная модель, в которой присутствует и проектирование. Но не уверен, что её можно использовать в команде.
+1. О том и речь. Суровая действительность, однако.
После составления эскиза ТЗ у меня начинаются два вида проектирования: проектирование юзабилити (рисую картинки и описываю варианты использования) и проектирование структуры ПО (упрощенные диаграммы классов и диаграммы взаимодействия). Всё это рисую в тетрадке, часто карандашом.
Далее к этому подключается программирование, в котором местами даже юнит-тесты присутствуют (для Python классические, для C++ - кривые велосипеды). При этом многие диаграммы и эскизы юзабилити переделываются (ибо сразу не могу верно спроектировать).
Далее начинается "дедлайн". Диаграммы используются по минимуму, новых юнит-тестов не пишется, вносится много быдлокода, который уродует программу, но позволяет увеличить скорость её завершения. "Дедлайн" занимает наверное процентов 20 от всей работы... то есть сроки часто срываются.
...
К этому я бы добавил, что надо изначально при проектировании планировать процесс внедрения/запуска... т.е. надо предположить где именно потребуется гибкость ПО.
Из литературы тут могу порекомендовать книгу Эда Салливана "Время деньги" ("Under Pressure and On Time" Ed Sullivan ) -- пожиже конечно, чем "Мифический человеко месяц", поскучнее, зато посвежее и о других аспектах процесса.
Я очень люблю свои статьи и по этому бываю не объективен. Так что если это намек на меня, то я прошу конкретнее: плохая? не в тему? или еще что то не так???
Глянул книжку этого Салливана. Сложилось мнение, что она из разряда книг: "Как сделать качественный проект за 3 месяца, если у вас контракт на миллион долларов". Для меня это не актуально пока.
Вот я описал модель работы, далёкую от совершенства. Некая гибридная модель, в которой присутствует и проектирование. Но не уверен, что её можно использовать в команде.
Для работы в команде есть ведущий программист, который и координирует подчинённых. У него в тетрадочке или каких других инструментах уже есть заготовка проекта.
У нормальных руководителей даже картинки сделаны.
В моём случае, как было сказано выше, я быдлокодер-одиночка (с) Kogrom. Поэтому тетрадка рулит!!!
Я не видел в книге бестолковых советов, все по делу. Автор имеет большой опыт и имеет аналитически склад ума, проблема книги в другом. Автор анализирует только свой собственный опыт, почти не обращается к первоисточникам, не анализирует статистику, разбирает только ошибки на собственных проектах. Таким образом теряется некоторая научность текста, и все же не смотря на это мне кажется что книга хорошая и полезная... Вообщем все кто темой занимается серьезно, я ее рекомендую -- читайте, чтобы не изобретать велосипед.
Ну вот и я про то. Ненаучность меня мало волнует. Дело в том, что книжка рассчитана на руководителя определённого типа предприятия. Я же таковым не являюсь, как и многие другие форумцы.
Про бестолковость советов говорить не собирался.