Написание дополнительного кода, чтобы избежать изучения новых фреймворков - PullRequest
4 голосов
/ 05 марта 2010

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

Я выучил ТОННУ во время моей работы, и мне не терпится реорганизовать мой код, чтобы сделать его более читабельным, чтобы будущие новые сотрудники могли окунуться и помочь мне в этом. Я также ДЕЙСТВИТЕЛЬНО хочу упростить добавление новых функций без необходимости взламывать вещи вместе. Я думаю, что было бы полезно изучить такие основы, как Prism для WPF / Silverlight, но у меня есть огромный список дел (так как я работаю в одиночном магазине), и, похоже, это займет довольно приличное количество времени. просто чтобы научиться им пользоваться.

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

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

Ответы [ 7 ]

5 голосов
/ 05 марта 2010

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

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

4 голосов
/ 05 марта 2010

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

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

Вы не решите эту проблему, изучив призму или любую другую библиотеку, но это неверное обоснование.

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

Как рекомендация из личного опыта: пишите строительные блоки, а не фреймворки.Фреймворки хороши, когда нужно делать одно и то же приложение с разными логотипами компании снова и сноваИли, как говорит Алекс из TDWTF, ключ к различиям , а не к сходствам.


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

2 голосов
/ 05 марта 2010

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

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

1 голос
/ 06 марта 2010

Я буду играть противно: ЯГНИ (Тебе это не понадобится).

Что делать, если рамки

  • Плохо спроектирован?
  • Багги?
  • Слишком медленно?
  • Через два года будет другой, и старая версия не будет поддерживаться?

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

Вот несколько советов, которые, я надеюсь, поможет вам ответить на ваши более конкретные вопросы:

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

  • Подробнее о каркасе. Или несколько рамок. Может быть, вы можете попробовать небольшой пилотный проект, скажем, через 1-4 дня.

  • Почетная стратегия - узнавать о каркасе не для того, чтобы использовать каркас, а для того, чтобы выбрать лучшие идеи и принять их в свои собственные проекты.

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

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

1 голос
/ 05 марта 2010

Я был в похожей ситуации, когда закончил колледж. Я получил предложение от большой компании примерно через 1,5 года после моего пребывания в маленькой компании. Вот что я узнал ( может отличаться для вас и других ):

  1. Это была потрясающая идея - работать в маленькой компании сразу после школы. Я говорю это, потому что вы должны носить много разных шляп. Например, вы могли бы написать код, протестировать код, развернуть код, написать хранимые процессы и т. Д. Конечный результат заключается в том, что вы знакомы со всем процессом от концепции до чего угодно. Я думаю, что этот опыт очень важен.
  2. Я любил писать код. Я помню дни, когда я ехал домой и думал о своем дне, потраченном на решение вопросов поддержки производства. Я тратил больше времени на поддержку клиентов и написание «разовых», которые я в основном не писал.
  3. Работа в большой компании - плохая идея, право колледжа. Когда вы работаете в большой компании, у них есть определенная роль для вас, и у вас есть определенные границы. Если вы являетесь разработчиком в большой компании, скорее всего, вы не развертываете приложение (я) в производство и не настраиваете хранимые процессы.
  4. Работать в большой компании - отличная идея после работы в маленькой. Это потому, что если вы работаете в небольшой компании, это заставит вас узнать гораздо больше, чем просто программирование. И если вы понимаете, что станете лучшим разработчиком.
  5. Работа с хорошими разработчиками делает вас лучше. Когда вы работаете с группой хороших парней, вам станет лучше. Это потому, что у каждого разработчика есть особая история, которую он приносит в группу, и вы все учитесь друг у друга. В группе, с которой я работаю в основном сейчас, есть: эксперт MSBuild, эксперт Silverlight и F #, и другие хорошие парни. Поэтому некоторые ребята учат MSBuild у меня, а я учусь у них. Просто общение с хорошими парнями может сделать вас лучше.

Так что, если бы я был тобой, не проводи там слишком много времени. Может быть, через 1 или 2 года после этого найти работу где-нибудь, где есть талантливые разработчики. Вы будете намного лучшим разработчиком через 5 лет. Я знаю, что я из-за моего переезда.

1 голос
/ 05 марта 2010

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

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

0 голосов
/ 10 марта 2010

У кого есть этот инструмент?

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...