Достижение скорости на современной архитектуре

У меня нет каких-либо формальных квалификаций в области информатики, а я преподавал себе классический ASP еще во времена бума доткома и сумел получить себе работу, и моя карьера развилась оттуда. Я был уверенным и, я думаю, довольно хорошим программистом в ASP 3, но, как другие наблюдали одну из проблем с классическим ASP, было то, что он отлично справлялся с тем, чтобы скрыть nitty-gritty http, чтобы вы могли стать достаточно компетентными, поскольку программист на основе относительно плохого понимания технологии, с которой вы работали.

Когда я сначала перешел на .NET, я рассматривал его как классический ASP, создавая автономные приложения как отдельные веб-сайты просто потому, что в то время я не знал ничего лучшего. Я переместил работу на этом этапе и провел следующие несколько лет, работая над одним сайтом, архитектура которого в значительной степени основывалась на пользовательских объектах: другими словами, я приобрел большой опыт работы с .NET в качестве инструмента для среднесрочного развития, образный подход к дизайну OO по образцу классического примера "автомобиль", который так часто использовался для обучения OO. Разбивание программ на блоки функциональности и базирование ваших классов и методов вокруг этого. Хотя мы работали под управлением Agile для управления работой, вся установка была классической клиент-серверной. Это мне подошло, и я постепенно освоился с .NET и начал использовать его гораздо больше в том виде, в котором он должен быть, и я начал видеть силу, присущую технологии, и именно почему она была намного лучше, чем старый добрый ASP 3.

В моей последней работе я внезапно погрузился в глубокий конец с двумя довольно молодыми, опытными и очень передовыми программистами. Они построили архитектуру сайта, которая моделирует множество вещей, которые мне носят, и, по правде говоря, у меня много проблем с пониманием. Приложение построено на модели облачных вычислений с многопользовательской лицензией, и архитектура все слабо связана с использованием множества интерфейсов, заводов и т.п. Они также используют nHibernate. Вскоре после того, как я присоединился, оба этих парня ушли, и я теперь, как полагаю, старший разработчик в системе, чья технология и архитектура я действительно не понимаю, и я не могу никому задавать вопросы.

Кроме вас, интернет.

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

Так может ли кто-нибудь предложить хорошие места для начала? Хорошие книги, учебники или блоги? Я нашел много интернет-материалов просто предполагает уровень понимания, которого у меня просто нет.

Ваш совет очень ценится. Помогите среднему, застрявшему в грязи, проявить энтузиазм снова!

Пожалуйста!

Ответ 1

Сидя на пляже - подготовка

Составьте список всего, что вы не понимаете. На заключительном этапе этот список будет вашим контрольным списком. Очистите свой разум - приступайте к новому запуску, "забудьте" все запутанные детали, которые вы уже знаете о своей архитектуре. Копайте каждый документ, созданный оригинальными архитекторами. Получите документацию для каждой технологии, используемой в вашем проекте. Сделать кофе.

Плавающая - управляющая сложность

Чтобы плавать, вам нужно управлять сложностью. Если вы не справитесь со сложностью должным образом, вы погрузитесь в детали, когда вам абсолютно не нужно, и вы не будете знать, как и где остановиться, погрузившись прямо в низу и утонув.

"Мой подход к дизайну часто просто отлаживать, пока он не будет работать, тогда рефакторинга, пока он не выглядит аккуратным"

Я думаю, что я был таким же, как ты. Я разработал решения, начиная с нуля и добавляя одну штуку за один раз, в конечном итоге содержащую сложную структуру внутри моей головы. Я не планировал архитектуру, я не разделял дизайн и реализацию, я только что закодировал, отлаживал, реорганизовал. Это сработало: с тех пор, как сложность росла медленно, я не имел проблем с пониманием архитектуры, которая возникла.

Этот подход просто недостаточно хорош, когда "наследует" сложную архитектуру, запланированную другими; вы не можете усвоить всю структуру сразу - потому что слишком много деталей, и вы не можете случайным образом усвоить маленькие кусочки - потому что вы не поймете, как все они связаны друг с другом, и вы никогда не увидите большую картину.

Программное обеспечение - это головоломка управления сложностью. Есть очень большие куски, иногда называемые "подсистемами", которые составляют общую картину. Каждый из них состоит из небольших кусков, которые, в свою очередь, также состоят из небольших кусков. Когда вы смотрите на код, все, что вы видите, это самые крошечные части. Так что забудьте о самом коде на данный момент, по крайней мере, пока не увидите все большие куски.

