Я вже півтора року працюю розробником додатків (не так довго знаю), і мені щойно дали свій перший великий проект.

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

Він сказав, що я різко передумав вирішити цю задачу, і тому, що ніколи не брався за проект такого масштабу, перш ніж витрачав занадто багато часу на роздуми моделей дизайну. Своїми мудрими словами він сказав мені "F * ck майбутнє, будуй зараз".

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

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

Капітан Очевидний на порятунок!

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

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

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

Побудувати зараз, якщо ...

• проект буде відірваний
• проект має короткий термін життя
• проект не повинен мати розширень
• проект не має значення впливу на ризик (переважно з точки зору іміджу)

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

Залиште Загальну проблему на потім, якщо це може знадобитися і варто докласти зусиль:

Будуйте для майбутнього, якщо ...

• проект буде публічним
• проект є компонентом, який слід використовувати повторно
• проект є кроком для інших проектів
• проект матиме подальші проекти або сервісні випуски з удосконаленнями

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

Керівні принципи

Я б сказав, що дотримуйтесь наступних принципів якнайкраще, і ви повинні поставити себе в позицію проектувати ефективні, пристосовані продукти:

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

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

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

Просто будуйте прості речі.

Ділемати

Суперінжиніринг

Це тенденція, яку програмісти зазвичай дотримуються, коли йдеться про такий проект?

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

Прототипування / Quick-n-Dirty / Менше - це більше

Це типова тенденція просто якнайшвидше розмішувати дієвий приклад?

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

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

Коли використовувати прототипізацію?

Є підказки щодо найкращих типів проектів для використання прототипу :

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

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

"Одне з найбільш продуктивних застосувань швидкого прототипування на сьогоднішній день - це інструмент для інтерактивного проектування вимог користувачів та розробки інтерфейсу між людиною та комп'ютером".

З іншого боку:

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

А якщо навколо вас зелене монстр, просто переконайтеся, що прототип буде в межах бюджету ...

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

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

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

1. Дизайн та обговорення трохи.
2. Напишіть купу коду, який щось робить.
3. Визнайте проблеми та STOP-кодування.
4. Поставтеся серйозно до дизайну і перестаньте турбуватися про втрату імпульсу або свого коду-моджо і ігноруйте керівника проекту (Ви робите йому / їй послугу.)
5. Візьміть проект під контроль. Виправте ваші помилки. Переконайтесь, що всі розуміють план. Тримайте проект під контролем.

Іноді ви потрапляєте на одну з тих функцій, яка насправді викликає занепокоєння щодо того, як реалізувати її в існуючій кодовій базі. Це не час "просто змусити його працювати". У мене був начальник, який сказав: "Іноді доводиться хапати табурет замість молотка". Він сказав мені це після того, як він зловив мене "думати" за моїм столом. На відміну від багатьох начальників, він не припускав, що я відхиляюся, і переконався, що я зрозумів, що хоче, щоб я зробив більше цього. Геніальність.

Зрештою, ваш код - це дизайн. Це підтримується документами, схемами, зустрічами, електронною поштою, дискусіями на дошці, ТАК питаннями, аргументами, переслідуванням, приступами люті та тихими чатами за кавою. Є момент, коли ви більше не можете створити дизайн і ризикуєте викинути більше часу на проектування через недоліки, які ви виявите лише, намагаючись написати код. Крім того, чим більше ви будете писати коду, тим більше шансів ви введете недолік дизайну, з якого ви не можете кодувати вихід. Час знову для табуретки.

Чи зазвичай програмісти будують щось, що працює зараз, не думаючи про майбутнє?

Так.

Чи повинні вони так робити?

Немає.

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

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

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

Agile розробники мають приказку: "Вам не знадобиться (YAGNI)", яка закликає розробляти те, що вам потрібно зараз, а не те, що, на вашу думку, може знадобитися в майбутньому. Щоб розширити проект в майбутньому, рекомендований маршрут - це рефактор.

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

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

Це тенденція, яку програмісти зазвичай дотримуються, коли йдеться про такий проект?

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

Дуже просто думати, що додаток повинен робити це та інше і отримувати масовий відбій.

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

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

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

Він сказав, що я різко передумував завдання, і, оскільки я ніколи не брався до такого великого проекту, як я витрачав занадто багато часу на роздуми дизайнерських моделей. Своїми мудрими словами він сказав мені "F * ck майбутнє, будуй зараз".

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

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

Це ідеалістична фантазія, і життя не працює так.

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

Будь-який старший розробник може критикувати, засуджувати та скаржитися - і більшість це робить!

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

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

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

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

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

Дизайн, як правило, відкритого типу, тому занадто легко застосувати занадто багато або занадто мало його. І правильну суму ви дізнаєтесь лише після того, як проект буде зроблений або відхилений. Або навіть не тоді.

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

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

Є кілька вагомих причин, щоб прислухатися до порад, щоб припинити планування та почати кодування;

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

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

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

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

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

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

Є менеджери, які не можуть самі помітити тенденцію, поки вона вже не порушиться у facebook. Замість того, щоб знайти роботу, керуючи дисконтним магазином шин, ці менеджери роблять проблемою те, що їм потрібен код, який працює до п’ятниці. Вони не хочуть чути, що вам потрібно розробити API або перевірити масштабність вашого алгоритму. Це просто технічна мамбо-джамбо ім. Вони будуть заохочувати вас кодувати, оскільки це все, що вони розуміли про програмне забезпечення ще під час написання сценаріїв Perl, щоб допомогти клієнтам передати свої файли. (У першій роботі з продажу вони отримали звання "інженер-програмний". Хто знав, що програмне забезпечення буде таким нудним і важким?)

Покажіть мені свій код, і я скажу вам, хто ви є

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

Ви стаєте тим, що кодуєте

Ваш код - це ваша програма на все життя.

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

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

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