Добрый день.
Вот такой вот вопрос, который меня уже немного начинает беспокоить.
Стоит ли изучать эту область программисту или нет, или проектированием должен заниматься проектировщик ПО?
Стоит ли изучать какие-то средства проектирования: UML, чего-то там еще...?
P. S. Поделитесь опытным мнением :)
P. S. S. И где брать идеи для написания ПО(для практики, может даже что то полезное и нужное сделать), если я особо их не могу придумать?
Ему нужно понимать интерфейсы разных частей, например, железо <> драйвер <> код прикладного уровня. Эту задачу решают не программисты (в терминах архитектор-программист). Или вопрос, про интерфейс клиентской части и серверной, сегодня решение на пять, а завтра надо мобильные устройства включать, и внезапно, «садись, два!». На нем лежит просчитать, во что обойдется тот или иной подход к архитектуре уже завтра.
Архитектор думает над тем, над чем программист никогда не думает. Например, что интерфейсы откомпилированных модулей, написанных сторонними разработчиками вообще не документируются, из чисто расовых соображений, ведь plug-and-play? Если модули написаны в одном проекте разными программистами, то изредко документируются только архитектором для себя. В скретч-память. Никто же из программистов не догадывается, (или???) что линкер работает только с глобальными переменными, которые так боится использовать обычный программист, и к тому же, вдумайтесь, линкер понятия не имеет о проверке типов. Ему, линкеру, всё равно, указатель здесь или просто число. Программист мыслит песочницей адресного пространства процесса, он полагает, наивный, что весь компьютер услужливо ждет только его, и потому не сильно замечает эту восхитительную особенность сборки кода из модулей. Отсюда архитекторы и рождают концепции архитектур с переключением контекстов со всеми вытекающими оверхэдами, чтобы как-то удержать в клетках весь этот зоопарк, который быстренько настрогает линкер.
Ну в общем, где-то в таком ключе разница в образе мышления... ИМХО.
Как вы эту задачу выполните без проэктировочной части ?
«Нужно ли уметь программисту писать тех. доки?»
Ага, хоча б на рідній мові.
п.с.
нікого на насторожує вислів:
«нужно ли ’инфинитив + инфинитив’ »
сцуко ти, $10 донації, але так і не зрозумів про що ти ...
А прикинь, якщо то в такому стилі пишуть код, або доки, або коментарі. Ужос.
якось я раптово опинився на сайті нігдіяспори. от там було — як звучить так і пишеться ...
Я не грамар наці, я бігло читаю і, якщо порушується нормальний зв"язок між словами, це ніби біжиш і спіткнувся, або їдеш і тре різко гальмувати, мене це дратує.
цей світ давно зійшов з рейок
программист — это человек, который смотрит налево и направо переходя улицу с односторонним движением ©[:||||:]
дело в парсерах западных украинцев и восточных.Проблема в неоптимальному парсері нестандартних лексем.
не тре з цього галас робити, мабуть))
але твій комент коштував мені 10 баксів :)
або .. да. я нещодавно українську лінукс спільноту дещо здивував :)
нічого цікавого
Хочу выразить вам своё восхищение и огромную благодарность за пожертвование в Фонд Викимедиа!
Именно так мы оплачиваем наши счета: только благодаря таким людям, как вы, тем, кто дарит пять долларов, двадцать долларов, сто долларов. Моим любимым взносом в прошлом году стали пять фунтов от маленькой девочки в Англии, убедившей своих родителей позволить ей внести свои карманные деньги. Именно такие люди, как вы, присоединившиеся к той девочке, позволяют Википедии обеспечивать всех в мире свободным, лёгким доступом к непредвзятой информации. Всех тех, кто помогает оплачивать её, и тех, у кого нет средств для помощи. Спасибо вам большое.
Я знаю, наши призывы легко проигнорировать, и я рада, что вы этого не сделали. От себя лично и от имени десятков тысяч добровольцев, пишущих Википедию, я говорю вам: спасибо, что помогаете нам делать мир лучше. Мы будем использовать ваши деньги аккуратно и бережливо, и я благодарю вас за доверие к нам.
Спасибо.исполнительный директор Фонда Викимедиа
Для вашего архива: ваш взнос от
Это письмо может служить подтверждением вашего взноса. За этот вклад не было предоставлено никаких товаров или услуг, ни в целом, ни частично. Фонд Викимедиа (The Wikimedia Foundation, Inc.) — некоммерческая благотворительная корпорация со статусом освобождения от налогов 501©(3) в Соединённых Штатах. Наш адрес: Нью-Монтгомери-стрит, д. 149, 3 эт., Сан-Франциско, Калифорния, 94105 (149 New Montgomery, 3rd Floor, San Francisco, CA, 94105). Номер освобождения от налогов США:
Хоча мені радять почати писати і продавати комплект: книга + виделка.
xxx: нет, но теперь он смотрит на меня с благодарностью
Да... я вот недавно получил 15 минут здорового смеха, до слез...Ага, хоча б на рідній мові.
Увидел FAQ, на секундочку, тоже, кому-то «на рідній мові»:
www.fatcow.com/...venkman-faq-beоригинал: www.hacksrus.com/...enkman-faq.html
Спасибо, я лучше пешком постою...
4. лучше всего «браузить» исходники больших проектов, с точки зрения «архитектуры» — а как у них это, а как это ... линукс, мозилла, вайн (если винда используется активно), gcc , eclipse тот-же. вариантов много
Deux. По исходникам архитектура как раз не (оче)видна, для этого существуют проекции (viewpoints) и конкретные ЯП-зависимые технологии, позволяющие сделать обратное представление по артефактам низкого уровня.
И вообще думаю ТС имел ввиду не эти материи, а архитектуру уровня прикладного решения (Application Architecture). Для последнего достаточно изучить общие методы и типовые подходы к проектированию прикладных решений в конкретной области знаний. И важно помнить, что ИТ предназначены решать задачи бизнеса либо целевого потребителя, а сама по себе архитектура лишь средство достижения цели, а не самоцель.
а я чо. я ш с прогерской тз говорю, и сам дорос и видел многих «живых» доросших ...
ну и из практики — если архитект не умеет читать код «запоем» ну и если не может одновременно видеть и лес и деревья — фиговый значит архитект
Это не всегда возможно, код потоком читать-то умеют все, но кода может быть безобразно много, и стоимость анализа будет космической, поэтому анализ делается полуавтоматически, а иногда и автоматически. Последее --- это пока еще область научных исследований.
Это не всегда возможно, код потоком читать-то умеют все
фраза требующая доказательств
поэтому анализ делается полуавтоматически, а иногда и автоматически.
вы реально претендуете на опровержение второй теоремы геделя, или просто понты колотите ?
Умеют начиная с определенного этапа пребывания в профессии конечно, я думаю это очевидно.
На второе замечание, я ни на что не претендую, в остальном выбирайте выражения, иначе отвечать не буду.
Как единичный пример того, что я имел ввиду Structure101. Таких разработок много исходя из разных подходов и привязок к технологическим стекам.
Программист отличается от кодера как раз этим самым навыком. Самое интересное, что я еще не встречал профессиональных кодеров. Они вапшэ существуют?
топікстартер говорить про програмістів та проектувальників, а що Ви маєте на увазі? бо я щось не збагну яка різниця між кодером і програмістом
Но мы не об этом...тоже не пойму почему плохо, что такие вопросы возникают.
тоже не пойму почему плохо, что такие вопросы возникают.
Потому что наличие вопроса:
Нужно ли уметь программисту проектировать ПО?
Подразумевает что человек не уверен да или нет. А ответ «да» и другого быть не может.
як кажуть «поганий той солдат, який не хоче стати генералом»
Каждый программист, маленький проектировщик. Со временем некоторые становятся маленькими программистами и большими проектировщиками.
Ответ — нужно! Читай Фаулера для начала, 97 этюдов программных архитекторов, Буча и прочих. Просто так учить инструменты не надо, нужно стремиться понять как люди строят системы, это незаменимые знания, даже если ты просто программист, это поможет понять ТЛ или архитектора проекта.
На Фаулера посмотримс, данке.
Битте. Впринципе уже читаешь то, что надо. Потом дело за практикой. Я занимаюсь больше сейчас мобильными приложениями, архитектура не слишком нагруженная, но если сделать стыковку с серверами, то выходят интересные вещи. Попробуй в этой сфере, можно самому осилить и в архитектуре попрактиковаться.
Лучшая идея для написания ПО: это ПО, которое решает проблему, пускай даже самую маленькую. Это не обязательно должна быть очередная социалка или что-то мего прорывное, если кто-то благодаря тебе освободит хотя бы 1 час своего времени каждый день, это уже большая похвала. Представь, что твое ПО юзает 1000 человек, это 1000 часов экономии каждый день!!!
Эдакий пост из конца 90х, когда все еще верили в «архитекторов» и в UML. Проектирование — задача каждого программиста. И занимается он ей постоянно. Не нужно «разрабатывать архитектуру», нужно быть готовым часто и быстро рефакторить и «причесывать» код. И тут, как и везде — главное не перебарщивать, но и не откладывать в долгий ящик.
На своем проекте каждый раз в начале итерации решаем, есть ли что-то, что хотим переделать и переделываем. Если задача оказывается громоздкой и в итерацию не влезет, то разбиваем на этапы.
а теперь серьезно. Архитектура нужна для того, что бы ограничивать техническую свободу при «часто и быстро рефакторить (по-русски: изменять структуру) и „причесывать“ (по-русски: повышать качество) код». Иначе получится ситуация, когда все время решаются краткосрочные задачи, что далеко не всегда работает в долговременной перспективе.
Как всегда it depends от масштабов и сроков.
Вы как бы не совсем поняли свою мысль. Никто не говорит о том, что рефакторинг должен отвечать только текущим задачам.
Я не люблю слово «архитектура» — оно как бы подразумевает законченное здание, чего в нашей отрасли не часто встретишь. Четыре шведа, которые написали curl, до сих пор что-то в нем подпиливают.
Я люблю слова «блоки», «компоненты», люблю нарисовать квадратики и линии между ними. И больше всего не люблю, когда линии между квадратиками пересекаются, или когда их слишком много. Вы же понимаете, о чем я говорю? ;) Еще я не люблю велосипеды. Если возникает задача, первым делом я еще, как ее решил кто-то до меня.
Но к сожалению, мы не можем предугадать все и вся, и переделывать что-то приходится. В нашем деле всегда есть противоречие между «расширяемостью» и YAGNI. Когда я был молодым и зеленым, я придерживался того, что расширяемость важнее. В результате любая задача превращалась в моих руках в монструозный конгломерат — мечту архитектурных астронавтов.
Сейчас я придерживаюсь другого мнения: где-то посередине есть такая зона, когда в целом мы придерживаемся YAGNI-подхода, но действуем аккуратно, постоянно думая о том, что вдруг нам придется добавлять расширяемость. Т.е. пишем по простому, но про себя примечаем, что тут мы можем переделать так-то и так-то, если понадобится. Архитектура on-demand, так сказать.
В таких условиях с одной стороны, мы оставляем за собой возможность расширяемости, с другой — не тратим на это ресурсы. Такой же стиль стараюсь прививать команде. Получается неплохо.
Опять же, архитектуризация зависит от конкретной платформы: для той же Джавы уже выработаны многочисленные практики, и сегодня хорошей архитектурой проекта «из коробки» уже никого не удивишь. А вот для JavaScript’а такого банка практик еще нет: индустрия фронтэнд-разработки еще не вышла на такой высокий уровень. Поэтому встретить хорошо организованный проект на JS можно гораздо реже. В таких условиях без рефакторинга явно не обойтись.
Когда я говорил, что что решения о рефакторинге принимаются на каждую итерацию, я не говорил о том, что они сиюминутны. Я говорил о том, что рефакторинг никогда не откладывается в долгий ящик. Нет такого: сегодня у нас работа над функционалом, завтра рефакторинг, а потом «завтра» не наступит. При этом планы относительно рефакторинга могут быть долгоиграющими.
Судя по Вашим словам, у вас практикуется и архитектурное планирование и описание архитектуры, просто вы используете другую терминологию, что не меняет сути явлений. Единственное, что позволю себе заметить, это то, что архитектура любого уровня в ИТ — это просто план развития, такой же гибкий, как и план проекта в проектном управлении. Специфика ваших проектов позволяет использовать одну из версий гибких методологий и она же позволяет сократить накладные расходы по описанию архитектуры.
Резюмируя, с одной стороны у нас формальные RUP, PMBoK и TOGAF, а с другой заметки на доске/листочках, agile/ad-hoc и светлые головы разработчиков, да пребудет с ними Сила :)
А кто такой проектировщик ПО и откуда они берутся? :)
проектировать ПО это то, что типичный представитель класса ПХП програмистов делать не умеет. Я как раз сижу и разбираю то, что один из них, надумавши спрыгнуть на джаву, понаписывал...
Кирилл Нечаев
Grez
flyman
proger
flyman
Gremlin
Кирилл Нечаев
Петтинг Пудинга
belmondo
Bogdan Shyiak
belmondo
Sergey Bushnyak
Sergey Bushnyak
Андрей
Андрей
Bohdan Chechyn
Ostap Vyshnya
46 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів