Pull to refresh
61
0
Романов Борис @ganouver

Архитектор

Send message
Имея за плечами большой опыт успешного применения MS Project для управления именно софтверными проектами, совершенно не могу согласиться с такой абсолютистской оценкой автора. Оценка скорее эмоциональная, чем практическая.
Я согласен с тем, что MS Project откровенно плохо приспособлен для управления часто изменяющимися проектами. Но, честно говоря, я не знаю другого инструмента, который бы имел сравнимую функциональность.

Я успешно применял MS Project для планирования и отслеживания хода выполнения проекта. Я никогда не рассматривал его как инструмент совместной работы. Файл MS Project — это моя личная модель проекта. Изменения в него вношу только я. Я могу отдельным людям показывать отдельные выжимки из него, может быть использовать верхнеуровневые диаграммы Ганта в качестве отчетов начальству. Но сам файл проекта — это мой персональные инструмент как руководителя проекта. Отслеживание выполнения задач осуществляется другими средствами. Тут назывались Jira, TFS — это не суть важно. Перенести несколько задач в эти системы и раз в неделю отмечать как что движется — это не напряжно. Зато узкие места проекта становятся видны сразу же, а не в конце этапа.

P.S. если кому-то интересно, могу поделиться своей методологией использования MS Project для управления софтверными проектами.
цитата: «Если в программе больше 5 строк — в ней есть ошибка».
;-)
Поддерживаю автора. Подобные вещи иногда значительно облегчают жизнь С++ программиста.
При переходе на C# остро страдаю от отсутствия подобных инструментов! приходится осваивать кодогенерацию…
<ирония>Видимо, потому что язык появился раньше чем фундаментальные принципы и потому является более фундаментальным.

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


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

Если Вы считаете, что современные фреймворки покрывают 99% проблем — то это означает, что человечество бесконечно развилось и дальше расти некуда, все открытия были сделаны и весь мир нам понятен?
Увы, это совсем не так. Современные системы выглядят безумно умными и все умеющими. Особенно, если их сравнивать с теми, которые были 20 лет назад. Но почему-то пользоваться большинством программных продуктов, за исключением самых примитивных, ужасно неудобно. Особенно это касается мобильных платформ. Их создатели почему-то оказались не в курсе кучи полезных решений, сделанных в свое время для настольных систем. Видимо, считая что ни к чему им «заниматься изучением старых понятий (с)».

Фреймворки тоже нужно конфигурировать. И даже программисты-профи часто (и даже большую часть времени) вынуждены этим заниматься. Но, черт возьми, неужели вам не хочется большего?
Хм. Знаете, инженер программист тоже в ряде случаев может не заморачиваться на архитектуру.
Но заметьте разницу — он это делает потому что знает, что в данной ситуации этим можно пренебречь. Кодер так делает — потому что по другому не умеет.

