Набирание скорость на современной архитектуре
У меня нет формальных квалификаций в информатике, скорее я преподавал мне классический ASP назад в эпоху бума доткома и сумел вовлечь себя задание и моя карьера, разработанная оттуда. Я был уверенным и, я думаю, довольно хороший программист в ASP 3, но поскольку другие наблюдали, одна из проблем с классическим ASP была то, что он сделал очень хорошее задание сокрытия основных элементов http, таким образом, Вы могли стать довольно компетентными как программист на основе относительно плохого понимания технологии, с которой Вы работали.
Когда я изменился на.NET сначала, я рассматривал ее как классический ASP, разрабатывая автономные приложения как отдельные веб-сайты просто, потому что я не знал ничего лучшего в то время. Я переместил задания в эту точку и провел следующие несколько лет, работая над единственным сайтом, архитектура которого положилась в большой степени на пользовательские объекты: другими словами, я получил большой опыт, работающий с.NET как средство разработки среднего уровня с помощью довольно старомодного подхода к дизайну OO вроде классического "автомобильного" примера класса, который это так часто используется для обучения OO. Разрушение программ в блоки функциональности и базирование классов и методов вокруг этого. Хотя мы работали при Гибком подходе для управления работой, целая установка была классическим клиент-серверным материалом. Это подошло мне, и я постепенно справлялся с.NET и начинал использовать ее намного больше таким образом, что это должно быть, и я начал видеть питание, свойственное от технологии и точно почему это было настолько лучше, чем старый добрый ASP 3.
В моем последнем задании я внезапно нашел меня заглядывавшим в глубине с двумя довольно молодыми, квалифицированными и очень ультрасовременными программистами. Они создали архитектуру объекта, которая моделирует вдоль большого количества материала, который плохо мне знаком и который, по правде говоря, у меня есть большое понимание проблемы. Приложение основано на модели облачных вычислений с коллективной арендой, и архитектура все слабо связывается с помощью большого количества интерфейсов, фабрик и т.п.. Они используют nHibernate много также. Вскоре после того, как я присоединился, и эти оставленные парни, и я - теперь, предположительно, старший разработчик в системе, технологию которой и архитектуру я действительно не понимаю, и у меня нет никого для задавания вопросов.
Кроме Вас, Интернета.
Откровенно я чувствую, что был передан в в глубине, и я снижаюсь. Я не уверен, является ли это вызвано тем, что я испытываю недостаток в образовании для понимания этого материала, если я просто не, математически возражал достаточно для современных вычислений (моя математика никогда не была большой - мой подход к дизайну должен часто просто отлаживать, пока это не работает, затем осуществите рефакторинг, пока это не выглядит аккуратным), или подарили ли мне просто слишком много слишком радикальной природы сразу. Но единственный способ узнать, который это, состоит в том, чтобы попытаться изучить это.
Таким образом, кто-либо может предложить, чтобы некоторые хорошие места запустились? Хорошие книги, учебные руководства или блоги? Я нашел, что много интернет-материала просто предполагает уровень понимания, что я просто не имею.
Ваш совет очень ценится. Помогите средних лет, всунул разработчика грязи, получают enthusastic снова!
Пожалуйста!
7 ответов
Сидение на пляже - подготовка
Составьте список всего, чего вы не понимаете. На заключительном этапе этот список будет вашим контрольным списком. Очистите свой разум - начните все сначала, «забудьте» все запутанные детали, которые вы уже знаете о своей архитектуре. Найдите все документы, созданные первоначальными архитекторами. Получите документацию по каждой технологии, используемой в вашем проекте. Сделайте кофе.
Плавающий - управление сложностью
Чтобы плавать, вам нужно управлять сложностью. Если вы не справитесь со сложностью должным образом, вы погрузитесь в детали, когда в этом нет абсолютно никакой необходимости, и вы не будете знать, как и где остановиться, погрузившись прямо на дно и утонув.
«Мой подход к дизайну часто состоит в том, чтобы просто отлаживать, пока он не заработает, а затем рефакторировать, пока он не будет выглядеть аккуратно»
Я думаю, что раньше был таким же, как вы. Я разрабатывал решения, начиная с нуля и добавляя по одному элементу за раз, в конечном итоге создавая сложную структуру в моей голове. Я не планировал архитектуру, я не разделял дизайн и реализацию, я просто кодировал, отлаживал, реорганизовывал. Это сработало: поскольку сложность росла медленно, у меня не было проблем с пониманием возникшей архитектуры.
Этот подход просто недостаточно хорош при «наследовании» сложной архитектуры, запланированной другими; вы не можете проглотить всю структуру сразу - потому что здесь слишком много деталей, и вы не можете случайно проглотить маленькие кусочки - потому что вы не поймете, как все они соотносятся друг с другом, и вы никогда не сможете увидеть общую картину.
Программное обеспечение - это загадка управления сложностью. Есть очень большие части, иногда называемые «подсистемами», которые составляют большую картину. Каждый из них состоит из более мелких частей, которые, в свою очередь, также состоят из более мелких частей. Когда вы смотрите на код, все, что вы видите, - это мельчайшие детали. Так что забудьте пока о самом коде, по крайней мере, пока не увидите все более крупные части.
Плавание - отображение архитектуры
Первый шаг к плаванию - увидеть большие части. Для этого вам понадобятся карты. Карта самых больших частей - это архитектура самого высокого уровня. Если первоначальные архитекторы не оставили вам такой карты, вам придется создать ее самостоятельно. Точно так же, как невозможно отобразить регион изнутри долины, вы не можете отобразить свою архитектуру с помощью низкоуровневых деталей. Вам нужно встать на вершину горы, чтобы получить 360-градусный обзор всех долин, холмов и троп. Вам нужно нанести на карту вашу архитектуру сверху.
После того, как у вас есть эта карта верхнего уровня, вы должны получить карты для составляющих ее частей - точно так же, как вы создаете недетализированную карту всего региона, а затем создаете отдельные подробные карты субрегионов. Карта должна описывать различные подсистемы. По крайней мере, он должен описывать обязанности каждой подсистемы, ее внешний интерфейс и то, как она взаимодействует с другими подсистемами.
Погружение - Управление деталями
В дайвинге есть принцип, согласно которому нельзя слишком быстро перемещаться между глубинами из-за изменений давления. Этот принцип соблюдается.Когда вы переходите от работы с одной подсистемой к работе с одной из ее внутренних подсистем, убедитесь, что вы погружаетесь только на следующий уровень сложности / абстракции. Позвольте своему разуму обрабатывать один уровень за раз.
Отдельные концепции, шаблоны, интерфейсы и реализации. nHibernate - это решение для объектно-реляционного сопоставления (ORM). Таким образом, прежде чем разбираться с деталями самого nHibernate, вам необходимо убедиться, что вы понимаете общую концепцию ORM и их место в мире. Factory - это шаблон проектирования, поэтому, прежде чем иметь дело с Factory, вы должны понять, что такое шаблоны проектирования и какова их роль.
Технологии поднимаются и падают, но концепции остаются. Как только вы получите концепции, действительно не имеет большого значения - на архитектурном уровне - как эти концепции проявляются.
Тот факт, что ваша архитектура является слабосвязанной, на самом деле хорошо, потому что это означает, что вы можете понять роль одной подсистемы без необходимости много знать о других подсистемах. Тот факт, что ваша архитектура использует интерфейсы, также хорошо - это означает, что вы можете узнать, как элементы взаимодействуют друг с другом, не изучая, как они работают внутри.
Катание на водных лыжах - приобретение чистых знаний
Есть одна книга, которую, на мой взгляд, обязательно нужно прочитать: Code Complete Стива МакКоннелла. Это изменило мою профессиональную жизнь.
Я надеюсь, что этот пост смог вам чем-то помочь и не является пустой тратой вашего времени.
Шаблоны архитектуры корпоративных приложений - отличная книга, Мартин - легенда.
Честно говоря, я чувствую, что Меня бросили на дно, и я тону. Я не уверен, что это потому, что у меня нет образования, чтобы {{1} } понять эти вещи, если я просто недостаточно разбираюсь в математике для современных вычислений (моя математика никогда не была хороша - мой подход к дизайну часто просто отлаживать, пока он не заработает, а затем рефакторировать, пока он не станет аккуратным), или мне просто представили слишком много слишком радикального характера {{1} } однажды. Но единственный способ узнать , что это такое, - это попробовать и изучить его.
Для меня это из-за отсутствия у вас образования. Люди, обучающиеся сами по себе или на работе, часто не имеют необходимой подготовки, чтобы по-настоящему понять, что скрывается за рамками. Некоторые концепции являются общими для всех информационных систем, и мы изучаем их в школе, поэтому мы можем понять, как эта концепция работает на всех языках ... Вы больше похожи на прагматичного (и эффективного?) Программиста, но вы поймете, что делать ошибки, если у вас нет этого общего фона (но вы должны знать, что вы не одиноки в этом случае ... в частности, php dev, я думаю, у вас нет этого фона).
Как понять связь кода с БД, ORM вроде Hibernate, если вы точно не знаете, что такое транзакция (я думаю, вы знаете, как ее использовать ... (прагматично, я сказал!), Но вы, наверное, никогда не слышали таких понятий, как ACID: http: //en.wikipedia.org / wiki / ACID , полагаю, вы не очень разбираетесь в изоляции транзакций).
Как использовать архитектуру soa с веб-сервисами, rpc, rmi, corba ... эффективно и иметь согласованные данные в своей базе данных, если вы не знаете некоторых концепций, таких как 2-фазная фиксация http://en.wikipedia.org/wiki/Two-phase_commit_protocol
Как написать хороший код, если вы не знаете многих шаблонов проектирования, лучших практик и не знаете, когда их использовать?
Мы могли бы многое сказать.
Дело в том, что вы просто упускаете часть общих знаний в области информатики, которыми обладают все студенты-инженеры (обычно?). Когда мы начинаем работать после инженерной школы, мы не разбираемся в этих вещах, но единственная разница с вами заключается в том, что мы знаем, что существуют очень важные концепции и когда их следует использовать. Таким образом, нам просто нужно прочитать об этом и применить то, что мы узнали из Интернета или нашей команды (потому что в школе мы почти не видим основ, но о многих технологиях).
Я действительно думаю, что для вас нет ничего невозможного, просто вы должны понять много вещей об общих концепциях, которых вы не знаете и о которых много слышали. Без этих знаний вы просто будете изобретать велосипед, и с вашим прагматизмом найдете альтернативные решения, которые, безусловно, работают, но немного грязны ... Например, ваш разработчик может работать, но когда вы вводите высокую нагрузку на свою систему, вы можете есть проблемы с параллелизмом, проблемы с производительностью. Этот недостаток знаний не является проблемой, когда вы работаете в простом контексте, но действительно необходим, когда у вас много обязанностей в сложной системе ...
Я тоже видел случаи, подобные вашему, в прошлом. Но с ежедневным самоотверженным чтением и обсуждениями они, кажется, преуспевают не хуже любых других «молодых и так называемых хороших программистов». Если бы я был на вашем месте, я бы сделал следующее:
- Разбил свои проблемные области на более мелкие части.
- Будет искать книги / статьи по темам из вышеупомянутого списка.
- Буду кодировать образцы самостоятельно и экспериментировать с ними, чтобы лучше понять.
Сказав это, не беспокойтесь о том, что у вас нет математических наклонностей. Я сам изучаю математику и, честно говоря, не так уж много случаев, когда мне нужно использовать эти навыки. «Большинство» корпоративных приложений не требуют таких математических навыков. Кроме того, современные API-интерфейсы настолько продвинуты и просты в использовании, что вам никогда не придется утруждать себя написанием эффективного алгоритма сортировки или чего-либо в этом роде.
Постарайтесь прочитать как можно больше о шаблонах дизайна. «Шаблоны проектирования с головы до головы» - отличная книга для начала, но примеры кода написаны на Java (что на самом деле не имеет значения). «UML Distilled» - еще одна хорошая книга. Есть много других доступных, просто google :). Кроме того, тщательно изучите существующую систему.
всего наилучшего ..
В дополнение ко многим замечательным ресурсам, которые уже перечислены в ответах и, вероятно, будут перечислены, есть немного другой совет - используйте StackOverflow.
Похоже, вы умеете писать очень хорошо продуманные, читаемые и осмелюсь сказать хорошие вопросы.
Итак, всякий раз, когда определенный конкретный архитектурный выбор / шаблон или фрагмент кода не имеет смысла, не стесняйтесь превращать его в вопрос SO (очевидно, в идеале после небольшого повторного исследования).
Также по поводу вашей точки зрения re: math:
Что касается разработки программного обеспечения , единственная математика, которая вам действительно нужна большую часть времени, это:
«дискретная математика» - наборы , графики, деревья и т. д. ... и их практическое применение к структурам данных и алгоритмам
Ограниченный набор навыков алгебры, участвующий в анализе сложности O (n) для последнего
В идеале, интуитивное понимание статистики / вероятности - как Разработчику общего программного обеспечения не всегда нужно уметь проделывать сложные вычисления, но чувство, что «это с большей вероятностью повлияет на мою ситуацию, исходя из вероятности того, что это произойдет, умноженное на размер воздействия», часто является хорошим руководством при выборе дизайна.
Однако ОДНА вещь, которая неоценима для хорошего инженера-программиста, которая часто отличает человека, «хорошо разбирающегося в математике», от «не очень хорошего в математике» - хотя, строго говоря, не связанного с математикой - это способность видеть закономерности.
Если причина того, что вы «не очень хорошо разбираетесь в математике», заключается в том, что вам не хватает этой способности к соблюдению закономерностей, то вы окажетесь в очень невыгодном положении. Это тот навык / способность, который вы должны тренировать в себе прежде всего, чтобы преуспеть в построении систем, ИМХО.
Если речь идет об архитектуре, я всегда смотрю на Шаблоны и методы , если речь идет о стеке разработки Microsoft.
У них есть много хороших технических документов / книг по архитектуре для всех типов приложений.
Вот несколько предложений, ни в коем случае не полный практический или комплексный ответ;
Сделайте время вашего рабочего дня, чтобы узнать о новом материале. Сделайте это время своим рабочим днем, потому что это часть вашей работы. Это не то, чем вы должны заниматься только по вечерам или в выходные. Если вы хотите потратить некоторое время на изучение этого, продолжайте, но не упускайте из виду, что обучение является частью вашей работы, и не входите в мышление, что вы должны скрывать свое невежество дома или что незнание всего губительно для вашей карьеры. Вам решать, как сбалансировать время обучения и рабочее время.
Возьмите несколько больших листов бумаги и коробку цветных карандашей (или MS Visio, если хотите). Начните рисовать два типа диаграмм:
- Интеллектуальные карты, чтобы показать свое понимание новых технологий. Если вы не знаете, что такое интеллектуальные карты, для начала загляните в Википедию.
- Архитектурные схемы системы, за которую вы несете ответственность. Независимо от того, используете ли вы UML, другой широко используемый формат или придуманный вами формат, решать вам.