Як стати більш організованим програмістом? [зачинено]

9

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

Закрито 7 років тому .

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

Моє запитання:

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

project-management junior-programmer

— Тед Вонг
джерело

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

— Філіп

2

Як і в багатьох програмах, найважливішим є бути послідовним

— Том Сквайрс

1

@TomSquires: мені доведеться не погодитися. На сьогодні найголовніше - завжди вдосконалювати себе та код + документацію. Консистенція заради послідовності служить для того, щоб програмне забезпечення було важче підтримувати з часом.

— l0b0

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

— ozz

3

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

Щоб бути більш організованим, я спробував багато різних методів та інструментів для організації коду та навколишньої інформації:

Програми відслідковування помилок, як текстові файли GitHub / Bugzilla / TODO
Вікі-сайти, такі як GTD TiddlyWiki / GitHub
Створюйте такі інструменти, як make / Maven / grake
Інструменти управління проектами, такі як JIRA та Redmine
Редактори, як jEdit і vim
Об'єднайте такі інструменти, як Meld та kdiff3
Системи контролю версій, такі як Subversion і Git (насправді це подряпайте, просто використовуйте Git і заощадьте собі багато горя)

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

— l0b0
джерело

gtdtw посилання вниз?

— ell

2

Перефактуруйте свій код, поки не будете задоволені ним.

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

Вчіться, роблячи.

* В основному правильно :)

— Дебіли
джерело

+1. Код є "правильним", коли будь-яке повторення видавлюється і тести проходять. Структура може змінитися для проходження наступних тестів. Я дуже намагаюся не вводити складності в очікуванні неписаних тестів.

— кевін клайн

0

Git та SourceForge. Це два пункти, які я використовую при написанні великої неорганізованої програми. Для деталей Google два, тому що я не можу зв’язатись зараз з якоїсь дивної причини. Пробачте про це, сподіваюся, що це допоможе.

— Динамічний
джерело

0

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

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

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

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

Деякі конкретні поради щодо структуризації коду:

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

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

— Ментос
джерело