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

9

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

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

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

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

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

Канадский Люк
источник
2
Трудно собрать кодеров, независимо от того, что вы делаете. На всех этапах сделайте ваш код читабельным, или никто не будет к нему прикасаться. Используйте ООП над процедурным не потому, что это правильно или популярно. Используйте его, потому что требования изменяются и как они изменяются, трудно предсказать. Используйте как можно меньше предположений.
candied_orange
5
«после целых выходных» вы расстроены, все кусочки не встают на свои места прямо на ваших глазах. Вы можете рассмотреть другое хобби. Или согласитесь с тем, что этот путь делается по одному шагу, и наслаждайтесь поездкой.
Мартин Маат
4
То, что ООП является хорошей практикой, далеко не исчерпано . На самом деле, в настоящее время он теряет позиции для функциональных подходов. Если вы все еще хотите впихнуть свой код в объектный подход, вы можете найти это полезным. Я лично считаю, что процедурные или функциональные возможности намного проще и более интуитивно понятны для веб-приложения, которое имеет естественную точку входа, вызывает стек до надежного хранилища (базы данных) и возвращает обратно в стек.
jpmc26
Что касается фактического создания сообщества с открытым исходным кодом, которое будет процветать , я только что связал статью с некоторыми очень проницательными советами, основанными на опыте и фактическом наблюдении за влиянием различных подходов на ключевые цифры (например, количество оставшихся новых участников). (Не моя статья, мне просто нравится.)
Wildcard
1
В основе ООП лежит инкапсуляция изменений состояния за простыми или абстрактными интерфейсами ... что не очень подходит для написания серверов без состояний, которые обрабатывают запросы. Правильное использование ОО-языков для той работы, которую вы хотите выполнять, во многом больше похоже на функциональное программирование, чем на ОО-программирование, поэтому может оказаться, что вам трудно применить эти учебники.
Мэтт Тиммерманс

Ответы:

12

Лучшие практики - это, в основном, предложения и предложения, собранные на основе опыта, чтобы помочь сделать проекты более легкими.

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

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

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

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

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

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

удачи

Newtopian
источник
4
«Абсолютно важная вещь, которую нужно сделать в программном проекте - это ... ну ... закончить, отправить ... короче заставить его работать!» - Я не могу отказать этому достаточно. Так много людей упускают момент, что это должно быть их фокусом все время.
ivan_pozdeev
@ivan_pozdeev У меня ушло много времени, прежде чем я осознал это в своей карьере, и до того, как я сделал все, что у меня оставалось, это череда незаконченных неудач. Тогда я отправил кое-что, что я посчитал провалом, потому что качество оказалось одним из моих самых успешных проектов. Независимо от того, что вы цените, вы ставите на мнение других, в конце концов, именно для них вы делаете то, что делаете.
Newtopian
3
Что значит "* способный"?
Роберт Харви
1
@RobertHarvey Тестируемый, ремонтопригодный, переносимый, многоразовый и т. Д., В основном, любого конкретного качества, к которому можно стремиться. Только то, что они имеют тенденцию быть словами, которые заканчиваются на «исправление» после исправления, - это все. Я полагаю, что я только что получил ленивый плюс, когда оптимизирую для одного аспекта очень часто, это означает компромисс по другим аспектам, поэтому я избегал быть слишком конкретным, чтобы не привлекать придирки к касательной с основной точки зрения.
Newtopian
8

TL; DR

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


А теперь длинный ответ ...

1. «Рабочее программное обеспечение является основной мерой прогресса». ( Agile Manifesto )

Если вы видите границы своих знаний, это здорово! Преследуй края! Продолжай учиться! Но имейте в виду, вы можете учиться и анализировать вечно .

Построй что-нибудь.


2. Учиться и делать ошибки; но не делайте "плохих". *

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

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

Если вы делаете небольшой CLI для себя : работайте так, как хотите.

Если вы пишете веб - портал банка: окружите себя очень опытных разработчиков.


3. «Лучшие практики» должны быть написаны в кавычках и должны быть подмигнуты.

«Практики» превращаются в «лучшие практики», когда они замечены как успешные в достижении X, по крайней мере, в некоторых случаях. Кто-то признает пользу Практики A для достижения Преимущества X и объявляет эту практику «лучшей практикой» в Интернете. Другие согласны - часто по уважительной причине. Но с этого момента мы, как правило, теряем из виду, почему некоторые практики являются «лучшими», а другие - «антипаттернами» или «вонючими».

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

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