Плавание - отображение архитектуры

Первый шаг к плаванию - это увидеть большие куски. Для этого вам нужны карты. Карта для самых больших частей - архитектура самого высокого уровня. Если оригинальные архитекторы оставили вас без такой карты, вам придется создать ее самостоятельно. Так же, как невозможно отобразить регион изнутри долины, вы не можете сопоставить свою архитектуру с деталями низкого уровня. Вам нужно стоять на вершине горы, чтобы получить 360-градусный вид на все долины, холмы и тропинки. Вам нужно отобразить свою архитектуру сверху.

После того, как у вас есть карта верхнего уровня, вы должны получить карты для составляющих ее частей - так же, как вы создаете неинформативную карту всего региона, а затем создаете отдельные подробные карты субрегионов. Карта должна описывать различные подсистемы. По крайней мере, он должен описывать обязанности каждой подсистемы, ее внешний интерфейс и то, как он взаимодействует с другими подсистемами.

Дайвинг - управление деталями

В дайвинге есть такой принцип, который говорит, что вы не должны слишком быстро перемещаться между глубинами из-за изменений давления. Этот принцип имеет место. Когда вы переходите от работы с одной подсистемой к работе с одной из своих внутренних подсистем, убедитесь, что вы только погружаетесь в следующий уровень сложности/абстракции. Пусть ваш разум обрабатывает один уровень за раз.

Отдельные понятия, шаблоны, интерфейсы и реализации. nHibernate - это решение Object-Relational Mapping (ORM). Таким образом, прежде чем вы будете разбираться с деталями самого nHibernate, вам нужно убедиться, что вы понимаете общую концепцию ORM и их место в мире. Factory является шаблоном проектирования, поэтому перед тем, как вы справитесь с Factory, вы должны понять, какие шаблоны проектирования и какова их роль.

Технологии поднимаются и падают, но концепции остаются. Как только вы получаете концепции, это действительно не имеет большого значения - на архитектурном уровне - как проявляются эти понятия.

Тот факт, что ваша архитектура тесно связана, на самом деле хорошо, потому что это означает, что вы можете понять роль одной подсистемы, не зная о других подсистемах. Тот факт, что ваша архитектура использует интерфейсы, также хороша - это означает, что вы можете узнать, как элементы взаимодействуют друг с другом, не изучая, как они работают внутри страны.

Уотерскинг - Приобретение дистиллированных знаний

Есть одна книга, которую я считаю "обязательным для чтения": Code Complete by Steve McConnell. Это изменило мою профессиональную жизнь.

Я надеюсь, что этот пост сумел каким-то образом помочь вам и не является полной тратой времени.

Ответ 2

Вот несколько предложений, отнюдь не полный ответ "все-в-одном" или "все-в-одном";

Сделайте время в рабочий день, чтобы узнать о новых материалах. Сделайте это в свой рабочий день, потому что это часть вашей работы. Это не то, что вы должны делать только по вечерам или по выходным. Если вы хотите потратить часть своего времени на изучение этого, идите прямо вперед, но не забывайте, что обучение является частью вашей работы и не вникает в то, что вам нужно скрывать свое невежество дома или что не зная, что все роковое для вашей карьеры. Это зависит от вас, чтобы сбалансировать время обучения и рабочее время.
Получите несколько больших листов бумаги и коробку цветных карандашей (или MS Visio, если хотите). Начните рисовать два типа диаграмм:
- Карты разума, чтобы показать ваше понимание новых технологий. Если вы не знаете, какие карты разума, нажмите Википедию, чтобы начать с.
- Архитектурные диаграммы системы, за которую вы отвечаете. Независимо от того, используете ли вы UML или какой-либо широко используемый формат или какое-либо из ваших собственных разработок зависит от вас.

Ответ 3

В дополнение к многим большим ресурсам, уже перечисленным в ответах и, возможно, перечисленным, немного другим советам - используйте StackOverflow.

Вы, кажется, умеете писать очень хорошо продуманные, читаемые и осмеливаетесь сказать, что это хорошие вопросы.

Итак, всякий раз, когда определенный специфический архитектурный выбор/шаблон или фрагмент кода не имеет смысла, не стесняйтесь превращать его в вопрос SO (очевидно, идеально после повторного изучения бит).

Кроме того, в отношении вашей точки re: math:

Что касается программного обеспечения engineering, единственная математика, в которой вы действительно нуждаетесь большую часть времени:

