Як ви отримали передовий досвід для своїх проектів OOP? [зачинено]

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

Наприклад, це посада, яка має кілька днів: /codereview/8041/how-to-improve-my-factory-design

Я не переконаний у своєму коді. Тому я хочу вдосконалити свої проекти, зайняти менше часу на його створення.

Як ви навчилися створювати гарні конструкції? Деякі книги, які ви можете мені порадити?

Проектування систем - одна з речей, до якої можна вдосконалитись лише зробивши це. Звичайно, це допомагає трохи прочитати про хороший дизайн - рекомендована загальна об'єктно-орієнтована книга дизайну - «Банда чотирьох моделей дизайну»: елементи багаторазового об’єктно-орієнтованого програмного забезпечення . Існують також інші книги про схеми та принципи проектування для різних типів систем та в різних областях.

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

Хоча я, як правило, найкраще сідати з іншими людьми віч-на-віч, про програмістів тут можна задати конкретні дизайнерські питання. Також є сайти Stack Exchange для огляду коду та питань реалізації .

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

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

Справжнє оволодіння вмінням передбачає розуміння того, коли ним користуватися, а коли не слід. Зловживання цим вмінням, мабуть, єдиний спосіб розвинути таке розуміння. Звичайно, ви можете прочитати про це, але читання не замінює досвід.

З одного боку, читання про шаблони дизайну - це поганий старт IMHO. Читання про принципи дизайну OO, такі як SOLID та GRASP , краще. Ознайомившись із ними, вивчення загальних моделей дизайну є хорошою ідеєю, адже ви побачите, як ці принципи можна застосувати для формування конкретних ідіом.

Стверджується, що коли у вживанні мови з’являються закономірності, то мова фактично не має особливості. Хоча це твердження дуже радикальне, в ньому є багато правди. Тому я б запропонував вам переглянути і пограти з іншими мовами, щоб краще зрозуміти поняття, які ви хочете використовувати, а також дізнатися про нові поняття. Шорт-лист буде Скрік, Рубі та Лісп.
Що стосується Ліста, то моя особиста рекомендація - « Структура та інтерпретація комп’ютерних програм» , яка дуже багато навчила мене з дизайну, показавши мені, як без особливих зусиль можна створити надійні рішення складних проблем, маючи трохи більше, ніж чітку абстракцію та (де) склад у спосіб зверху вниз.

Отже ось що я пропоную:

1. написати код (і спробуйте зрозуміти, що це робить погано)
2. прочитати код (і спробувати зрозуміти, що це робить добре)
3. обмінюватися знаннями з іншими людьми. поставити свої ідеї на випробування.

Як уже згадували інші, ви добре попрацюєте лише практикою та досвідом. Насправді не так багато ярликів, які можна взяти.

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

Що стосується розробки програмного забезпечення, то це не чорно-біле, або дизайн хороший чи поганий. Скільки б ви не мали досвіду, ви повернетесь до свого старого коду і подумаєте: "що я курив, коли писав це?" Ключовим моментом є постійне оцінювання речей і часто проходження продуманих вправ для оцінки того, що робить хороший код хорошим, а поганий - поганим.

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

Для початку я рекомендую такі книги:

• Agile Principles, Patterns and Practices in C # - Я сам 3/4-й через цю книгу. Один з головних моментів, який автор зазначає, і я погоджуюся на 100% з цим, не починайте вирішувати проблему, шукаючи схему дизайну, яку слід застосувати. Зберігайте речі максимально простими і перетворіть код на зразок, якщо альтернатива починає ускладнюватися.
• Шаблони дизайну Head First - я не читав цієї книги, і в IMO багато серій Head First орієнтовані саме на новачків у цій галузі. Тож вони, як правило, на більш простій стороні, але я чув / читав багато хороших відповідей інших про цю книгу

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