Романов Борис
@ganouver
Архитектор
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Project Manager, Software Architect
Git
Архитектор
Information
Я согласен с тем, что MS Project откровенно плохо приспособлен для управления часто изменяющимися проектами. Но, честно говоря, я не знаю другого инструмента, который бы имел сравнимую функциональность.
Я успешно применял MS Project для планирования и отслеживания хода выполнения проекта. Я никогда не рассматривал его как инструмент совместной работы. Файл MS Project — это моя личная модель проекта. Изменения в него вношу только я. Я могу отдельным людям показывать отдельные выжимки из него, может быть использовать верхнеуровневые диаграммы Ганта в качестве отчетов начальству. Но сам файл проекта — это мой персональные инструмент как руководителя проекта. Отслеживание выполнения задач осуществляется другими средствами. Тут назывались Jira, TFS — это не суть важно. Перенести несколько задач в эти системы и раз в неделю отмечать как что движется — это не напряжно. Зато узкие места проекта становятся видны сразу же, а не в конце этапа.
P.S. если кому-то интересно, могу поделиться своей методологией использования MS Project для управления софтверными проектами.
;-)
При переходе на C# остро страдаю от отсутствия подобных инструментов! приходится осваивать кодогенерацию…
*интересно что будет, если забыть закрыть тег иронии??
Мне как раз кодогенерация, при всех её недостатках, кажется более удобным решением. Особенно перспективным кажется кодогенерация макросов и последующее их использование.
Увы, это совсем не так. Современные системы выглядят безумно умными и все умеющими. Особенно, если их сравнивать с теми, которые были 20 лет назад. Но почему-то пользоваться большинством программных продуктов, за исключением самых примитивных, ужасно неудобно. Особенно это касается мобильных платформ. Их создатели почему-то оказались не в курсе кучи полезных решений, сделанных в свое время для настольных систем. Видимо, считая что ни к чему им «заниматься изучением старых понятий (с)».
Фреймворки тоже нужно конфигурировать. И даже программисты-профи часто (и даже большую часть времени) вынуждены этим заниматься. Но, черт возьми, неужели вам не хочется большего?
Но заметьте разницу — он это делает потому что знает, что в данной ситуации этим можно пренебречь. Кодер так делает — потому что по другому не умеет.
И в дополнение хочу сказать, что прекрасно понимаю, что никто с рождения программировать не умеет, и всему надо учиться. Но меня удивляет ситуация, когда человек свое невежество выпячивает как достоинство.
Не хочешь — не надо, твое право. У нас свободное общество.
Но гордится этим?..
А эти понятия как раз таки играют роль ПДД в программировании.
Вполне можно клепать поделки на фрилансе не утруждая себя изучением чего либо.
Я нисколько не осуждаю таких товарищей — это их выбор (по крайней мере, пока мне не приходится иметь дело с результатами их творчества). Но мне их немного жалко. Осознанно или нет, но они сами себя лишают изрядной части удовольствия.
Я очень даже ЗА применение современных средств разработки. Но я также очень даже против их бездумного применения. В общем, я свои мысли изложил тут.
ПДД созданы для того, чтобы минимизировать проблемы на дороге в большинстве ситуаций. Такую же роль играют эти самые «старые понятия» в программировании. Перед тем как их нарушать — важно понимать, какое правило нарушаете и почему в этом случае это возможно.
Конечно можно этого и не делать… одно из первых правил, которое объясняют начинающим водителям — это правило трех «Д».
Смысл не меняется. Цель вопроса — понять, насколько человек понимает различие хотя бы между элементарными структурами. Пусть это понимание хотя бы промелькнет в глазах в виде недоумения — значит можно продолжать разговор. Это показатель наличия хоть какой-то базы. Если же ответ вида «конечно, список лучше», то разговаривать о сбалансированных деревьях уже бессмысленно.
Надо сказать, что паскаль в свое время считался очень простым языком — он был создан как раз таки для обучения программированию.
Ну, и чтобы подытожить: программирование — это не автоматическое и не ручное управления памятью, это, в первую очередь, понимание того, что есть на свете такая штука, как память, и ей надо управлять.
а теперь по порядку.
1. я не хочу обсуждать достоинства и недостатки языков программирования. каждый из них создан для какой-то задачи, сравнивать их часто просто бессмысленно
2. я пытался объяснить, почему я упомянул скриптовые языки. Я это сделал потому, что, на мой взгляд, их появление кардинально изменило жизнь программиста. Порог входа в них очень низок, а потенциальные возможности велики.
3. Если касаться управления памятью — то тут, как и везде. все зависит от ситуации. В какой-то ситуации мне важно удержать количество потребляемой памяти в определенных рамках, я придумываю свой менеджер памяти. В каких-то ситуациях мой опыт подсказывает мне, что возможностей стандартного сборщика мусора будет достаточно — и я опираюсь на него, сосредотачивая свои усилия на взаимосвязях между объектами.
Ключевая мысль, которую я пытался донести, заключается в том, что программирование — это не просто складывание конструктора лего из готовых кусочков. Что тут есть место и для создания своих кусочков. А изучение разных систем связывания этих кусочков позволяет придумывать более интересные решения.
Кроме этого, программирование на интерпретируемых языках очень сильно отличается от программирования на пресловутом С тем, что интерпретируемая программа существенно более динамична. Есть возможность сконструировать объект на лету, приделать к нему требуемые методы, собрав их реализацию по кусочкам, и передать такой объект дальше. Конечно, и на С это можно сделать, но там для этого придется вывернуть мозг наизнанку, а здесь это является нормальным функционалом.