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

По-перше, я хочу сказати, що я звикла займатися процедурним програмуванням як своє хобі - я намагаюся вивчити OOP на пару мовах і розумію теорію , тільки не практику.

У мене є проект для домашніх улюбленців, який я хотів створити, зокрема, в PHP з базою даних бази даних (не важливо, яку саме). Моя основна причина полягала в тому, що додаток можна було використовувати на будь-якому пристрої, тому WebApp видався логічним вибором.

Я розумію, що для створення реконструйованих PHP WebApps слід використовувати OOP, класи, фреймворки, бібліотеки тощо. Це звучить логічно, тому я вирішую спробувати деякі з популярних. Однак після цілих вихідних просто пробуючи їх і намагаючись пройти підручники, я залишаюся розгубленим і розчарованим, намагаючись адаптувати підручники до мого невеликого проекту.

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

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

Найкращі практики - це переважно пропозиції та пропозиції, зібрані з досвіду, що сприяють спрощенню проектів *.

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

У будь-якому випадку, абсолютне найважливіше, що потрібно зробити в проекті для мене, це ... ну ... закінчити, відправити ... коротше кажучи, змусити його працювати!

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

Так що так, почніть з того, що ви знаєте спочатку, занотуйте важкі речі, які ви робите. Коли ви вдаряєтесь про стіну, зробіть крок назад і подивіться на цю стіну, дізнайтеся, з чого вона зроблена. У багатьох випадках ви зрозумієте, що ВИ - корінь проблеми. Ваша нерозуміння якоїсь частини проблеми, яку ви намагаєтеся вирішити, ваша незнання того, як можна краще використовувати інструменти, які ви маєте, або ваше незнання інших інструментів, які вам прямо під ніс весь час, але не готові були розпочати своє опанування.

У той же час продовжуйте читати про нові способи робити речі. Прочитайте ці найкращі практики та спробуйте перевірити, чи застосовуються вони до всього, що вам важко у вашому проекті. Якщо ні, пам’ятайте про їх існування та час від часу переглядайте їх. Залишайтеся цікавими. З часом ви побачите, що спостереження, зроблені вище, просто натискають природним чином на знання, які ви набуваєте тут.

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

Щасти

TL; DR

Ти ніколи цього не дізнаєшся. Завжди завжди є більша глибина і широта навколо кожної окремої "речі", яку ви можете знати. Вчіться, як підете. Застосуйте "найкращі практики", які, на вашу думку, є актуальними зараз. Робити помилки. Просто спробуйте уникнути дуже дорогих помилок. Знайдіть наставників, якщо ваш проект може призвести до дорогих помилок.

А тепер довга відповідь ...

1. "Робоче програмне забезпечення є основним показником прогресу." ( Agile Manifesto )

Якщо ви можете бачити краї своїх знань, це приголомшливо! Переслідуйте краї! Продовжуйте вчитися! Але майте на увазі, ви могли навчитися та проаналізувати назавжди .

Будуйте щось.

2. Вчитись і робити помилки; але не робіть "поганих". *

Продовжуйте розсовувати межі своїх знань / навичок. Ви будете робити помилки. Ви можете дізнатися у них. Але вам не потрібно бути необачним .

Час, який ви витрачаєте на пошук та роботу з більш досвідченими розробниками та наставниками, повинен збільшуватися пропорційно діловій вартості та профілю ризику проекту.

Якщо ви робите для себе маленький CLI : працюйте, як тільки хочете.

Якщо ви пишете веб - портал банку: оточіть себе дуже досвідчених розробників.

3. "Кращі практики" слід писати в цитатах і говорити підморгнувшими.

"Практики" перетворюються на "кращі практики", коли їх, як відомо, є успішними у виконанні Х принаймні в деяких випадках. Хтось визнає перевагу практики А для досягнення вигоди X і оголошує її практикою "найкращою практикою" в Інтернеті. Інші згодні - часто з поважних причин. Але з цього моменту ми, як правило, втрачаємо з поля зору, чому одні практики є "найкращими методами", а інші - "антистандартними" або "смердючими".

Біда в тому, що "найкраща практика" ніколи не є корисною. "Анти-візерунки" насправді не є диявольськими по собі. І навіть «сморід» лише іноді походить від гнилі. Іноді ця смердючість - це просто химерний, смачний сир ...

Ви не практикуєте такі речі, як "ін'єкція залежності" (DI), оскільки "ін'єкція залежності" по суті є цінною для бізнесу. Це навіть не дуже важливо для створення робочого продукту. Це досягає чогось, чого ви, можливо, хочете в своєму кінцевому продукті. Але це також може просто змусити вашу роботу тривати більше часу без жодної користі ...

Хм ...

Отже, чи слід дотримуватися "найкращих практик"? Навіть якщо ви їх не розумієте? ... Помилка ... так. Я маю на увазі ні. Але так. Але лише ті, які дійсно стосуються вас та вашого програмного забезпечення та його призначення.

Викликайте POAP ! ^{(Так. Мій блог.)}

Принципи, зразки та практики не є кінцевою метою.

