Прежде всего, я хочу сказать, что я привык заниматься процедурным программированием как своим хобби - я пытаюсь выучить ООП на нескольких языках и понять теорию , но не практику.
У меня есть pet-проект, который я хотел построить, в частности, на PHP с базой данных (не важно, какой именно). Моей главной причиной было использование приложения на любом устройстве, поэтому веб-приложение казалось логичным выбором.
Я понимаю, что для создания поддерживаемых PHP WebApps необходимо использовать ООП, классы, фреймворки, библиотеки и т. Д. Это звучит логично, поэтому я решил попробовать некоторые из популярных. Тем не менее, после целых выходных, просто попробовав их и попробовав пройти уроки, я остался растерянным и разочарованным, пытаясь адаптировать уроки к моему небольшому проекту.
Я решил, в основном для проверки концепции, создать приложение в другой программе (Microsoft Access) и выполнил свои основные задачи всего за пару часов - за исключением веб-части.
Мой вопрос заключается в том, должен ли я идти по пути, который я знаю, затем попытаться реализовать правильные методы кодирования или я должен начать с хороших методов кодирования и попытаться придумать свой путь? Для этого проекта я хотел бы, чтобы он был открытым исходным кодом на GitHub, поэтому я был бы открыт для других людей, использующих и изменяющих мой код, но я также знаю, что если код написан плохо, было бы сложно собрать кодеров, чтобы помочь.
источник
Ответы:
Лучшие практики - это, в основном, предложения и предложения, собранные на основе опыта, чтобы помочь сделать проекты более легкими.
Ключевыми аспектами этого ИМХО является опытная часть. Хотя эти лучшие практики являются хорошим способом поделиться опытом с начинающими, я думаю, что для того, чтобы по-настоящему понять, что является лучшей практикой, нужен минимальный уровень опыта. В противном случае это означает слепое следование им как верховенство закона, которое, в конце концов, замедлит ваше обучение, так как вы постепенно позволяете другим думать за вас.
В любом случае, самое важное для меня в программном проекте - это ... ну ... закончить, отправить ... короче заставить его работать!
Все, что было до этого момента, - пародия, плод вашего воображения. Только когда у вас есть что-то, что работает, вы сможете по-настоящему оценить его, если оно медленное, сложное в обслуживании, трудное для тестирования и т. Д. В процессе работы все это откроет вещи, для которых, возможно, существует лучшая практика, которая поможет вам переосмыслить это. таким образом, чтобы легче было достичь этой цели.
Так что да, начните с того, что вы знаете в первую очередь, обратите внимание на трудные вещи, которые вы делаете. Когда вы ударите стену, сделайте шаг назад и посмотрите на эту стену, узнайте, из чего она сделана. Во многих случаях вы поймете, что вы корень проблемы. Отсутствие понимания какой-либо части проблемы, которую вы пытаетесь решить, недостаток знаний о том, как лучше использовать имеющиеся у вас инструменты, или незнание других инструментов, которые все время находятся у вас под носом, но не были готовы начать свое мастерство.
В то же время, продолжайте читать о новых способах делать вещи. Прочитайте эти рекомендации и попробуйте выяснить, применимы ли они к чему-то, что вам сложно найти в вашем проекте. Если нет, помните об их существовании и время от времени возвращайтесь к ним. Оставайтесь любопытными. Со временем вы увидите, что сделанные выше наблюдения просто естественным образом соответствуют полученным знаниям.
Наконец, поэкспериментируйте с тем, что вы узнали, и посмотрите, упростит ли это все. продолжайте в том же духе, и в конце концов вы прочитаете лучшие практики, какие они есть. Просто простые советы от людей, которые пострадали и узнали способ сделать это проще. Черт возьми, вы можете даже не согласиться с некоторыми из них и увидеть, что ваш путь на самом деле работает лучше для вас. Но без знания вы просто ходите вслепую.
удачи
источник
TL; DR
Вы никогда не узнаете все это. Вокруг каждой «вещи», которую вы можете знать, всегда есть больше глубины и широты. Учитесь, как вы идете. Применяйте «лучшие практики», которые вы считаете актуальными сейчас. Делать ошибки. Просто постарайтесь избежать действительно дорогостоящих ошибок. Найдите наставников, если ваш проект может привести к дорогостоящим ошибкам.
А теперь длинный ответ ...
1. «Рабочее программное обеспечение является основной мерой прогресса». ( Agile Manifesto )
Если вы видите границы своих знаний, это здорово! Преследуй края! Продолжай учиться! Но имейте в виду, вы можете учиться и анализировать вечно .
Построй что-нибудь.
2. Учиться и делать ошибки; но не делайте "плохих". *
Продолжайте раздвигать границы своих знаний / навыков. Вы будете делать ошибки. Вы можете учиться у них. Но вам не нужно быть безрассудным .
Время, которое вы тратите на поиск и работу с более опытными разработчиками и наставниками, должно увеличиваться пропорционально стоимости бизнеса и профилю рисков проекта.
Если вы делаете небольшой CLI для себя : работайте так, как хотите.
Если вы пишете веб - портал банка: окружите себя очень опытных разработчиков.
3. «Лучшие практики» должны быть написаны в кавычках и должны быть подмигнуты.
«Практики» превращаются в «лучшие практики», когда они замечены как успешные в достижении X, по крайней мере, в некоторых случаях. Кто-то признает пользу Практики A для достижения Преимущества X и объявляет эту практику «лучшей практикой» в Интернете. Другие согласны - часто по уважительной причине. Но с этого момента мы, как правило, теряем из виду, почему некоторые практики являются «лучшими», а другие - «антипаттернами» или «вонючими».
Проблема в том, что «лучшая практика» никогда не бывает корыстной. «Антипаттерны» сами по себе не являются дьявольскими. И даже "зловоние" только иногда происходит от гниения. Иногда эта вонь - просто вкусный, вкусный сыр ...
Вы не практикуете такие вещи, как «внедрение зависимостей» (DI), потому что «внедрение зависимостей» по своей сути ценно для бизнеса. Это даже отдаленно не важно для создания работающего продукта. Это выполняет то, что вы, возможно, хотите в вашем конечном продукте. Но это также может сделать вашу работу дольше без пользы ...
Хм ...
Итак, вы должны следовать "лучшим практикам?" Даже если ты их не понимаешь? ... эээ ... да. Я имею ввиду нет. Но да. Но только те, которые действительно относятся к вам и вашему программному обеспечению и его назначению.
Призовите POAP ! (Да. Мой блог.)
Так, вы, возможно, не до конца понимаете каждый нюанс DI, например. Но, если вы понимаете намерение, вы будете знать, если вы «должны» использовать DI, и вы будете в некотором роде лучше понимать DI.
И, как только вы выпустите продукт, вы можете подумать о том, был ли DI (или что-то еще) действительно полезным. Если так, сформулируйте почему в письменной форме. Если нет, сформулируйте, почему в письменной форме ...
Чтение бонусов / Несколько актуально:
Анализ паралича это вещь. Вам нужно анализировать и учиться; но вы также должны сделать вещи. Баланс.
Вы всегда можете чувствовать себя ковбойским кодером .
* На самом деле вы будете делать плохие ошибки, если будете делать что-то примечательное. Но вы человек, я полагаю. Итак, мы прощаем тебя раньше времени ... Или, по крайней мере, я делаю. Может быть. ... ну ... посмотрим.
источник
Может быть, стараться изо всех сил, но все еще грузить что-то? Существует две разные силы между тем, как пользователи оценивают качество и привлекательность продукта, и тем, как разработчики определяют качество кода. Постарайтесь сделать эти две силы максимально гармоничными. Сосредоточив внимание на одном из них за счет другого, вы, как правило, выбираете наиболее контрпродуктивные маршруты.
источник
Ну, во-первых, я хотел бы предположить, что принятие хороших методов кодирования не обманывает ... Хитрость заключается в понимании цели каждой практики и как правильно ее реализовать.
Среды быстрой разработки приложений являются соблазнительными, потому что вы можете сделать многое за очень короткое время. Я создал целую систему учета в Access один раз. Но вы сказали это сами: вы не можете перенести подобное приложение в Интернет без переписывания, и инструменты, которые вам там нужны, действительно разные.
Есть причины, по которым никто больше не использует инструменты визуального дизайна, такие как Access или Visual Basic. Они имеют тенденцию изолировать вас от кода, который действительно чего-то добивается. Доступ - это прекрасный инструмент, но он требует того, чтобы веб-приложения были специально разработаны, чтобы избежать: установка. Настройка его внешнего вида может быть сложной; даже если вам это не нужно в Интернете, приложение Access всегда будет очень похоже на любое другое приложение Access. Большинство людей, которые пишут свое первое приложение Access, не знают достаточно, чтобы написать хорошее приложение, а Access позволяет легко написать плохое.
Так что теперь вы смирились с изучением новой технологии для размещения вашего приложения в Интернете. Должны ли вы построить его правильно с самого начала? Конечно. Но изучение новой среды разработки и философии похоже на изучение любой другой вещи; Вы должны сделать это на некоторое время, чтобы все было правильно.
Вот почему я думаю, что вы создали ложную дихотомию. Никто не изучает все «лучшие практики» в первую очередь. Они учат их, как они идут. Но чтобы быть продуктивным на любом языке ООП, я думаю, вам нужно знать некоторые ООП или, по крайней мере, как классы в основном работают.
Что бы это ни стоило, я не думаю, что PHP - ваш лучший выбор. PHP привлекателен, потому что он «неглубокий», то есть вам не нужно много знать, чтобы написать работающую программу. Лучшие практики в основном оставлены на усмотрение разработчика, а это значит, что PHP не поможет вам писать «хорошие» программы. Это не обязательно плохо, но это означает, что, как и Access, вы, в конечном счете, можете отказаться от PHP для более надежной платформы.
источник
Рассматривайте ООП как еще один шаблон, который вы можете применить в нужное время. ООП не та основа, которая методично может решить любую задачу. Такого не бывает в программной инженерии.
Также обратите внимание, что то, что люди называют хорошей практикой , иногда сомнительно. Я часто видел, как неопытные разработчики применяют очень сложные шаблоны программирования, которые не нужны для данной проблемы. Сложность кода должна соответствовать сложности задачи. Простота является важной ценностью.
Статьи в Интернете, заявления экспертов отрасли и советы старших коллег вполне могут быть ошибочными. Я видел это много.
Поэтому я рекомендую вам применить самое простое решение, которое решает вашу проблему. Вероятно, это будет охватывать использование одной из популярных платформ в вашем пространстве. В рамках этого ограничения вы можете свободно выбирать, какой код вам нравится. Не просто подумайте, что их способ сделать это подходит для вашего случая.
Также поймите, почему рекомендуются определенные методы. Например, ООП - это инкапсуляция. Вы можете инкапсулировать другими способами (процедуры также касаются инкапсуляции).
Отрицательный пример: иногда люди пишут слой доступа к данным, чтобы абстрагировать базу данных. Здесь суть этого шаблона заключается в том, чтобы стать независимым от конкретного хранилища данных и предоставить более простой интерфейс для более высоких уровней кода. Но если вам не нужны эти преимущества, вам не нужен уровень доступа к данным, и вы можете сохранить работу. Тем не менее, многие эксперты рекомендуют всегда делать DAL, который является неправильной рекомендацией.
Я считаю, что с хорошим кодом часто весело работать. Это весело, потому что вы работаете над реальными требованиями, а не заботитесь об инфраструктурных проблемах. Если вы обнаружите, что то, что вы делаете, - это слишком много тяжелой работы, то, скорее всего, вы выбрали неправильный набор шаблонов.
источник