И в дополнение хочу сказать, что прекрасно понимаю, что никто с рождения программировать не умеет, и всему надо учиться. Но меня удивляет ситуация, когда человек свое невежество выпячивает как достоинство.
Не хочешь — не надо, твое право. У нас свободное общество.
Но гордится этим?..
да разве я предлагаю изучать устаревшие понятия? Я говорю о том, что существуют понятия за пределами документации по библиотекам функций. И про них очень часто просто не думают.
А эти понятия как раз таки играют роль ПДД в программировании.
Когда читаю подобные вещи, на ум проходить древняя мудрость, которую я часто слышал от отца: «Любая крайность — это плохо». Эти самые «симпатичные парни» привлекательны тем, что умеют найти золотую середину между дебрями и костылями
индустрия такова — что и подниматься выше необязательно.
Вполне можно клепать поделки на фрилансе не утруждая себя изучением чего либо.
Я нисколько не осуждаю таких товарищей — это их выбор (по крайней мере, пока мне не приходится иметь дело с результатами их творчества). Но мне их немного жалко. Осознанно или нет, но они сами себя лишают изрядной части удовольствия.
Огнестрельное оружие изменяет способ охоты, но не отменяет основных навыков — выслеживание зверя и т.п. Если проводить аналогию, то бездумное применение высокоуровневых средств разработки сродни рыбалке с динамитом — глушанули на полметра вокруг, чтобы выловить 5 рыбок.
Я очень даже ЗА применение современных средств разработки. Но я также очень даже против их бездумного применения. В общем, я свои мысли изложил тут.
Хм. А на кой черт тратить время на изучение придуманных черт-те когда и черт-те кем ПДД чтобы водить машину? что там сложного-то? завел, поехал, крутишь руль — все в порядке, доехал!
ПДД созданы для того, чтобы минимизировать проблемы на дороге в большинстве ситуаций. Такую же роль играют эти самые «старые понятия» в программировании. Перед тем как их нарушать — важно понимать, какое правило нарушаете и почему в этом случае это возможно.
Конечно можно этого и не делать… одно из первых правил, которое объясняют начинающим водителям — это правило трех «Д».
Ну ладно, давайте переформулируем — «Какую структуру Вы предпочитаете использовать в своих программах и почему?».
Смысл не меняется. Цель вопроса — понять, насколько человек понимает различие хотя бы между элементарными структурами. Пусть это понимание хотя бы промелькнет в глазах в виде недоумения — значит можно продолжать разговор. Это показатель наличия хоть какой-то базы. Если же ответ вида «конечно, список лучше», то разговаривать о сбалансированных деревьях уже бессмысленно.
Ну например, в одной системе для статистического анализа данных, я реализовывал хитрый кэш, для которого требовалось, с одной стороны быстрый доступ, а с другой стороны — не сожрать всю доступную память. Так что там присутствовал эвристический алгоритм вытеснения и принудительной выгрузки «лишних» элементов.
Знаете, у меня вдруг промелькнула мысль, что этот «синдром утенка» существовал-то всегда. Просто сейчас интернет сделал его таким заметным :-)
Полностью с Вами согласен, и в плане удобства обучения и в плане сложности освоения С. И про это я тоже писал в статье — высокий порог вхождения в профессию задавал определенную планку. И еще Кнут в своей книге приводил примеры не на С, а на некотором псевдоязыке, призванном только иллюстрировать описываемые концепты.

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

Ну, и чтобы подытожить: программирование — это не автоматическое и не ручное управления памятью, это, в первую очередь, понимание того, что есть на свете такая штука, как память, и ей надо управлять.
:-) Чувствую какой-то негатив, и сразу хочется сказать: Ребята, давайте жить дружно!
а теперь по порядку.
1. я не хочу обсуждать достоинства и недостатки языков программирования. каждый из них создан для какой-то задачи, сравнивать их часто просто бессмысленно
2. я пытался объяснить, почему я упомянул скриптовые языки. Я это сделал потому, что, на мой взгляд, их появление кардинально изменило жизнь программиста. Порог входа в них очень низок, а потенциальные возможности велики.
3. Если касаться управления памятью — то тут, как и везде. все зависит от ситуации. В какой-то ситуации мне важно удержать количество потребляемой памяти в определенных рамках, я придумываю свой менеджер памяти. В каких-то ситуациях мой опыт подсказывает мне, что возможностей стандартного сборщика мусора будет достаточно — и я опираюсь на него, сосредотачивая свои усилия на взаимосвязях между объектами.

Ключевая мысль, которую я пытался донести, заключается в том, что программирование — это не просто складывание конструктора лего из готовых кусочков. Что тут есть место и для создания своих кусочков. А изучение разных систем связывания этих кусочков позволяет придумывать более интересные решения.
В не совсем правильно меня поняли. Я радею не за инженеров. Я радею — за вектор развития. Меня настораживает не то, что начинающие чего-то не знаю. Меня пугает, что они не хотят этого знать.
Этот вопрос был именно провокационным. Задавая его требовалось сохранять невозмутимый вид и ни в коем случае не улыбаться. ;-) Но сейчас не могу удержаться.
Я упомянул в этом ряду скриптовые языки, как средства программирования высокого уровня абстракции. В некоторых случаях они позволяют лучше сосредоточиться на задаче, не заботясь вопросами управления памятью и точностью синтаксических конструкций.
Кроме этого, программирование на интерпретируемых языках очень сильно отличается от программирования на пресловутом С тем, что интерпретируемая программа существенно более динамична. Есть возможность сконструировать объект на лету, приделать к нему требуемые методы, собрав их реализацию по кусочкам, и передать такой объект дальше. Конечно, и на С это можно сделать, но там для этого придется вывернуть мозг наизнанку, а здесь это является нормальным функционалом.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity

Specialization

Project Manager, Software Architect
Git