Хм ...

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

Призовите POAP ! (Да. Мой блог.)

Принципы, модели и практики не являются конечными целями.

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

(POAP не освобождается от POAP.)

Так, вы, возможно, не до конца понимаете каждый нюанс DI, например. Но, если вы понимаете намерение, вы будете знать, если вы «должны» использовать DI, и вы будете в некотором роде лучше понимать DI.

И, как только вы выпустите продукт, вы можете подумать о том, был ли DI (или что-то еще) действительно полезным. Если так, сформулируйте почему в письменной форме. Если нет, сформулируйте, почему в письменной форме ...


Чтение бонусов / Несколько актуально:

Анализ паралича это вещь. Вам нужно анализировать и учиться; но вы также должны сделать вещи. Баланс.

Вы всегда можете чувствовать себя ковбойским кодером .


* На самом деле вы будете делать плохие ошибки, если будете делать что-то примечательное. Но вы человек, я полагаю. Итак, мы прощаем тебя раньше времени ... Или, по крайней мере, я делаю. Может быть. ... ну ... посмотрим.

svidgen
источник
7

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

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


источник
6

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

Среды быстрой разработки приложений являются соблазнительными, потому что вы можете сделать многое за очень короткое время. Я создал целую систему учета в Access один раз. Но вы сказали это сами: вы не можете перенести подобное приложение в Интернет без переписывания, и инструменты, которые вам там нужны, действительно разные.

Есть причины, по которым никто больше не использует инструменты визуального дизайна, такие как Access или Visual Basic. Они имеют тенденцию изолировать вас от кода, который действительно чего-то добивается. Доступ - это прекрасный инструмент, но он требует того, чтобы веб-приложения были специально разработаны, чтобы избежать: установка. Настройка его внешнего вида может быть сложной; даже если вам это не нужно в Интернете, приложение Access всегда будет очень похоже на любое другое приложение Access. Большинство людей, которые пишут свое первое приложение Access, не знают достаточно, чтобы написать хорошее приложение, а Access позволяет легко написать плохое.

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

Вот почему я думаю, что вы создали ложную дихотомию. Никто не изучает все «лучшие практики» в первую очередь. Они учат их, как они идут. Но чтобы быть продуктивным на любом языке ООП, я думаю, вам нужно знать некоторые ООП или, по крайней мере, как классы в основном работают.

Что бы это ни стоило, я не думаю, что PHP - ваш лучший выбор. PHP привлекателен, потому что он «неглубокий», то есть вам не нужно много знать, чтобы написать работающую программу. Лучшие практики в основном оставлены на усмотрение разработчика, а это значит, что PHP не поможет вам писать «хорошие» программы. Это не обязательно плохо, но это означает, что, как и Access, вы, в конечном счете, можете отказаться от PHP для более надежной платформы.

Роберт Харви
источник
Как программист, который в свободное время программирует только «для удовольствия», что бы вы посчитали более надежным при запуске с сервера Debian?
Канадский Люк
1
Если это просто для удовольствия, PHP может быть вполне адекватным. Он обладает тем преимуществом, что не тратит огромное количество времени на его изучение, если вы решите перейти к чему-то другому. Это особенно полезно для небольших приложений.
Роберт Харви
Выбор языка здесь не имеет значения. Этот последний абзац, кажется, не добавляет много к вашему в противном случае хорошему ответу.
Cypher
1
@Cypher: Это относится к тем же причинам, которые я изложил в своем описании Access. Прочитайте еще раз часть, в которой говорится, что «лучшие практики в основном оставлены на усмотрение разработчика».
Роберт Харви
Нет необходимости в непристойных замечаниях. Ваши комментарии по PHP предвзяты и непредвзяты и отвлекают от хорошего момента (ваш второй абзац с последним). Но эй ... это твой ответ.
Cypher
1

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

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

Статьи в Интернете, заявления экспертов отрасли и советы старших коллег вполне могут быть ошибочными. Я видел это много.

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

Также поймите, почему рекомендуются определенные методы. Например, ООП - это инкапсуляция. Вы можете инкапсулировать другими способами (процедуры также касаются инкапсуляции).

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

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

USR
источник