Працюючи єдиним розробником: перегляньте код

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

Я думав, що отримаю відповідь через статтю Джеффа Етвуда: «Програмування« Один є найолітнішим номером » , найкраще, що я міг знайти з цього приводу, але виявилося, що я просто повторюю своє запитання.

Я знаю такі сайти Stack Exchange, як цей, і Code Review - це очевидний потенційний відповідь, але, як багато хто вдячний, це FAR від ідеального:

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

Чи є відповіді, крім оплати консультанту, щоб переглянути мій код?

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

Чи є відповіді, крім оплати консультанту, щоб переглянути мій код?

Ні.

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

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

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

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

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

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

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

Я в подібній ситуації, і я сильно покладаюся на Stack Overflow, щоб отримати зворотній зв'язок із загальнодоступними питаннями. Я також вважаю, що насправді потрібно записати опис проблеми, що відповідь часто стає очевидною. З точки зору передового досвіду, я розробник .Net, і я використовую ReSharper, який запропонує варіанти найкращих практичних методів для коду, який я пишу (який я іноді просто ігнорую - це може бути трохи педантично). Ще один корисний інструмент - FxCop, який зробить аналіз статичного коду та виділить усі проблеми, які не відповідають його набору правил.

Інакше вам варто прочитати та бути в курсі сучасних практик. Мені подобається «Ранкова роса» Елвіна Ешкрафта за посилання на те, що є новим та покращеним у світі .Net.

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

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

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

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

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

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

Я відчуваю те саме для> 75% запитань, які я публікую.

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

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

Справа в точці:

Коли я був новим розробником, я багато разів мав справу зі сторінкою ерозії ASP.Net . Мені потрібно було в Google повідомлення, щоб зрозуміти, що не так. може пройти кілька годин, перш ніж я знайшов правильне рішення. Я в основному робив кожну помилку в книзі, а згодом доводилося стикатися з наслідками необхідності налагоджувати проблеми.

Тепер, коли з’являється помилка, я вже знаю «звичайних підозрюваних» у тому, що може спричинити проблему. Мій ментальний список "звичайних підозрюваних" ефективно ґрунтується на тих проблемах, з якими у мене було найбільше проблем протягом моєї кар'єри. Не вперше зробивши неефективну роботу ніг годинами Гуглінга, я ніколи не склав би цей ментальний список . Але тепер, коли у мене є ментальний список, я значно швидше вирішую проблеми.

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

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

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

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

Чотири випадки:

• Коли я розроблюю свій особистий аналіз / список списку тодо як розробник, я все ще використовую ручку та папір. Я помітив, що я замовчую припущення та неправдивість, коли я друкую свої замітки, тому що мій розум вважає, що "я можу це легко виправити пізніше". Однак виправляти щось, що ви написали на папері, дратує, вам потрібно перекреслити речі та записати між рядками, і документ виглядає набагато гірше, коли на ньому є писанки. Писання на папері змушує мене перевірити факт, перш ніж я зобов’язуюсь його писати. Це сприймає багато непорозумінь рано, перш ніж я навіть напишу код, який створюватиме помилки.
• Моя бабуся була секретарем (вік друкарської машини). Введення друку у формальному документі означало повторне введення всієї сторінки. Моя тітка - секретар (вік текстового редактора). Вона може покластися на автоматичну перевірку орфографії, і помилки можна виправити легко і з мінімальними зусиллями. Не дивно, що моя бабуся робить значно менше помилок введення тексту та орфографічних помилок порівняно з моєю тіткою.
• Відеоігри, які раніше друкувалися на картриджах. Виправити помилку після виходу було майже неможливо. Вам потрібно буде передрукувати всі картриджі, роздати їх усім постачальникам і сподіватися, що продавці зможуть якось зв’язатися з клієнтами, які вже купили гру. Це коштувало б тонн грошей (вдвічі більше фізичних витрат на виробництво) і все одно не охопить деяких клієнтів. Зараз, в епоху інтернет-патчів, розробники ігор показали, що значно менше вкладають коштів у тестування своїх ігор, щоб вони могли уникнути помилок випуску, оскільки так набагато простіше просто натиснути виправлення на кожного клієнта безпосередньо. Вплив помилки зводиться до того моменту, коли краще виправити жменю проблем за фактом, порівняно з необхідністю перевірити на всі можливі помилки, які можуть виникнути.
• Раніше я жив у квартирі третього поверху, без ліфтів, і мені доводилося часто паркувати одну-дві вулиці від моєї будівлі. Я навряд чи коли-небудь забував взяти щось із своєї машини. Зараз я живу в будинку з машиною поруч зі мною на під'їзді. Я забуваю весь час брати речі зі свого автомобіля .

Основна ідея тут полягає в тому, що складна система обміну стимулює людей здійснювати правильні та перевірені факти обміни . Суворість покарання (= складний процес виправлення) вчить не помилятися.

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

Коли ви створюєте MCVE , ви не повинні просто створювати його та розміщувати у питанні. Спочатку слід зробити це для себе , щоб можна було ізолювати проблему. І тоді, коли ви думаєте, що проблему вже не можна зменшити, і ви все ще не бачите причини; то у вас є дійсне питання щодо StackOverflow.

Справа в точці:

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

• Що станеться, коли я зміню цей параметр?
• Чи можу я відтворити проблему, якщо скорочую код?
• Які налаштування дозволяють / неможливо відтворити проблему?

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

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

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

Коли у вас уже є MCVE, ви не повинні багато перешкоджати особистої (або фірмової) інформації в ньому. Якщо це так, оскільки код мінімальний, легко перейменувати речі на більш базовий приклад foo / bar / baz.