Моя запропонована конструкція, як правило, гірша, ніж у колеги - як мені покращитись? [зачинено]

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

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

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

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

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

У вас є дві по-справжньому сильні (і дивно незвичайні) сили:

• Ви здатні об'єктивно оцінювати свої проекти проти інших
• Ви маєте бажання і доклали зусиль, щоб зробити свої проекти оптимальними

Вам всього пару років, і вам належить пройти довгий шлях, але при такому ставленні ви обов'язково потрапите туди, просто не здайтеся; всі ми маємо справу з ментальною спиною, як це. Оскільки часто я отримую шанс, я люблю підключати принципи дизайну (НЕ такі, як шаблони дизайну), і я думаю, що це ідеальний приклад того, як вони стануть у нагоді. Вивчайте їх і практикуйте їх застосування у своїх проектах, ви перед тим, як дізнаєтесь, зробили ще один крок вперед у цьому плані.

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

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

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

В ідеалі кожен програміст повинен знати мову з кожного класу. Що ви могли дізнатися:

1. Статична набрана основна мова OOP: Java, C # (в основному використовується у програмному забезпеченні підприємства) та C ++ (системне програмування та складні настільні програми)
2. На основі прототипу мова OOP: Javascript (веб-програмування на стороні клієнта)
3. Процедурна мова: C (вбудоване програмне забезпечення та системне програмування)
4. Функціональна мова: Haskell, ML або Lisp (функціональні мови добре підходять для програм із сильною паралельністю).

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

Це допоможе розширити різноманітність ідей, які приходять на думку при спробі розробки рішення.

1. Це абсолютно нормально для кількох людей, які можуть придумати проекти різної якості. В минулому мене запрошували судити про змагання з дизайну програмного забезпечення, тому я був свідком цього з перших вуст: навіть найпростіші конструкції призводили до рішень різної якості, які виходили від розумних та досвідчених людей.
2. Читання вихідного коду є занадто низьким рівнем, щоб допомогти вам покращити свої дизайнерські навички: код вирішує складність на нижчому рівні, ніж загальний дизайн.

Найкращим способом удосконалення при розробці програмного забезпечення є розробка програмного забезпечення ^* . Один із способів зробити це - переглянувши конкурси дизайнерів: TopCoder має архів із 100+ компонентних конструкцій, доповнений проектною документацією та реалізаціями UML на Java та / або C #. Візьміть готовий компонент, який вам подобається, прочитайте специфікацію вимог та спробуйте придумати оригінальний дизайн для виконання вимог. Витратьте годину-дві на роздуми над проблемою та накреслення схеми класу, потім відкрийте виграшну конструкцію та прочитайте, що робив автор. Порівняйте його дизайн із вашим, знайдіть відмінності та подивіться, чи краще ваш дизайн. Перевірте таблицю показників змагань, щоб побачити, як судді оцінювали дизайн. Це дасть вам відгук про те, що вам потрібно вирішити, як покращити свої дизайнерські навички.

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

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

Для вдосконалення дизайнерських навичок найкраще зробити - це створити конструкції, а потім будьте жорстокі з собою, оцінюючи їх та визначаючи, як їх можна вдосконалити. Задайте собі такі питання, як: Чи буде вона працювати і чи відповідає їй вимога в усіх аспектах, чи це доцільно, як я зможу це перевірити, чи спричинить це питання щодо продуктивності, наскільки вірогідна потреба змінитись і наскільки добре буде дизайн? вміти впоратися зі змінами. Прочитайте про шаблони дизайну, а потім спробуйте застосувати їх до своїх конструкцій. Рефактор нещадно після того, як придумав ідеальну конструкцію. Якщо ви розробляєте базу даних разом із додатком, читайте детально про нормалізацію та налаштування продуктивності db, ви дізнаєтесь багато про дизайн баз даних, якщо навчитеся робити так, щоб база даних працювала найбільш ефективно та ефективно. Що стосується програм, подумайте про принципи DRY та SOLID при виконанні дизайну. Прочитайте про антипакет, щоб дізнатися, які речі уникати.

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

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

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