"discret math" - наборы, графики, деревья и т.д.... и их практическое применение к структурам данных и алгоритмам
Умение с ограниченной алгеброй, участвующее в анализе сложности O (n) для последнего
В идеале, интуитивное понимание статистики/вероятности - как универсального инженера-программиста вы не всегда должны иметь возможность делать предварительные вычисления, но чувствуете, что "это, скорее всего, повлияет на мою ситуацию на основе его вероятность того, что время его разрастания" часто является хорошим ориентиром в выборе дизайна.

Тем не менее, ОДНА вещь, которая неоценима в хорошем инженере-программисте, который часто отличает "хорошего в математике" от "плохого в математике" - хотя и не строго говоря, связанная с математикой - это способность видеть узоры.

Если причина, по которой вы "не хороши в математике", заключается в том, что вам не хватает способности к соблюдению паттерна, тогда вы окажетесь в невыгодном положении. Это один умение/умение, которое вы должны тренировать в себе выше всех остальных, чтобы преуспеть в системах архитектуры, ИМХО.

Ответ 4

Шаблоны архитектуры корпоративных приложений - отличная книга, Мартин - легенда.

Ответ 5

Если речь идет об архитектуре, я всегда смотрю "Шаблон и практика" , если речь идет о стеке разработки Microsoft.

У них есть много хороших публикаций/книг об архитектуре для всех видов типов приложений.

Ответ 6

Я видел случаи, подобные вашим, в прошлом. Но со специальным ежедневным чтением и parctise они, кажется, делают так же, как и любые другие "молодые и так называемые хорошие программисты". Если бы я был на вашем месте, я бы это сделал:

Разделите мои области проблем на более мелкие куски.
Идет поиск книг/статей по темам в вышеупомянутом списке.
Будет ли скомпоновать примеры кода и экспериментировать с ними, чтобы получить более глубокое понимание.

Сказав это, не беспокойтесь, не имея математического наклона ума. Я сам математик и, честно говоря, часто бывает, когда я должен использовать эти навыки. "Большинство" корпоративных приложений не требуют таких навыков математики. Кроме того, modenr day apis настолько продвинуты и просты в использовании, что вам никогда не придется беспокоиться о написании эффективного сортировочного алгоритма или чего-то подобного.

Постарайтесь читать как можно больше на Design Patterns. "Начать первые образцы дизайна" - отличная книга, но примеры кода находятся на Java (что не должно иметь значения). "UML Distilled" - еще одна хорошая книга. Есть много других доступных, просто Google:). Кроме того, тщательно изучите существующую систему.

все лучшее..

Ответ 7

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

Для меня это из-за вашего отсутствия образования. Люди, которые изучают себя или работают часто, не имеют необходимого фона, чтобы действительно понять, что находится за сценой рамки. Некоторые концепции являются общими для всех информационных систем, и мы изучаем их в школе, поэтому мы можем понять, как эта концепция работает на всех языках... Вы больше похожи на прагматичного (и эффективного?) Программиста, но вы ошибаетесь, У меня есть общий фон (но вы должны знать, что вы не одиноки в этом случае... особенно php dev, я думаю, не имеет этого фона).

Как понять отношение кода с БД, ORM, как Hibernate, если вы точно не знаете, что такое транзакция (я думаю, вы знаете, как ее использовать... (прагматичный, я сказал!), но вы никогда не слышали таких как ACID: http://en.wikipedia.org/wiki/ACID, я думаю, вы не знаете много об изоляции транзакций).

Как использовать soa-архитектуру с web-сервисами, rpc, rmi, corba... эффективно и иметь возможность иметь согласованные данные в вашем db, если вы не знаете некоторые понятия, такие как 2 phaze commit http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Как написать хороший код, если вы не знаете много шаблонов проектирования, лучших практик и не знаете, когда их использовать?

Мы могли бы сказать много чего.

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

Я действительно думаю, что для вас нет ничего невозможного, вы просто должны многое знать об общих понятиях, которые вы не знаете, и вы слышали много. Без этих знаний вы просто попытаетесь изобрести колесо, и ваш прагматизм найдет альтернативные решения, которые, безусловно, будут работать, но просто немного грязны... Например, ваш разработчик мог бы работать, но когда вы вводите высокую нагрузку на свою систему, вы можете есть проблемы с проблемами, проблемы с производительностью. Эта нехватка знаний - это не вопрос, когда вы находитесь в простом контексте, но действительно необходим, когда у вас много ответственности в сложной системе...