Что некоторые - усовершенствованные темы разработки программного обеспечения, которые должен знать каждый разработчик? [закрытый]
WPF привязывает список / коллекцию элементов к ListBox, но пользовательский интерфейс не обновляется после обновления элементов, Решено .
1114 Я просто тупой. Хотя я много читал об использованииObservableCollection<> вместо List<>, я просто продолжал игнорировать это предложение и следовал другим предложениям, но безрезультатно. Вернулся к моим книгам и перечитал. Довольно хорошо объяснено, что ObservableCollection<> является обязательным использованием, потому что List<> не предоставляет интерфейс INotifyCollectionChange, необходимый для ListBox обновления его отображения, когда элементы изменяются в коллекции.
Это обновленный код:
private ObservableCollection<StringWrapper> m_AppLog;
ObservableCollection<StringWrapper> Log { get { return m_AppLog; } }
Довольно просто и не требует ничего другого (например, Refresh ()). Поскольку ObservableCollection заботится о том, чтобы инициировать событие изменения, я смог удалить ненужный вызов:
// notify bound objects
OnPropertyChanged("Log");
ObservableCollection не поддерживает обновление потоком, который его не создавал. Поскольку мой список (визуальный журнал, отображающий последние сообщения об ошибках / информационные сообщения) можно обновлять из разных потоков, я добавляю его, чтобы настроить свой код таким образом, чтобы обеспечить обновление с помощью собственного диспетчера списка:
public void AddToLog(string message) {
if (Thread.CurrentThread != Dispatcher.Thread) {
// Need for invoke if called from a different thread
Dispatcher.Invoke(
DispatcherPriority.Normal, (ThreadStart)delegate() { AddToLog(message); });
}
else {
// add this line at the top of the log
m_AppLog.Insert(0, new StringWrapper(message));
// ...
Также отметим, что ObservableCollection<> не поддерживает RemoveRange() вопреки List<>. Это часть возможных корректировок, требуемых при переходе от List к ObservableCollection.
31 ответ
Параллельное / параллельное программирование и многопоточность, особенно в отношении моделей памяти и когерентности памяти. Я думаю, что каждый программист должен знать о соображениях в этой области, когда мы переходим в мир многоядерное оборудование / оборудование с несколькими процессорами.
Для этого я бы, вероятно, наиболее активно использовал Интернет-исследования; но учебный курс на кампусе в хорошем университете может стать хорошим началом.
Я полностью согласен с Accessabiitly. Меня попросили изучить этот веб-сайт на работе, и там действительно отсутствуют хорошие знания по этому вопросу, а не только отсутствие стандартов CSS, которые могли бы помочь в подобных программах для чтения с экрана.
Однако мой ответ касается графического интерфейса пользователя. дизайн - это довольно сложная вещь. Существует слишком много ужасных приложений, которые можно предотвратить, просто потратив время на то, чтобы следовать советам / проектам HCI (взаимодействие человека с компьютером). Возьмите Google / Apple в качестве источника вдохновения при создании графического интерфейса - это не обычная комбинация из сотен кнопок и ярлыков, которую слишком часто выталкивают наружу.
Я думаю, что продвинутый программист должен знать, как заставить вашего работодателя выделить вам время и деньги для обучения по такому количеству продвинутых тем программирования, которое вы можете съесть за год. Я еще не продвинулся. :)
Как я бы предпочел пройти обучение? Мне бы хотелось, чтобы значительное количество времени в компании было посвящено самообучению.
Что ж, если вы здесь, я надеюсь, что к настоящему времени у вас уже есть основы:
- Рекомендации по ООП
- Шаблоны проектирования
- Безопасность приложений
- Безопасность баз данных / Запросы / схемы
В первую очередь разработчики должны стремиться изучать несколько языков программирования и дисциплин, чтобы их набор навыков можно было расширить более чем в одном направлении. Им не нужно становиться экспертами в этих других навыках, но, по крайней мере, они должны иметь очень острое понимание интеграции со своей основной дисциплиной. Это сделает их намного лучшими разработчиками в долгосрочной перспективе, а также позволит им получить возможность использовать все инструменты, имеющиеся в их распоряжении, для создания приложений, которые могут преодолевать ограничения единственного языка.
Помимо программирования конкретных тем, вам следует также научитесь работать в Agile, XP,
Посетите Stack Overflow DevDays
Прочтите
- Гибкая разработка программного обеспечения, принципы, шаблоны и методы (Роберт С. Мартин)
- Чистый код (Роберт С. Мартин)
- Программист-прагматик (Эндрю Хант и Дэвид Томас)
Методы рефакторинга (которые подразумевают также обучение написанию хороших наборов модульных / функциональных тестов).
Знание того, как провести рефакторинг - лучший способ сохранить код чистым - редко, когда вы делаете это правильно с первого раза (особенно в новых разработках).
Однако ряд рефакторингов требует приличного набора тестов, чтобы убедиться, что рефакторинг не привел к неожиданному поведению.
Отладка
Отладка Дэвида Дж. Аганса - хорошая книга по этой теме. Отладка может быть очень сложной, когда вы имеете дело с многопоточными программами, сбоями, алгоритмами, которые не работают. и т.д. Всем было бы лучше хорошо уметь отладку.
Я бы проголосовал за реальные боевые истории. Предложите разработчикам из других организаций рассказать о своих успехах и неудачах. Не ограничивайте презентации используемыми вами технологиями. В случае очень сложного проекта это обязательно приведет к разделению на «продвинутые» темы, которые вы даже не рассматривали. Реальные успехи (и неудачи) могут многому научить.
Я бы рассказал о новых технологиях и тенденциях. Некоторые из новых технологий, с которыми я изучаю / совершенствую свои навыки, включают:
- Microsoft .NET Framework v3.0 / v3.5 / v4.0
- Платформы облачных вычислений (Amazon EC2, Windows Azure Services, GoGrid, и т. д.)
- Шаблоны проектирования
Я из мира разработчиков MS, так что вот мой взгляд на
Подробнее о новых концепциях в облачных вычислениях (различные API и т. Д.). поскольку промышленность делает ставку на это на время.
Подробнее о LinQ для .NET Framework
Распределенные базы данных
НП Полнота . В частности, как определить, является ли проблема NP-Complete, и как построить приблизительное решение проблемы.
Я считаю это важным, потому что вы не хотите, чтобы разработчик пытался решить NP- завершите проблему , получив оптимальное решение, если область поиска проблемы не очень мала, и в этом случае приемлема грубая сила. Однако по мере увеличения пространства поиска время, необходимое для решения проблемы, увеличивается экспоненциально.
Одним из лучших курсов, которые я прошел, был курс технического письма. Это хорошо послужило мне в моей карьере.
Кроме того: вероятно, не имеет значения, ЧТО является тема - тот факт, что организация заинтересована в ней и платит за нее, а разработчики хотят идти и работать, является лучшим индикатором успеха / улучшения, чем любой другой конкретная тема.
Я также не думаю, что имеет большое значение, о чем идет речь. Организации разработчиков имеют дело с таким большим количеством вещей во время проекта, что обучение, а затем выполнение работы / метод проб и ошибок всегда даст вам лучшую перспективу - даже если попытки опробовать / использовать новый материал потерпят неудачу. Этот опыт, вероятно, больше поможет в последующих проектах.
I'm a book person, so I wouldn't really bother with instruction.
Not necessarily in this order, and depending on what you know already
- OO Programming
- Functional Programming
- Data structures and algorithms
- Parallel processing
- Set based logic (essentially the theory behind sql and how to apply it)
- Building parsers (I only put this, because it actually came up where I work)
- Software development methodolgoies
К сожалению, коммуникативные навыки для большинства разработчиков попадают в раздел «расширенные темы» (конечно, за исключением нынешней компании). Лучший способ приобрести этот навык: потренироваться.
- Возьмите наушники и поговорите с кому-то вместо обмена мгновенными сообщениями или электронной почты парень за соседней стойкой.
- Поднимите трубку и поговорите с клиент вместо лоббирования электронной почты через забор.
- Задавайте вопросы на конференции, а не сидите за ноутбуком щебетание экрана.
- Активно участвуйте в нетехническом совещании на работе.
- Представьте что-нибудь публично.
Большинство проектов не терпят неудачу по техническим причинам. Они терпят поражение, потому что не могут создать команду. Коммуникация жизненно важна для командной динамики.
Это не повредит и вашей карьере.
Разработчики должны знать основы разработки SQL и то, как их решения влияют на производительность базы данных. Одно дело написать запрос, другое дело написать запрос, понять план объяснения и принять проектные решения на основе этих результатов. Я думаю, что хороший курс по разработке PL / SQL и производительности баз данных будет очень полезен.
Доступность
Это игнорируется многими организациями, но простой факт в том, что существует огромное количество людей с плохим зрением или без него, дальтонизмом или другими различиями, которые могут сделать навигацию по сети очень утомительной. Если бы каждый прошел хотя бы небольшую подготовку в этом, мы могли бы получить некоторые веб-интерфейсы, которые будут немного более инклюзивными.
Вот три, которые я всегда объясняю младшим разработчикам, не получившим достаточного обучения CS. Все эти другие вещи, как правило, представляют собой скорее шумиху, чем суть, или их довольно легко подобрать. Но если вы не знаете этих трех, вы можете нанести большой ущерб:
- Анализ алгоритмов, включая Big O Обозначение .
- Различные уровни сцепление и соединение .
- Закон Амдала и его отношение к оптимизации.
Думаю, «продвинутый» у всех разный, но я бы посоветовал следующие вещи, которые наиболее достойные разработчики (т.е. те, которым не нужно рассказывать о NP-полноте или паттерны проектирования) могут получить выгоду от:
- методов многопоточности, которые за пределами «блокировки» и когда их применять.
- Углубленное обучение для изучения и привыкают к умным функции в их инструментальной цепочке (IDE / текст редактор, отладчик, профилировщик, оболочка.)
- Некоторые теории криптографии и практический опыт работы с различными типичными недостатками в схемах безопасности, которые создают люди.
- Если они программируют против базы данных, изучите внутреннее устройство своей базы данных и продвиньтесь дальше. методы составления и настройки запросов.
Проблемы интернационализации, тем более, что похоже, что это не будет сложной темой. Но это так.
Безопасность!
Слишком много программистов просто создают что-то и думают, что они могут добавить безопасность в качестве второстепенной мысли после завершения «основной» части программы. Вы всегда можете получить больше информации о том, как защитить свое приложение, как разрабатывать программное обеспечение для обеспечения безопасности с самого начала, как выполнять обнаружение вторжений и т. Д.
Расширенная разработка баз данных
Такие вещи, как хранилище данных (MDX , Запросы OLAP, звездообразные схемы, таблицы фактов и т. Д.), Расширенная настройка производительности, расширенные схемы и шаблоны запросов и т.п. всегда полезны.
Ruby
Количество символов: 217 179
Это самое короткое решение для Ruby на данный момент (одно, в значительной степени основанное на RegExp, дает неправильные ответы, если строка содержит несколько групп скобок) - больше не верно. Решения, основанные на регулярном выражении и подстановке, короче. Этот основан на стеке аккумуляторов и анализирует все выражение слева направо. Он повторяется и не изменяет входную строку. Его можно обвинить в нарушении правил отказа от использования eval , поскольку он вызывает Float '
- Автоматическое тестирование: модульное тестирование, функциональное интеграционное тестирование, нефункциональное тестирование
- Сведения о компиляторе (более актуальны для некоторых платформ, чем для других): Как компилятор реализует определенные общие конструкции на языке X? Как работает JIT-компиляция на платформе с интерпретацией байтового кода? Что может быть JIT-скомпилировано (например, могут ли виртуальные вызовы быть JIT-скомпилированы?)?
- Базовая веб-безопасность
- Общие идиомы проектирования из других проблемных областей, кроме той, в которой вы работаете в данный момент.
I'd recommend learning about Refactoring, Test Driven Development, and various unit testing frameworks (NUnit, Visual Test, CppUnit, etc.) I'd also learn how to incorporate automated unit testing into your continuous integration builds.
Ultimately if you can prove your code does what it claims it can do, you don't have to be there to answer questions as to why or how. If a maintainer comes along and tries to "fix" your code, they'll know instantly if they broke it. Tests written around the requirements (use cases) explain to the maintainer what your users wanted it to do, and provide a little working example of how to call it. Think of unit tests as functional documentation.
Test Driven Development (TDD) is a more novel design approach that begins with the requirements, where you start by writing a test before you write the code. You then write exactly enough code required to pass the test. You have to stop before you write extra code (that you may never need), because you will refactor it later if you find that you really needed it.
What makes TDD cool is that a bad interface (such as one with lots of dependencies) is also very hard to write tests for. It's so hard that a coder would rather refactor the interface to make it easier to test. And that refactoring simplifies the code, removing inappropriate dependencies, or grouping related tests together to make it easier to test, thus improving cohesion. By making it immediately apparent to the developer when he's writing a badly interfaced module, the developer sticks to the architecture and gravitates to the principles of tight cohesion and loose coupling. Good interfaces are the natural result. And as a bonus, once you pass all your tests, you know you're done.
На первый взгляд кажется, что на этот вопрос легко ответить, просто введите свое любимое злобное мнение о том, что другие разработчики не могут сделать правильно. Но когда я прочитал ответы и подумал, я понял, что каждая «продвинутая тема» Воспитание было охвачено в моей программе бакалавриата по информатике 20 лет назад. И я сомневаюсь, что концепции объектно-ориентированного проектирования, безопасности, функционального программирования и т.д. за это время изменились. Конечно, инструменты есть, но я утверждаю, что инструменты отличаются от тем.
Так что же такое «продвинутая тема» в информатике? Кто такие Тьюринг, Кнут, Юрдон 21-го века?
У меня нет четкого ответа на этот вопрос, хотя я бы хотел увидеть больше работ по теориям параллельного программирования, которые позволят инструментам абстрагироваться от этого беспорядочного материал для разработчиков.
Yourdon 21-го века?У меня нет четкого ответа на этот вопрос, хотя я хотел бы увидеть больше работ по теориям параллельного программирования, которые позволят инструментам абстрагироваться от этого беспорядка для разработчиков.
Yourdon 21-го века?У меня нет четкого ответа на этот вопрос, хотя я хотел бы увидеть больше работ по теориям параллельного программирования, которые позволят инструментам абстрагироваться от этого беспорядка для разработчиков.
Я бы посоветовал пройти курс искусственного интеллекта в колледже / университете. Большинство вещей забавны, их легко понять (по крайней мере, основы), а решения проблем обычно творческие.
Довольно забавно, что никто не упомянул:
- отладка.
- инструменты и идеи, с которыми вы работаете
- и платформа, на которой вы разрабатываете.
Повседневная разработка намного увлекательнее, если вы действительно хорошо знаете свои инструменты, добьетесь большего и облегчите себе жизнь, если знаете, как отлаживать кто-то вводит код без труда.