Ви отримаєте ідеї щодо різних принципів дизайну з деяких із таких джерел: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Дизайн програмного забезпечення на wikipedia Google "Принципи дизайну програмного забезпечення"

• Ознайомтеся з різними моделями розробки програмного забезпечення, такими як Об'єктно-орієнтоване проектування або Функціональний дизайн або Структурний аналіз. Це можуть бути абсолютно різні способи мислення, з яких можна підійти до завдання дизайну, і в кожному з них є сфери, де вони переважають. Дізнайтеся це як інструменти для вашої панелі інструментів. http://userpages.umbc.edu/~khoo/survey2.html

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

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

Повеселіться - не робіть цього, якщо вам хоч трохи не сподобається!

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

Другий крок - аналіз. Подивіться на його роботу і не просто кажіть, що краще; з’ясувати, чому це краще. Шукайте конкретні деталі та моменти, які він зробив краще.

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

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

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

Я також хотів би додати (крім чудових відповідей), що в цьому є більше, ніж "Він може створити кращий дизайн, ніж я". Інші відповіді зосереджуються на тому, як можна покращитись у дизайні, що все і добре ... але ...

Я ставлю гроші на те, що ВИ можете зробити щось краще, ніж ваш колега. Не для того, щоб створити сварливу відповідність чи що-небудь (Ви можете зробити Y краще? Вигніть вас, я можу зробити X краще!), Але щоб вказати на правду, що всі мають сильні та слабкі сторони.

На моїй роботі є 4 розробники. Бувають випадки, коли два основні «програмісти» можуть створювати речі, які просто залишають мене в пилу. Змушує мою голову крутитися, намагаючись обернути голову навколо їхніх творінь.

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

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

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

Зосередьтеся на обох - сильних і слабких сторонах - вас та ваших колег.

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

Ви повинні вчитися у всіх.

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

Не дозволяйте професіоналам заздрити між вами та можливістю вчитися.

1. Пару років насправді не так вже й багато. І чим є люди з кращим або гіршим дизайнерським поглядом на високому рівні. Наприклад, я знав людей, здатних миттєво написати складний алгоритм для програм низького рівня, але нездатний зрозуміти дизайн вищого рівня та такі поняття, як згуртованість та залежності. Однак це не фактично стан. Як ви можете покращитись у дизайні вищого рівня (прочитайте кілька книг, спробуйте кілька хитрощів вдома тощо), а також ви можете виявити, що в інших сферах програмування ваш колега-програміст менш хороший. Крім того, якщо ви думаєте, що ви приблизно однакового рівня як за досвідом, так і за технічними знаннями, це, можливо, мало б випадкову ситуацію. Наступного разу, можливо, у вас будуть кращі дизайнерські ідеї. Крім того, замість того, щоб відмовлятися від роботи, скористайтеся цією можливістю та навчайтеся у колеги. Наступного разу зробіть дизайн разом, постарайтеся зловити його таємниці, його думки. Програмування - це як ремесло, його навчають, роблячи і спостерігаючи, як інші це роблять.

2. Навички дизайну здебільшого мають досвід і після того, як ви прочитали кілька важливих книг. Я рекомендую вам наступні дії:

   • Роберт К. Мартинг - Agile Principles, Patterns and Practices (є 2 версії, одна на Java і одна в C #. Не має значення, яку саме ви виберете, ідеї та принципи можуть бути застосовані до будь-якого орієнтованого об'єкта - і не тільки - вихідний код)
   • Крім того, Роберт К. Мартінг має ще дві цікаві книги: «Чистий код» та «Чистий кодер»
   • Навіть якщо Мартін висвітлює всі моделі сучасного дизайну у своїй першій книзі, ви хочете знайти оригінальну книгу зразків дизайну «Банди чотирьох».
   • Нарешті, є й інші книги, які сьогодні високо цінуються: Зростання об’єктно-орієнтованого програмного забезпечення, керованого тестами, або Рефакторинг М. Пір'я (я думаю), або Написання справ про ефективне використання А. Кокберна та ще декілька інших, які ви відкриєте на шляху.

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

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

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

Коротше кажучи, "роки досвіду" не завжди рівнозначні. Ідіть, щоб ваші роки чогось варті.

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