Отже, правильне та правильне застосування кожного надихається та обмежується вищою, більш кінцевою метою. Вам потрібно зрозуміти, чому ви робите те, що робите!

(POAP не звільняється від POAP.)

Отже, ви, можливо, не повністю розумієте кожен нюанс DI, наприклад. Але, якщо ви розумієте наміри, ви дізнаєтесь, чи слід "використовувати" DI, і ви начебто неявно зрозумієте DI.

І після того, як ви випустите продукт, ви зможете задуматися над тим, чи справді DI (чи що завгодно) було корисним. Якщо так, сформулюйте, чому в письмовій формі. Якщо ні, то сформулюйте, чому письмово ...

Бонусне читання / Дещо актуальне:

Параліч аналізу - річ. Вам потрібно проаналізувати та навчитися; але, ви також повинні зробити речі. Баланс.

Ви завжди можете відчувати себе кодером ковбоя .

^{* Ви насправді будете робити помилкові помилки, якщо зробите щось примітне. Але ти, я припускаю, ти людина. Отже, ми прощаємо вам достроково ... Або, принаймні, я. Можливо. ... Ну ... Побачимо.}

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

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

Ну, по-перше, я б припустив, що прийняття належних методів кодування не є фальсифікацією ... Трюк - це розуміння мети кожної практики та її правильної реалізації.

Середовища швидкої розробки додатків спокусливі, тому що за дуже короткий час можна багато зробити. Я створив всю систему обліку в Access один раз. Але ви це сказали самі: ви не можете перенести подібну програму в Інтернет без перезапису, а потрібні вам інструменти справді різні.

Є причини, чому ніхто більше не використовує засоби візуального дизайну, такі як Access або Visual Basic. Вони, як правило, ізолюють вас від коду, який дійсно щось виконує. Доступ - прекрасний інструмент, але він вимагає того, щоб веб-додатки були спеціально розроблені, щоб уникнути: встановлення. Налаштування його зовнішнього вигляду може бути важким; навіть якщо він вам не потрібен в Інтернеті, програма Access завжди буде дуже схожа на будь-яку іншу програму Access. Більшість людей, які пишуть свою першу програму Access, недостатньо знають, щоб написати гарну програму, і Access полегшує написання поганого.

Отже, тепер Ви звільнилися з вивченням нової технології, щоб отримати свою заявку в Інтернеті. Чи варто будувати його правильно з самого початку? Звичайно. Але вивчати нове середовище розвитку та філософію - це як вивчити будь-яку іншу річ; вам доведеться на деякий час відхилити його, щоб виправити речі.

Тому я думаю, що ви поставили помилкову дихотомію. Ніхто не вивчає спочатку всіх «найкращих практик». Вони вчать їх, як вони йдуть. Але для того, щоб бути продуктивними на будь-якій мові ООП, я думаю, вам потрібно знати деякі ООП або хоча б те, як принципово працюють класи.

Для чого це варто, я не думаю, що PHP - ваш найкращий вибір. PHP привабливий тим, що він "неглибокий", тобто вам не потрібно багато знати, щоб написати робочу програму. Кращі практики залишаються значною мірою за розробником, а це означає, що PHP не збирається допомогти вам написати «хороші» програми. Це не обов'язково погано, але це означає, що, як і Access, ви, зрештою, також можете піти на PHP для більш надійної платформи.

Розгляньте OOP як лише інший зразок, який ви можете застосувати в потрібний час. OOP не є рамкою, яка може методично вирішити кожне завдання. Такої речі в інженерії програмного забезпечення не існує.

Також зауважте, що те, що люди претендують на добру практику , іноді викликає сумніви. Я часто бачив, як недосвідчені розробники застосовують дуже складні схеми програмування, які були б непотрібними для даної проблеми. Складність коду повинна відповідати складності проблеми. Простота - важлива цінність.

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

Тому я рекомендую застосувати найпростіше рішення, яке вирішує вашу проблему. Ймовірно, це охопить використання однієї з популярних рамок у вашому просторі. У рамках цього обмеження ви можете вільно обирати, який тип коду вам подобається. Не просто думайте, що їх спосіб зробити це підходить для вашої справи.

Також зрозумійте, чому рекомендуються певні прийоми. Наприклад, OOP стосується інкапсуляції. Можна інкапсулювати іншими способами (процедури також стосуються інкапсуляції).

Негативний приклад: Іноді люди записують шар доступу до даних, щоб відмовитись від бази даних. Тут суть цього шаблону полягає в тому, щоб стати незалежною від конкретного сховища даних та піддати більш простий інтерфейс вищим шарам коду. Але якщо вам не потрібні ці переваги, тоді вам не потрібен рівень доступу до даних і ви можете зберегти роботу. Тим не менш, багато експертів рекомендують завжди робити DAL, що є неправильною рекомендацією.

Я вважаю, що з хорошим кодом часто працювати із задоволенням. Це цікаво, тому що ви працюєте над актуальними вимогами, а не схильні до проблем інфраструктури. Якщо ви виявите, що те, що ви робите, - це занадто велика робота, то, ймовірно, ви вибрали неправильний набір шаблонів.